How the dependency formed
A longitudinal note. Dependency rarely arrives in a single decision.
Early adoption is usually opportunistic — a workload, a team, a project. Within a few years internal platform teams standardize on AWS primitives, and IAM becomes the access language of the engineering organization.
By the time the migration is described as complete, the organization's reference architecture is no longer portable. It is an AWS reference architecture.
The platform read through the five frameworks
Each section applies one of the System Drift frameworks to Amazon Web Services.
Dependency Concentration
Concentration is unusually wide. A single supplier holds compute, object storage, network, managed databases, queues, identity for workloads, observability primitives, and increasingly the data warehouse and ML stack.
What makes the concentration durable is not market share but the depth of primitive coupling: services compose on top of one another in ways that are difficult to substitute piecemeal.
Observed indicators- —Reference architecture documents reference AWS service names directly.
- —IAM is the authorization model engineers reason in.
- —Internal platforms abstract over AWS but do not abstract away from it.
Reversibility
Reversibility is low and asymmetric. Compute and object storage are nominally portable; managed services, identity, networking, and data services are not. The least portable surfaces are precisely those that carry the most operational weight.
The relevant measurement is not whether AWS could be left, but how many internal architectural assumptions would have to be rewritten if it were.
Governance Surface
Governance has migrated into IAM, Organizations, SCPs, Control Tower, and Config. Permission, policy enforcement, and audit are expressed in AWS's control plane.
Where this is the case, AWS is the governance surface for infrastructure, not merely a place where governance is applied.
Operational Capture
Capture appears as architecture written in AWS nouns: queues are SQS, events are EventBridge, secrets are in Secrets Manager. The operational vocabulary of the engineering organization is AWS's vocabulary.
This is the form capture takes in cloud infrastructure: workflows are not embedded in a UI, they are embedded in a programming model.
Exit Complexity
Exit complexity is dominated by data egress economics, the rewrite cost of managed-service-coupled code, and the loss of the IAM-centric authorization model. Contracts and reserved-capacity commitments add a commercial layer on top.
Institutional memory of how systems are operated — runbooks, on-call practices, incident vocabulary — is itself AWS-shaped, and is among the slowest constraints to unwind.
What separation would involve
A description, not a recommendation.
Separation would require re-architecting workloads around primitives that exist on more than one cloud, rebuilding identity and policy outside IAM, and absorbing data egress over an extended window. The technical pattern is well understood; the organizational pattern — retraining engineers out of an AWS reference model — is the slower constraint.
Editorial note
This profile is a dependency study, not a product review. It is not a buyer's guide, a feature comparison, or a recommendation. It does not argue that Amazon Web Services is good or bad. It documents how the platform shapes organizational behavior, where concentration accumulates, and what separation would involve.
The framework readings are revised on the transparent methodology cadence. The indices are analytical signal, not procurement advice.