In the Net, Episode 03
In March 2024 AWS announced that it would waive data-egress fees for customers wishing to leave. The press release was elegant, the wording generous, the timing precise: less than two months after the EU Data Act came into force, with its Article 25 obligations on cloud switching, and rather earlier than the moment in January 2027 when the same regulation will prohibit switching charges altogether. Two years on, the egress bill is no longer the largest cost of leaving AWS. The egress bill, in fact, is not even the main reason customers do not leave. The architecture is.
This is the third episode of In the Net: a series on the documented mechanics of vendor lock-in. The premise has not changed. Every platform tells you how to come in. The architecture tells you whether you can leave, what it does with what you build inside it, and how much of what you built belongs to you when you wish to walk out.
The Promise
AWS opened to the public in 2006 with what was, at the time, an unusual proposition. Stop owning racks. Stop running data centres. Rent capacity, and pay for what you use. Two decades later that promise has been kept on its own terms. Startups have shipped products without ever owning a server. Established firms have moved workloads off depreciating hardware on predictable cycles. The cloud has been, by any honest reading, the most productive infrastructure shift of a generation, and AWS has led most of it.
This matters. Lock-in stories are most useful when they begin with the promise that was real, because the architecture which produces the lock-in is not the architecture which produces the value. The value is real. The architecture, taken as a whole, also keeps the customer in a way that is increasingly difficult to characterise as a free choice.
The Hooks
The lock-in lives in three layers. The first is widely discussed. The second is rarely discussed. The third is almost never discussed in the right terms.
The egress layer
In March 2024, AWS published a blog post titled "Free data transfer out to internet when moving out of AWS". The programme is real. The conditions are also real. To qualify, a customer must hold an account in good standing, must have more than 100 GB of data stored in the account, must be moving all of their data off AWS, and must complete the move within 90 days; requests are reviewed at account level, and AWS reserves the right to apply additional scrutiny if the same account applies multiple times.
The European Union's Data Act entered into force on 11 January 2024, became applicable on 12 September 2025, and includes in Article 25 the most far-reaching cloud-switching obligations any major jurisdiction has yet legislated. By 12 January 2027, switching charges of any kind, including data egress charges levied during a switch, will be prohibited for in-scope providers. AWS' programme arrived in the window before the regulator did, with conditions the regulator will not, in fact, permit when the relevant article reaches full force. This is not an accusation of insincerity. It is an observation of timing.
The egress layer is the layer the industry has talked about for fifteen years, the layer Cloudflare campaigned against in 2021, the layer regulators eventually moved on. It is, on the evidence, also the easiest layer to mitigate. The cost of moving 50 TB out of AWS at standard rates is around €4,300 (US$5,000-ish, depending on region and class of transfer); the cost of moving 50 TB across a slow internet pipe is the duration of a few weekends. The egress layer is not, and never was, the reason large customers stay.
The runtime layer
AWS' managed services are the next layer down, and the lock-in here is structural rather than fiscal.
Amazon Aurora is documented as "PostgreSQL-compatible" and "MySQL-compatible". On the wire and at the SQL surface, this is true for the overwhelming majority of standard operations. Beneath the wire, Aurora is its own database. The storage layer is not PostgreSQL's; it is AWS' six-way replicated, log-structured shared-storage fabric. Aurora's Babelfish module accepts Microsoft SQL Server's T-SQL on top of the Aurora engine. Aurora Machine Learning calls SageMaker and Bedrock directly from SQL. Aurora Limitless Database introduces horizontal scaling semantics that have no PostgreSQL equivalent. None of these features ports off Aurora; each of them, once adopted in a production schema, becomes a one-way commitment.
Amazon DynamoDB has no on-prem equivalent. It is sold as a managed NoSQL database, but it is, more precisely, an API and a billing model wrapped around a proprietary key-value store with proprietary indexing semantics, proprietary stream semantics, and proprietary integration with Lambda, EventBridge, S3 and CloudWatch. The closest open-source replacements (Apache Cassandra, ScyllaDB, MongoDB) require non-trivial schema translation, and each has a meaningfully different consistency, availability and operational model. There are migration paths; there is no drop-in equivalent.
AWS Lambda is wired into the ecosystem at the point of event delivery. Lambda functions consume from EventBridge, S3 events, DynamoDB streams, SQS queues, SNS topics, Kinesis streams; they emit to CloudWatch logs and CloudWatch metrics; they are observed by X-Ray. Each of these dependencies is a service-specific protocol with no portable replacement that ships in the box. OpenTelemetry, Prometheus and Grafana exist and work; they are not, however, the path of least resistance inside AWS, and adopting them in addition to the AWS-native instrumentation is a deliberate engineering choice that adds cost in the short term and pays back only at migration time.
The runtime layer is the layer where the lock-in compounds. Each AWS-specific decision is locally rational. The cumulative effect, at the scale of a production estate, is that the workload is no longer a "PostgreSQL workload" or a "Linux workload"; it is an "AWS workload", and the noun matters.
The identity layer
The third layer is the layer most engineering leads underestimate, and it is, on this analysis, the most expensive layer to migrate.
AWS Identity and Access Management is two distinct things. At the level of resources, it is a policy language: a JSON document grammar that grants and denies actions on Amazon Resource Names (ARNs) under specified conditions. At the level of organisations, it is an account model: a hierarchy of accounts, organisational units, service control policies and trust relationships that, taken together, constitute the security perimeter of every workload running on AWS.
Neither half is portable. The policy language is AWS-specific. ARNs are AWS-specific. The account hierarchy is AWS-specific. KMS keys, the cryptographic substrate that secures most of what an enterprise stores on AWS, never leave the service in plaintext (by AWS' own KMS documentation); they cannot be exported, only used through API calls. KMS keys are region-bound; they cannot be shared across regions, let alone across providers. Re-encrypting a large estate with new keys held by a different provider, while keeping data continuously available, is not a 90-day operation.
IAM Identity Center, AWS' successor to AWS SSO, adds another layer: permission sets, assigned through the AWS organisation hierarchy, are translated at session time into IAM roles inside individual accounts. The permission set is the abstraction; the role is the artefact. Migrating off Identity Center means reconstructing the permission set semantics in a different identity system (Keycloak, Zitadel, Authentik, or a commercial product) and then re-grounding every workload's authorisation against the new system. The permission model is not a thousand lines of JSON; it is the encoded security history of an organisation, often built across several years and several reorganisations, and rarely documented outside the JSON itself.
A senior architect priced the migration in EC2 hours. The actual migration is in the permission model, and that took five years to build. The bill for moving compute is the bill the FinOps team will quote. The bill for moving identity is the bill the security team will quote, much later, and quietly.
The Standing
AWS holds approximately 30 per cent of the global cloud infrastructure market in Q1 2026, ahead of Microsoft Azure (around 21 per cent) and Google Cloud (around 13 per cent), according to Synergy Research Group; aggregated estimates from the same period place the Big Three together at around 65 per cent of the market, with the global cloud-infrastructure spend running at about $129 billion for the quarter and a year-on-year growth rate of 35 per cent driven largely by AI workloads. The market is, on any reasonable description, an oligopoly. AWS is the senior partner in that oligopoly.
This matters for the same reason that Adobe's 80 per cent of the creative-software market matters in Episode 01, and the same reason that LinkedIn's billion-plus users matter in Episode 02. The contract is offered from a position. The position determines what kind of contract is offered, and how much leverage the customer has to negotiate any of it. A startup signing an AWS Enterprise Agreement is not negotiating peer-to-peer with the platform that decides whether its product can run.
There is a second observation worth making. The European Union has, in the same eighteen-month window, designated Microsoft, Alphabet, Apple, Amazon, Meta and ByteDance as Digital Markets Act gatekeepers (September 2023, with full obligations from March 2024). Amazon is on the list. AWS' core services, however, are not in scope of the DMA's gatekeeper obligations; the DMA addresses Amazon's marketplace, not Amazon's cloud. The cloud was instead addressed, with some lag, by the Data Act, which applies to a far broader set of providers and is not enforced through the same designation mechanism. The architecture of the cloud sits in a regulatory space that the EU has, in essence, conceded to a sector-specific instrument rather than the DMA's gatekeeper apparatus.
The practical consequence is that AWS' cloud services are obligated to meet switching standards from January 2027, but are not obligated to meet the DMA's interoperability or data-portability standards in the same way that, say, Microsoft Windows or Apple iOS now are. The lock-in mechanisms described above continue under the Data Act regime; the Data Act provides switching rights, not interoperability rights. The customer can leave, eventually, after a notice period and a transitional period; the customer cannot, however, demand that AWS' API surface be replicated on a competitor's infrastructure.
How the User Is Treated
The Würde-Verhältnis, the dignity dimension this series tracks, has a quieter shape on AWS than it had on Adobe or LinkedIn. AWS does not, in the main, scrape its customers' workloads for AI training. AWS does not, by default, repurpose customer data. The AWS Customer Agreement is, by the standards of the platforms this series has previously examined, restrained.
What it does instead is shape the entire interaction around the assumption that the customer has chosen, and continues to choose, the AWS architecture. The Free Data Transfer Out For Leaving programme is structured as an exception to the default, granted at AWS' discretion, with conditions ("more than 100 GB", "all data", "90 days", "account-level review", "additional scrutiny on repeated applications") that read more like a creditor's conditions on a workout than a vendor's facilitation of a switch. The customer who wishes to leave is, by the structure of the programme, treated as a customer asking for a concession.
The Data Act, when it reaches full force in January 2027, will remove this framing. Until then, the framing is the architecture.
The Exit That Isn't
A customer can leave AWS. By the time this sentence ends, the customer will have understood several things they did not understand at the start.
The customer can move the data. Free Data Transfer Out For Leaving will, in most cases, be granted. The data will arrive on the receiving infrastructure, in a reasonable amount of time, at no charge. This is the easy part.
The customer cannot move the permission model. IAM policies are not portable; ARNs do not resolve outside AWS; KMS keys do not export; Identity Center permission sets have no direct equivalent on competitor platforms. Reconstructing the authorisation surface on a new identity provider is a multi-month engineering exercise that touches every workload.
The customer cannot move the managed-services semantics. Aurora's AWS-specific features must be rewritten or removed. DynamoDB schemas must be re-modelled for Cassandra, ScyllaDB or MongoDB. Lambda functions must be re-hosted, often as containers, with their EventBridge, SQS and SNS dependencies replaced by Kafka, NATS or a workflow engine. CloudWatch monitoring must be re-built on OpenTelemetry, Prometheus and Grafana. Each of these is tractable; in aggregate, on a 50-application estate, the work is 8 to 12 months and €1M to €3M of effort by independent industry averages.
This is a Lock-in by design. Not in the sense that someone in a boardroom said "let us trap our users". In the sense that the architecture, taken as a whole, produces the outcome that customers do not leave even when the cost of staying has, on their own honest accounting, exceeded the value of staying. That is what an architecture is: the outcome the structure makes likely, regardless of intent.
The Price
The price of staying is the AWS bill, the trajectory of which is documented quarterly. The Big Three's combined revenue grew 35 per cent year-on-year in Q1 2026, and the customer's share of that growth, on any given account, tracks broadly with the customer's adoption of AWS-specific services. The price of staying is also the opportunity cost of the architecture choices the customer would have made on a more portable substrate.
The price of leaving is the migration. By industry averages, a 50-application enterprise migration runs around €1.2M and 8 to 12 months; large waves with 100-plus applications run €1M to €3M and span longer. Optimised post-migration run-rates are 20 to 35 per cent lower than the pre-migration cloud bill; FinOps reports also document persistent 20 to 30 per cent waste in unoptimised AWS estates.
37signals, the maker of Basecamp and HEY, published a detailed account of its AWS departure across 2023 and 2024. The company's annual AWS spend, on its own figures, was around $3.2 million in 2022, fell to "well under a million" on-prem in 2024, and the company reported approximately $2 million in annual savings ongoing. Hardware spend, around $700,000 on Dell servers and around $1.5 million on Pure Storage for 18 petabytes, was recouped inside one year (afaik, per The Register and DCD reporting, 2024–2025). This is one case; it is also a public, documented, mid-scale case, and the kind of evidence the Würde-Verhältnis-balance shifts when it accumulates.
Twenty-one per cent of cloud workloads have been repatriated, on the Flexera 2025 State of the Cloud report. This is not a wholesale reversal of cloud adoption; it is a documented re-weighting of workloads back to private or hybrid infrastructure where the economics, latency, or data-gravity warrant it. The repatriation trend is the empirical answer to the question of whether the AWS architecture can be left. It can, for the customers who choose to.
The Escape Route
The escape route from AWS is not a single product. It is an architectural posture: build identity, policy, and the data layer on portable substrates from the beginning, and treat each managed AWS service as a deliberate, named, scoped exception to portability.
Identity, portable from day one. Keycloak is the established open-source identity provider, Java-based, with SAML, OIDC and SCIM out of the box; it is heavy to operate and widely deployed. Authentik is a more recent, lighter alternative, with a cleaner administrative interface. Zitadel is a Go-based, event-sourced alternative built for multi-tenant SaaS. All three speak the standards a modern enterprise identity provider must speak (OIDC, SAML 2.0, SCIM); all three can sit in front of AWS IAM and any other cloud's IAM, so that the customer's permission model is, from the start, defined in a system the customer owns.
Policy as code, vendor-neutral. Open Policy Agent (OPA), a CNCF graduated project, is a general-purpose policy engine with a declarative policy language (Rego) and integration with Kubernetes, service meshes, application admission controllers and infrastructure provisioning. Crossplane, also CNCF, is a Kubernetes-native control plane for provisioning cloud resources across multiple providers through a consistent declarative interface. OPA plus Crossplane is the closest the open ecosystem has come to a portable replacement for AWS-specific IaC plus IAM, and the combination scales to the kind of estate where the question is meaningful.
EU IaaS for sovereignty. Hetzner, OVHcloud, Scaleway and IONOS are the established EU-native infrastructure providers with no US parent and no CLOUD Act exposure. An independent Callista benchmark in February 2026 found Hetzner delivering approximately 14.3 times AWS' value-per-compute-unit and Scaleway approximately 4.8 times; Scaleway publishes free egress where AWS bills it. OVHcloud has the widest service range and the largest European data-centre footprint. None of these providers matches AWS' managed-services depth; all of them match AWS for compute, storage, networking, and the basic primitives an honest production workload needs.
Open-source data services. PostgreSQL replaces Aurora on the relational side, with the engine actively maintained by the community and used at multi-terabyte scale in production. Apache Cassandra and ScyllaDB replace DynamoDB on the wide-column side. MongoDB replaces it on the document side. MinIO and Garage replace S3 on the object-storage side, with the S3 API as a de-facto portability surface that ironically AWS itself does not control. PostgreSQL plus one of the wide-column or document stores covers most production data-layer workloads with no managed-service dependency on any single cloud.
Repatriation as a documented option. 37signals' case is not a recommendation that every workload return on-prem. It is evidence that the option exists and produces measurable results when chosen with engineering and operational discipline. The Flexera figure of 21 per cent repatriated workloads is the broader signal: cloud is the right answer for a great many workloads, and not the right answer for all of them.
Coda
The bill arrives every month. The data the customer has uploaded is portable as of March 2024, and will be free to move from January 2027. The architecture the customer has built inside AWS, taken whole, is not.
The cloud opened in 2006 with a promise to remove the racks. It removed the racks. It built, in their place, a permission model, a data layer and an identity layer that constitute the customer's actual production architecture. The architecture is, on this evidence, the larger part of what the customer pays for. The architecture is also the part the customer cannot fully take with them.
You can take your data with you. The architecture stays behind. The architecture is, on this evidence, the more expensive part.
Read the full article on vivianvoss.net →
By Vivian Voss, System Architect and Software Developer. Follow me on LinkedIn for daily technical writing.