Cloud vendor lock-in, portability and the discount.
The true cost of cloud vendor lock-in is not the migration project — it is the 12 to 28 percent discount erosion at each renewal when a customer has no credible exit. This note maps the major lock-in vectors, the portability patterns that preserve negotiating room without paying the multi-cloud complexity tax, and the exit clauses that hold discount in place.
Hyperscaler account teams price to whether a customer can actually move. Buyers who maintain genuine portability across compute, data and identity capture 8 to 15 points of additional discount over the renewal cycle. The goal is not full multi-cloud — it is a credible, documented exit path at a cost the discount uplift more than repays.
01 Key findings
Lock-in is priced at renewal, not at migration. The visible cost of a switch is the migration project; the real cost is 12 to 28 percent of discount erosion each cycle when there is no credible alternative to walk to.
Database is the most decisive vector. Wire-protocol-compatible engines (Aurora PG, Cloud SQL Postgres, Azure DB Postgres) move in 4 to 12 weeks; proprietary semantics (Spanner, DynamoDB, Cosmos DB) lock workloads for the life of the application.
Egress fees feel large and are small. They are the most visible lock-in and the smallest real contributor. The gravity well — application affinity to where the data lives — is the durable constraint.
Hybrid, not pure, portability wins. Most K8s estates keep portable workload code, mesh and ingress while accepting cloud-native storage and secrets — preserving 70 to 80 percent of portability at manageable complexity.
Portability pays for itself. A documented posture returns 8 to 15 points of renewal discount against a 5 to 12 percent operational cost — a clear net gain for estates spending $5M to $50M a year.
02 Sources of lock-in and their mitigation
Lock-in concentrates in four places. Each has a portability mitigation with a different cost profile; the discipline is to mitigate the vectors that move renewal pricing without over-engineering the ones that do not.
| Lock-in source | How it binds you | Portability mitigation | Cost to maintain |
|---|---|---|---|
| Proprietary services | Distinct semantics in Spanner, DynamoDB, Cosmos DB rewrite the application | Prefer wire-protocol-compatible managed Postgres/MySQL unless the workload truly needs them | Low — a design choice, not ongoing overhead |
| Data gravity | Applications develop affinity to data living in one cloud | Keep authoritative data in neutral formats (Parquet, Iceberg, Delta) on mirrorable object storage | Moderate — data-architecture discipline |
| Data egress fees | Per-GB charges on workload-specific moves | Model net of committed credits; negotiate free full-exit egress and a data-return clause | Low — mostly contractual |
| Commitment vehicles | EDP/MACC/CPA terms with no exit for convenience | Partial-exit and co-termination clauses; a documented BCDR or workload split | 5 to 12 percent operational |
03 Database portability
Database is the single most decisive lock-in vector for hyperscaler pricing. Proprietary services offer better economics and operational simplicity at the cost of meaningful portability constraints. Wire-protocol compatibility is the dividing line.
| Service | Wire-protocol compatible | Real-world migration effort | Lock-in level |
|---|---|---|---|
| AWS Aurora PostgreSQL | PostgreSQL wire protocol | 4 to 12 weeks for typical app | Medium |
| AWS Aurora MySQL | MySQL wire protocol | 4 to 10 weeks | Medium |
| AWS Aurora DSQL (serverless) | PostgreSQL wire, distinct semantics | 16 to 32 weeks | High |
| Google Cloud SQL Postgres | PostgreSQL wire protocol | 4 to 8 weeks | Low to medium |
| Google Cloud Spanner | Custom (SQL with restrictions) | 32 to 80 weeks for Spanner-dependent apps | Very high |
| Azure Database for PostgreSQL | PostgreSQL wire protocol | 4 to 8 weeks | Low to medium |
| Azure Cosmos DB | Multi-API (Mongo, Cassandra, Gremlin) | 20 to 60 weeks | High |
| Azure SQL Database | SQL Server compatible | 8 to 24 weeks | Medium to high |
| Snowflake (cross-cloud) | Native cross-cloud replication | 8 to 16 weeks across clouds | Lower than hyperscaler DBs |
Architect new applications for database portability whenever the workload does not specifically require Spanner, DynamoDB or Cosmos DB. The marginal performance benefit of proprietary databases over managed Postgres on equivalent compute is typically 15 to 30 percent; the renewal cost of lock-in is 12 to 28 percent. The portability decision pays back in negotiating room alone.
04 Kubernetes and platform portability
Kubernetes was designed to be portable, but the managed services (EKS, GKE, AKS) each add provider-specific extensions. The question is how much provider-specific surface area a deployment actually consumes. The control plane switches easily; node pools move through Terraform reconfiguration; cloud-native services are where lock-in concentrates.
| Component | Portable approach | Cloud-native approach | Switching cost |
|---|---|---|---|
| Ingress controller | Nginx, Traefik | AWS ALB Ingress, GCP GCLB, AKS App Gateway | 1 to 2 weeks |
| Service mesh | Istio, Linkerd | AWS App Mesh, GCP Anthos Service Mesh | 4 to 8 weeks |
| Secrets management | Hashicorp Vault | AWS Secrets Manager, GCP Secret Manager, Azure Key Vault | 2 to 4 weeks |
| Identity for pods | SPIFFE/SPIRE | IRSA (AWS), Workload Identity (GCP / Azure) | 3 to 6 weeks |
| Storage CSI | OpenEBS, Longhorn, Rook | EBS, Persistent Disk, Azure Disk | 4 to 12 weeks |
| Container registry | Harbor, JFrog Artifactory | ECR, Artifact Registry, ACR | 1 to 2 weeks |
The portable approach trades operational simplicity for switching-cost preservation. Most enterprise estates land in a hybrid configuration — portable workload code, portable mesh and ingress, cloud-native storage and secrets — which preserves 70 to 80 percent of portability at manageable complexity. Identity is the second-highest vector: an external primary IdP (Entra ID, Okta, Google Workspace) keeps user identity portable, leaving lock-in concentrated at the policy layer rather than the user layer.
05 Egress economics and the gravity well
Egress fees are the most visible component of cloud lock-in and the smallest real contributor. List rates sit close together; at scale, negotiated credits and full-exit waivers matter more than headline price.
| Provider | Egress to internet (per GB) | Free egress allowance | 2025 to 2026 reforms |
|---|---|---|---|
| AWS | $0.09 (first 10 TB), tiers to $0.05 | 100 GB/month, plus free on exit | Free egress on full account exit since March 2024 |
| Google Cloud | $0.12 (first TB), tiers to $0.08 | 200 GB/month, plus free on exit | Free egress on full account exit since 2024 |
| Azure | $0.087 (first 10 TB), tiers to $0.05 | 100 GB/month, plus free on exit | Free egress on full account exit since 2024 |
| Cloudflare R2 | $0 egress | Unlimited | Industry pressure shifted hyperscalers |
Free full-exit egress is not free workload egress. The EU Data Act and R2 pressure forced waivers only when a customer fully leaves the cloud; the fees remain for partial-workload moves, where most enterprise traffic sits. A 50-petabyte warehouse moving from AWS to Snowflake on Azure still pays roughly $2.5M. The real trap is the gravity well: the friction of moving an application back to its data is greater than the friction of building the next application in the same cloud. The defence is data-architecture discipline — keep authoritative data in cloud-neutral formats on object storage that mirrors across clouds.
06 A portability framework that works
Most multi-cloud strategies fail. The patterns that succeed are narrow, disciplined and aligned to a commercial objective. Weight these four factors to your situation before committing.
Split by workload class
Production on the primary cloud, BCDR warm-standby on a second, analytics and ML on a third aligned to the toolset. Each class lives in one cloud; the exit path stays credible. The pattern most Fortune 500 estates use in 2026.
Split by data domain
Customer-facing apps on the cloud closest to the base; internal apps aligned to the productivity stack (M365 leans Azure, Workspace leans GCP); a Snowflake or Databricks lakehouse reading from all three. Common in retail, financial services and healthcare.
Portable application platform
Kubernetes with a deliberately portable mesh, secrets and identity layer, wire-protocol-compatible databases, and a single image deployable anywhere through Terraform. Heaviest on complexity, strongest at the renewal table.
Avoid N+1 duplication
Running the same workload concurrently across two clouds rarely pays back outside specific regulated cases. Networking, identity and replication overhead exceed the resilience benefit. Split by workload — do not duplicate across clouds.
07 How portability translates to discount
The renewal impact of credible portability is concrete. In advisor-led renewals during 2024 to 2026, customers with a documented posture captured 8 to 15 points of additional discount over comparable customers without one.
| Portability posture | Typical renewal discount uplift | What it costs to maintain |
|---|---|---|
| Single cloud, no exit plan | Baseline (lowest discount) | $0 (the trap) |
| Documented BCDR on second cloud | +3 to 5 points | 5 to 8 percent of primary cloud spend |
| Workload-split across two clouds | +6 to 10 points | Operational complexity (8 to 12 percent) |
| Portable K8s + portable database | +10 to 15 points | Tooling and skill investment (5 to 10 percent) |
| Active migration in progress | +12 to 20 points (renewal becomes a defence by the vendor) | Migration project cost |
For most estates spending $5M to $50M a year on a hyperscaler, a 10-point uplift more than pays for the 5 to 12 percent additional operational cost of maintaining portability. Customers who fail to maintain it pay for the convenience through renewal-cycle pricing — a median of 11 points in the estates we advise.
08 Exit clauses that protect discount
Contractual terms matter alongside architecture. Three are decisive, and hyperscalers will accept the language with predictable pushback rather than outright refusal.
| Clause | Standard contract default | What to negotiate |
|---|---|---|
| Termination for convenience | Absent; committed for the full term | Partial-exit reducing commit 30 to 50 percent on M&A divestiture, regulatory change or material breach |
| Data return | Vague "industry standard" procedures | Specify format (CSV, Parquet, JSON), timeline (30 to 90 days) and cost (free or capped) |
| Co-termination | Staggered renewal dates across vendors | Align renewal dates to create cross-vendor pricing pressure; procurement should insist |
For the broader commercial framework, see the cloud contracts guide, cloud renewal strategy and multi-cloud strategy. For workload-specific economics, see the AWS EDP pillar, GCP CUD vs Flex CUD, Azure MACC and AWS vs Azure vs GCP pricing. The cloud exit strategy page covers the migration project framework.
09 Our recommendation
Default to wire-protocol-compatible databases and a portable mesh, ingress and identity layer. Reserve proprietary services for workloads that genuinely need them — the portability decision repays itself in renewal leverage.
Adopt a workload split and a documented BCDR path on a second cloud. A credible, evidenced exit is worth 6 to 15 points at renewal against single-digit operational cost.
Bring the posture to the table, negotiate partial-exit, data-return and co-termination clauses, and model egress net of committed credits. An active migration turns the renewal into the vendor's defence.
Reclaim renewal discount
Our Cloud & FinOps practice maps portability posture and quantifies the negotiation uplift in a four-week review.
The Licensing Edge
Weekly cloud and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.