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 the customer has no credible exit alternative. Hyperscaler account teams know whether a customer can actually move. They price accordingly. Customers who maintain genuine portability across compute, data, and identity capture 8 to 15 points of additional discount over their renewal cycle versus customers locked to a single provider. This page compares the portability of the three major lock-in vectors (database, Kubernetes, data egress) and documents the architectural patterns that preserve negotiating room without paying the multi-cloud complexity tax.
Database portability: Aurora vs Cloud SQL vs Azure Database
Database is the single most decisive lock-in vector for hyperscaler pricing. The proprietary database services (Aurora, Cloud SQL Enterprise, Azure Cosmos DB) offer better economics and operational simplicity than self-managed equivalents at the cost of meaningful portability constraints. The portability comparison varies widely across the major database options.
| 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 |
The general pattern. Wire-protocol-compatible databases (Aurora PG, Cloud SQL Postgres, Azure DB Postgres) are the lowest lock-in path because applications can move with logical replication tools (pglogical, AWS DMS, GCP Datastream). Proprietary database semantics (Spanner, DynamoDB, Cosmos DB) lock workloads to the provider for the lifetime of the application. Snowflake and Databricks deliberately offer cross-cloud architectures because their commercial model favours portability versus the hyperscaler relationship.
Negotiation lever: Customers building a new application in 2026 should architect for database portability whenever the workload does not specifically require the proprietary capabilities of Spanner, DynamoDB, or Cosmos DB. The marginal performance benefit of proprietary databases versus managed Postgres on equivalent compute is typically 15 to 30 percent. The renewal-negotiation cost of lock-in is 12 to 28 percent. The portability decision pays back in negotiating room alone.
Kubernetes portability versus the managed K8s services
Kubernetes was designed to be portable. In practice, the managed services (EKS, GKE, AKS) all add provider-specific extensions that bind workloads to the underlying cloud. The portability question is therefore: how much provider-specific surface area does the deployment actually consume?
Three layers of K8s portability matter. The control plane (EKS vs GKE vs AKS vs self-managed) is the easiest to switch. Workloads rarely depend on control-plane specifics. The node pool (AWS EC2 vs GCP Compute Engine vs Azure VM) is straightforward to switch through Terraform reconfiguration. The cloud-native services (load balancers, service mesh, secrets, IAM, storage CSI drivers) 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), Workload Identity (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 K8s estates land in a hybrid configuration: portable workload code, portable service mesh and ingress, cloud-native storage and secrets. The hybrid pattern preserves 70 to 80 percent of portability with manageable operational complexity.
Data egress economics and the gravity well
Data egress fees are the most visible component of cloud lock-in. The fees are also the smallest contributor to actual lock-in cost in most enterprise architectures. The egress fee economics are designed to feel high but to be small relative to total cloud spend, exactly the inverse of how customers perceive them.
| 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 |
The EU Data Act and competitive pressure from R2 forced all three hyperscalers to offer free egress when a customer fully exits the cloud. The fees remain in place for partial-workload egress, which is where most enterprise traffic actually sits. A 50-petabyte data warehouse moving from AWS to Snowflake on Azure still pays approximately $2.5M in egress fees because the move is workload-specific, not full account exit.
The data-egress lock-in pattern is therefore not the per-GB fee. It is the gravity well: applications develop affinity to data that lives in a single cloud, and the friction of moving the application back to where the data lives is greater than the friction of building new applications in the same cloud. The portability defence is data-architecture discipline: keep authoritative data in cloud-neutral formats (Parquet, Iceberg, Delta) on object storage that can be mirrored across clouds.
Identity and access portability
The identity layer is the second-highest lock-in vector. Each hyperscaler binds workloads to its identity service (AWS IAM, GCP IAM, Azure Entra ID). Workloads that use proprietary identity primitives (IAM Roles, Workload Identity Federation, Managed Identities) are hard to move without rewriting authorisation logic.
The portable pattern uses external identity. Hashicorp Boundary, SPIFFE/SPIRE for workload identity, and a primary IdP (Entra ID, Okta, Google Workspace) for human identity across clouds. The setup is operationally heavier than native IAM. The payback is that authorisation policies are written once and applied across clouds.
For enterprises using Microsoft Entra ID or Okta as the primary IdP, the lock-in cost on the identity layer is small. Both products integrate with all three hyperscalers as the federation source. The lock-in concentrates at the policy layer (IAM Conditions vs Conditional Access vs Cloud Identity-Aware Proxy) rather than at the user-identity layer.
Multi-cloud architectural patterns that work
Most multi-cloud strategies fail. The three patterns that succeed in 2026 are narrow, disciplined, and aligned with a specific commercial objective.
Pattern one: split-by-workload-class. Run production on one primary cloud. Run BCDR on a second cloud at a defined warm-standby state. Run analytics and ML on a third cloud aligned to the toolset (e.g. BigQuery on GCP, Databricks on AWS, Synapse on Azure). Each workload class lives in one cloud; the customer maintains a credible exit path across all three. This is the pattern used by most Fortune 500 enterprises in 2026.
Pattern two: split-by-data-domain. Run customer-facing applications on the cloud closest to the customer base. Run internal applications on the cloud aligned to the productivity stack (Microsoft 365 estates lean Azure; Google Workspace estates lean GCP). Maintain a Snowflake or Databricks lakehouse that reads from all three. This pattern is common in retail, financial services, and healthcare.
Pattern three: portable application platform. Build on Kubernetes with a deliberately portable service mesh, secrets, and identity layer. Use cloud-managed databases through wire-protocol-compatible options. Maintain a single application image that can deploy on any cloud through Terraform. This pattern is heaviest on operational complexity but delivers the strongest negotiation position at renewal.
What does not work: True N+1 multi-cloud (running the same workload concurrently across two clouds for resilience) is operationally expensive and rarely pays back outside specific regulated workloads. The networking, identity, and data-replication overhead consumes more cost than the resilience benefit for most enterprises. Multi-cloud should be split-by-workload, not duplicated-across-clouds.
How portability translates to discount
The renewal pricing impact of credible portability is concrete and quantifiable. In advisor-led hyperscaler renewals during 2024 to 2026, customers with a documented portability posture captured 8 to 15 points of additional discount versus 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 |
The economics are clear. For most enterprise estates spending $5M to $50M annually on a hyperscaler, a 10-point discount uplift more than pays for the 5 to 12 percent additional operational cost of maintaining portability. The customers who fail to maintain portability are paying for the convenience through renewal-cycle pricing.
Exit clauses that protect discount
Contractual exit clauses matter alongside the architectural posture. Three terms are particularly important.
Termination for convenience. Standard hyperscaler EDP and CASC contracts do not include termination for convenience. The customer is committed for the full term. Negotiate a partial-exit clause that allows reduction of the commit by 30 to 50 percent in the event of M&A divestiture, regulatory change, or material breach. Hyperscalers will accept this language with consistent pushback on the breach threshold.
Data return clause. The contract should specify the format, timeline, and cost of data return at term-end. Standard contracts often default to "industry standard" return procedures, which is too vague to enforce. Specify the format (CSV, Parquet, JSON), the timeline (30 to 90 days), and the cost (free, or capped at a defined rate).
Co-termination clause. For enterprises with multiple hyperscaler relationships, negotiate aligned renewal dates. Co-terminated renewals create cross-vendor pricing pressure that staggered renewals destroy. The hyperscaler account teams will resist this; the customer's procurement team should not.
For the broader cloud commercial framework, see cloud contracts guide, cloud renewal strategy, and multi-cloud strategy. For workload-specific economics, see 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. Engagement starts at cloud contract negotiation.