Cloud vendor lock-in — protecting your exit options.
Lock-in is deliberate architecture, not accident. This note treats it as a commercial risk to be managed: where switching costs actually accumulate, the exit clauses and portability terms worth negotiating, how egress-on-exit is priced, and how preserved optionality converts directly into negotiating leverage with AWS, Azure and Google Cloud.
Lock-in is engineered, cumulative and expensive to unwind — but it is negotiable at the point of commitment. The buyers who keep leverage are those who price their exit before they sign: quantify switching cost across the seven vectors, then trade committed spend for portability assistance, egress waivers and a 180-day transition window. Optionality preserved at signing is worth more than any single point of headline discount at renewal.
01 Key findings
Lock-in is intentional, not incidental. AWS, Azure and Google Cloud engineer switching costs to reduce churn, sustain pricing on captive accounts and defend share even against cheaper list prices. Treat it as commercial risk management, not a technical footnote.
Seven vectors compound over time. Data gravity, proprietary services, serverless, AI/ML, networking, identity and commitment terms each add friction. A new deployment carries one or two; a mature estate accumulates all seven — usually discovered only when migration is attempted.
Data gravity is the baseline cost. At $0.08–0.09/GB list egress, moving 1PB costs $80,000–$90,000. Enterprises hold dozens of petabytes, putting total exit costs in the millions before any technical or contractual barrier.
Exit terms are cheaper to win than discounts. Providers accept portability assistance, egress waivers and transition windows more readily than price cuts, because these provisions do not touch the economics of the primary commitment.
Optionality is the leverage. Genuine portability — and the credible threat of using it — is what earns better terms at renewal. Prevention through architecture beats remediation after lock-in has set.
02 Where lock-in comes from
Seven distinct mechanisms create switching costs, each with a corresponding protection. Data gravity is the baseline every buyer faces; proprietary services and AI/ML platforms are the deepest and most architectural; commitment terms are purely financial and the most directly negotiable. Map each protection to your estate before you commit. For provider-specific commitment guidance, see our AWS EDP guide, Azure commitment strategy and Google Cloud CUD guide.
| Lock-in source | How it binds you | Protection |
|---|---|---|
| Data gravity & egress | $0.08–0.09/GB to move data out; petabyte-scale estates cost millions to exit | Egress waiver for migration; S3-compatible storage abstraction |
| Proprietary managed services | Aurora, BigQuery, Cosmos DB — 2–4x harder to migrate than open-source equivalents | Open-source PostgreSQL and portable interfaces over vendor services |
| Serverless (FaaS) | Lambda / Functions code is provider-specific; porting a mature estate takes 12–24 months | Kubernetes (EKS/AKS/GKE) for portable compute |
| AI/ML platforms | SageMaker, Vertex AI, Azure ML models and pipelines are non-portable | Framework-level portability; avoid platform-specific pipelines |
| Networking constructs | Transit Gateway, VNet peering deeply couple workloads to provider fabric | Terraform / IaC to re-express topology across providers |
| Identity & access | IAM, Entra ID and Cloud Identity use incompatible policy models | Federated identity; avoid deep coupling to one policy language |
| Commitment terms | EDP / MACC / CUD spend is provider-specific and forfeited on exit | No-penalty exit clauses; transition assistance periods |
03 Exit clauses to negotiate
Architectural portability limits technical lock-in; contractual protections limit the financial and procedural kind. Negotiate these as side letters to an EDP or MACC rather than into main commercial terms — providers accommodate them far more readily as attachments than as changes to primary pricing.
No-penalty exit on material change. A termination right if the provider raises price above a defined threshold (e.g. 15% at renewal) or substantially changes terms, with a defined window (e.g. 180 days) to exit without penalty.
Data portability assistance at contract end. The provider assists with export, format conversion and validation at no additional cost, with specified formats (database dumps, Parquet) and a 30-day full-export window.
Transition assistance period. A 60–180 day post-contract window to keep using the platform at list price for extraction, API-based migration and certification of completeness.
Audit and certification rights. The provider certifies data completeness and accuracy after export; you retain rights to audit transfer logs and confirm nothing was left behind.
No surcharges for export. Bulk export tools, API access and standard formats are provided at agreed egress rates or waived for the migration window.
Committed spend is the sharpest lock-in. An organisation on a $10M/year AWS EDP with a three-year term faces roughly $20–30M in committed spend that would be forfeited on migration — a financial disincentive entirely independent of any technical barrier. Because EDP, MACC and CUD commitments cannot transfer between providers, the moment to break this trap is at signing: cap the term, stage the commitment, and pair it with the exit clauses above before the ink dries.
04 Data portability
Prevention beats remediation. Buyers who architect for portability from the outset carry modest running costs but hold dramatically lower switching costs — and correspondingly greater leverage. Four architectural choices do most of the work.
| Layer | Portable choice | What it displaces | Trade-off |
|---|---|---|---|
| Compute | Kubernetes (EKS / AKS / GKE) | Lambda, Cloud Functions | Cluster management overhead |
| Infrastructure | Terraform / IaC | CloudFormation, ARM templates | Minimal; equivalent providers exist |
| Storage | S3-compatible object APIs | Provider-locked object stores | Minimal code change to re-target |
| Database | Open-source PostgreSQL | Aurora, managed SQL | Modest performance / tuning cost |
Regulation now backs the buyer. The EU Data Act (2023) requires providers to enable data portability, remove technical switching barriers and offer free or proportionate-cost transfer for switching customers — usable in negotiation by any organisation with an EU presence. UK CMA findings on cloud market dominance similarly flag egress pricing and lock-in as anticompetitive. See our Cloud Egress Negotiation guide for the detailed tactics.
05 Egress on exit
Egress — the charge to move data out — is the switching cost every buyer pays first, and the one most often omitted from total-cost comparison. List rates cluster narrowly; at exit scale, negotiated waivers matter far more than headline price. First-10TB internet-egress list rates:
At list rates, moving 1PB costs $80,000–$90,000; a multi-petabyte estate reaches into the millions. All three providers negotiate egress waivers and migration credits for strategic accounts, and the EU Data Act pressures them further. The list winner is rarely the negotiated winner — model exit net of a committed migration waiver, not off the rate card.
06 Exit-optionality framework
Score your exposure across four factors before any renewal. Together they produce a lock-in risk profile that shows where switching costs concentrate and which protections to prioritise.
Data gravity
Quantify total data volume per provider and the list-rate egress cost to move it. This is your baseline switching cost and the first number every negotiation should reference.
Architectural depth
Audit dependence on proprietary services, serverless, AI/ML, networking and identity. The more application code bound to vendor-specific interfaces, the higher and stickier the re-architecture cost.
Commitment exposure
Calculate remaining EDP / MACC / CUD obligations. This is pure financial lock-in, forfeited on exit — and the most directly negotiable of the four.
Credible alternative
Assess whether you could actually stand up a second provider. Portability you can demonstrate — not merely claim — is what converts into leverage at the table.
07 Using lock-in as leverage
Lock-in reduction is a negotiating lever, not just a defensive posture. Rather than pressing on price alone, trade committed spend for exit protections:
“We will commit to $X over three years at [price], provided the agreement includes (1) an egress waiver for migration, (2) data portability assistance at contract end, and (3) a 180-day transition assistance period. These protections are essential to our multi-cloud strategy.”
Providers often concede these terms more readily than discounts, because they leave the economics of the primary commitment intact. The ask also signals a sophisticated buyer weighing lock-in as a strategic priority — which raises the provider's perceived risk of losing the account and improves every other term on the table. For the wider playbook, see our guides on vendor negotiating power and contract red flags.
08 Our recommendation
You are early in your cloud footprint. Standardise on Kubernetes, Terraform, S3-compatible storage and open-source databases now. The modest running cost buys durable portability and preserves leverage before lock-in ever sets.
You hold material committed spend. Score exposure across the four factors, then pair any new commitment with no-penalty exit clauses, an egress waiver and a 180-day transition window — won as side letters, not main terms.
You are captive across several vectors. Stand up a credible second provider for a real workload, cite the EU Data Act and CMA findings, and re-price your exit — optionality you can demonstrate is what restores negotiating power.
Quantify your lock-in exposure
Our Cloud & FinOps practice maps switching cost across all seven vectors and negotiates the exit terms that keep your options open.
The Licensing Edge
Weekly cloud and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.