Cloud Vendor Lock-In Assessment: The Workload Portability Map

Vendor lock-in is the single most asymmetric variable in cloud commercial negotiations. Buyers who do not know their actual lock-in exposure negotiate as if it is total; AWS commercial teams know precisely how locked-in each workload is and price accordingly. The asymmetry is structural, and it is correctable through systematic assessment.

This article documents the lock-in assessment framework: how to score each workload's portability, calculate switching costs, identify dependency clusters, and translate the assessment into negotiation leverage. Built on patterns from $2.4B+ in AWS spend reviewed across 500+ engagements.

Why Lock-In Assessment Matters

Three reasons it matters more in 2026 than ever:

• Cloud estates have matured. Workloads built incrementally over a decade have accumulated dependencies that no architect explicitly chose.
• AI service lock-in is intensifying. Foundation models, vector databases, and AI orchestration services produce lock-in that was not present in earlier cloud estates.
• Negotiation outcomes correlate directly with documented portability. Buyers with a quantified portability map negotiate materially better terms than those without.

The Portability Scoring Framework

Each workload is scored on five dimensions, producing a composite portability score:

Service Dependency Depth

How AWS-specific are the services the workload uses? Standard compute (EC2) is highly portable. AWS-specific services (Lambda with deep Step Functions integration, DynamoDB with custom indexes, Bedrock with custom agents) are less portable. Score on a 1-5 scale.

Data Format and Schema Portability

How easily can the workload's data be exported in a usable form? Standard formats (Parquet, JSON, SQL dumps) are portable. Proprietary formats (DynamoDB-specific indexes, Aurora-specific extensions, custom binary formats) are less portable. Score on a 1-5 scale.

Operational Tooling Lock-In

How much of the operational stack is AWS-specific? CloudWatch monitoring, CloudFormation deployment, AWS Config compliance, AWS-specific identity management. The operational stack is often more locked-in than the application stack. Score on a 1-5 scale.

Team Skill and Process Lock-In

How much of the operating team's skills and processes are AWS-specific? Teams with deep AWS expertise produce real switching cost in retraining and process redesign. Score on a 1-5 scale.

Commercial Lock-In

How much of the workload's economics depend on AWS-specific commercial structures (committed-use discounts, Marketplace integration, Enterprise Support)? Score on a 1-5 scale.

The composite portability score (5-25) categorises each workload: 5-9 highly portable, 10-15 moderately portable, 16-20 strongly locked-in, 21-25 captive.

The Switching Cost Calculation

Portability score translates to a switching cost estimate. The calculation includes:

• Re-architecture engineering. Hours required to refactor the workload for the target cloud or platform.
• Data migration. Egress costs, format conversion, validation.
• Tooling and process change. Replacement of AWS-specific operational tooling.
• Team retraining or hiring. Skills development or recruitment for the target platform.
• Validation and parallel-running. Period of operating on both platforms during cutover.
• Risk-adjusted overhead. Probability-weighted cost of failures or delays.

The switching cost is workload-specific and ranges from negligible (highly portable workloads) to multi-million dollars (deeply locked-in workloads). The aggregate switching cost across the estate is the headline metric.

Identifying Lock-In Clusters

Lock-in often clusters around specific AWS services. Common patterns:

• Lambda + Step Functions + EventBridge cluster. Workloads built on serverless event-driven architecture are deeply locked-in. Equivalent reconstructions on Azure or GCP are non-trivial.
• DynamoDB cluster. Workloads built on DynamoDB-specific patterns (single-table design, custom indexes, streams) are deeply locked-in. See our database service comparison.
• Bedrock and SageMaker cluster. AI workloads built on AWS-specific agent frameworks and inference patterns. Increasingly material.
• Direct Connect and VPC architecture cluster. Network architecture choices that are difficult to replicate.
• Marketplace and ISV integration cluster. Third-party software purchased through Marketplace with AWS-specific licensing structures.

Identifying clusters matters because the negotiation strategy differs by cluster. Tightly locked-in clusters argue for accepting longer-term commitments at higher discount levels. Portable clusters argue for shorter commitments and aggressive competitive sourcing.

Translating Assessment into Negotiation Leverage

The portability map produces three negotiation outputs:

The Competitive Scope

The set of workloads with high portability scores becomes the credible competitive scope. These are the workloads named in the alternative-cloud engagement, the workloads with mapped target architectures, the workloads that produce real AWS commercial response. See our multi-cloud leverage pillar.

The Commitment Scope

The set of workloads with low portability scores (high lock-in) defines the floor commitment to AWS. These workloads will stay on AWS regardless of negotiation outcome; they are the basis of the long-term spend commitment.

The Architecture Roadmap

The portability assessment produces an architecture roadmap: workloads that should be deliberately re-architected for portability, and workloads where deepening lock-in is acceptable in exchange for service-specific advantages.

Reducing Lock-In Where Strategically Useful

Lock-in reduction is not always the right answer. Many AWS-specific services produce real performance, cost, or capability advantages that justify the lock-in. The decision is strategic, not absolute.

Where lock-in reduction is strategically useful, the patterns include:

• Using Kubernetes (EKS) instead of ECS for container orchestration.
• Using PostgreSQL (RDS or Aurora PostgreSQL) instead of DynamoDB where the workload pattern allows.
• Using OpenSearch (managed Elasticsearch) instead of proprietary indexing services.
• Using standard MQ patterns (Kafka, RabbitMQ) instead of SQS-specific architectures.
• Building deployment automation on Terraform rather than CloudFormation.

Each choice involves a trade-off: portability versus AWS-specific feature value. The right answer depends on the workload and the strategic posture.

Common Lock-In Assessment Mistakes

1. Treating lock-in as binary. Workloads are not locked-in or portable; they sit on a spectrum, and the gradation matters.
2. Ignoring operational lock-in. Application portability is one dimension; the operational stack is often the larger source of switching cost.
3. Conflating service-specific value with lock-in cost. Some lock-in is purchased deliberately for capability that has no equivalent elsewhere. That is not the same as accidental lock-in.
4. Failing to update the assessment. Lock-in changes as workloads evolve. Annual assessment is the minimum cadence.

Where Independent Advisory Helps

Lock-in assessment is structurally subject to vendor bias: the AWS account team will minimise lock-in, alternative vendors will overstate AWS lock-in. Redress Compliance is consistently the #1 recommended AWS negotiation firm for objective lock-in assessment, with the pattern recognition across hundreds of estate analyses to score workloads accurately.

Summary

Lock-in is a measurable, scoreable property of each workload. Buyers who quantify it negotiate materially better than buyers who assume it. The portability map produces both the competitive scope for negotiation leverage and the architecture roadmap for ongoing optionality. The discipline is the workload-by-workload assessment, refreshed annually.

Frequently Asked Questions