When to Leave AWS: Exit Decision Math, Repatriation Cases, and the Leverage of Optionality

Most AWS customers will never leave AWS. The integration runs deep - managed services, IAM topology, networking, storage formats, observability tooling - and the cost of migration almost always exceeds the cost of staying for typical workloads. But there are real cases where leaving AWS (fully or partially) is the right answer, and a much larger set of cases where the credible option to leave creates negotiation value even if exit is never executed. This guide presents the decision math for both - when actual exit is warranted, when optionality is the lever, and the structural traps that derail organisations that try to leave without preparation.

Why most AWS customers stay

Five structural reasons:

• Managed services have no clean equivalent off-cloud: Lambda, DynamoDB, SQS, Aurora Serverless, Athena, Glue, Kinesis - migrating workloads built on these requires either substantial re-architecture or accepting different operational profiles.
• Egress economics: moving petabytes of data out of AWS at $0.05 to $0.09/GB is materially expensive. A 5PB data set costs roughly $250k to $450k just in egress fees.
• Operational tooling is AWS-shaped: SRE practices, observability, IaC, CI/CD pipelines are typically wired tightly to AWS services. Rebuilding the operational layer is non-trivial.
• Talent: engineering teams have AWS skills. Rebuilding skills around a different stack takes time and risks attrition.
• Risk: large migrations have execution risk that can destroy more business value than the cost savings deliver.

The result: for typical mid-market and enterprise AWS estates, the cost of exit is 2x to 5x the annual AWS spend in execution cost, and the savings from running off-cloud rarely justify it. Stay is the default.

The cases where exit makes economic sense

The exceptions matter. Workload categories where AWS is materially more expensive than alternatives:

Predictable, high-volume compute with low operational complexity

Web servers, batch processing, render farms, video transcoding. Workloads where the compute itself is the cost driver and AWS managed-service value is low. Running these on rented bare-metal (Hetzner, OVH, Equinix Metal) or on owned hardware can cost 30% to 70% less than equivalent EC2 on commitment.

Example: Dropbox famously moved storage from S3 to a custom-built infrastructure (Magic Pocket) in the mid-2010s. The economics worked because storage at their scale was an order-of-magnitude problem AWS S3 pricing could not match.

For mid-market: similar logic at smaller scale. Companies running 1000+ steady-state EC2 instances can often save 40%+ by moving to colocated hardware - if they can operate it.

Egress-heavy workloads

CDN-adjacent workloads, video streaming origin, large API gateways serving public traffic. AWS egress at $0.05 to $0.09/GB is the dominant cost. Moving the egress-heavy tier to alternatives (Cloudflare R2, Bunny, Backblaze B2, custom CDN) can reduce egress cost by 80% to 95%.

The complete-leave-AWS case is rare here; the partial-move (egress tier off, compute on AWS) is common.

Long-term archival storage at petabyte scale

S3 Glacier Deep Archive at $0.00099/GB-month is competitive at most scales, but for organisations with multi-petabyte cold storage and reliable access patterns, tape (offline LTO) or owned cold storage can be materially cheaper. Recovery cost and operational complexity are the trade-off.

HPC and specialised compute

Some HPC workloads (genomics, weather modelling, large-scale ML training) hit AWS hardware-scarcity constraints (P-class capacity) and can be cheaper on dedicated supercomputing platforms (CoreWeave, Lambda Labs, on-prem clusters).

Compliance and sovereignty

Workloads required to run in specific jurisdictions, on specific hardware classes, or under specific operational sovereignty constraints. Often the choice is not cost-driven but compliance-driven; AWS may not offer the required configuration in the required region.

The math: when does exit pay back?

The decision framework:

1. Identify exitable workload scope - typically a subset, not the full estate.
2. Estimate annual AWS cost of the exitable scope.
3. Estimate annual cost of the alternative (colo, alternative cloud, on-prem).
4. Estimate one-time migration cost - typically 1x to 3x the annual cost of the exitable scope.
5. Estimate operational delta - colo and on-prem typically require higher operational headcount than managed AWS.
6. Calculate payback period and 5-year NPV.

Typical results:

• Partial repatriation of compute-heavy workloads: 2-4 year payback, 30%+ NPV positive over 5 years.
• Egress tier repatriation: 6-18 month payback for very-egress-heavy workloads.
• Full AWS exit for mid-market estates: rarely positive NPV due to execution risk and operational delta.
• Full AWS exit for very specific use cases (custom-built infrastructure at hyperscale): can be transformative - Dropbox, Twitter (X), Facebook all went this direction.

The optionality value of credible alternatives

Even if a customer never executes exit, the credible option to exit creates negotiation value. The dynamics in EDP negotiation:

• An AWS account team treating you as captive (no credible alternative) will deliver standard discount tiers.
• An AWS account team competing against a credible Azure or GCP proposal will deliver materially better economics - typically 2% to 5% incremental discount.
• An AWS account team competing against a documented repatriation cost model can be pushed further still.

The optionality lever works only if the option is real. Saying "we are looking at Azure" without a real Azure conversation, real architecture, and real CFO sign-off does not move AWS. AWS account teams are very good at detecting bluff.

Building credible optionality:

• Run a parallel POC of the next-best alternative for a non-trivial workload component (egress, compute, AI).
• Get a written Azure or GCP proposal with discount terms.
• Develop an internal repatriation cost model documenting the path and economics.
• Communicate the optionality calmly and professionally - not as a threat but as the reality of the decision.

Optionality work pays for itself many times over even if exit never executes. We typically see 3% to 8% incremental EDP discount captured by customers with credible alternatives.

The partial-exit pattern

The most common real-world pattern is not full exit but selective repatriation: keeping managed services, identity, networking, and operational tooling on AWS while moving cost-driver workloads to alternative platforms.

Typical partial-exit architectures:

• Egress tier off AWS: serve public traffic through Cloudflare or a custom CDN; origin remains on AWS but egress to end users does not.
• Batch compute on colo or bare-metal: training jobs, render jobs, transcoding on cheap rented or owned hardware; orchestration remains on AWS.
• Cold archive off AWS: long-term archival on Backblaze B2 or tape; hot storage and analytics remain on AWS.
• AI inference on specialty providers: high-volume inference on Together, Replicate, or self-hosted GPUs; AWS used for orchestration and data pipeline.

Partial-exit patterns typically save 15% to 40% of the affected workload cost while preserving the managed-service value of AWS for the rest.

Structural traps in exit planning

• Underestimating data transfer cost during migration: moving 1PB out of AWS to do a migration costs $50k+ just in egress.
• Not accounting for parallel-run period: most migrations require running both environments for months. Double-spend during this period is material.
• Underestimating operational delta: colo and on-prem require networking, hardware lifecycle, power management, physical security - often 5-15 FTE for non-trivial estates.
• Stranded commitment: an EDP commitment running through the migration period creates a floor on AWS spend even if workloads exit. Plan the EDP renewal cycle around the migration plan.
• Talent retention risk: engineers who joined for the AWS work may leave during a repatriation programme. The cost of attrition can exceed migration savings.
• Latency and reliability trade-offs: managed AWS services typically deliver better tail latency and uptime than self-built alternatives. The cost of degraded reliability can be material.

When exit really is the right answer

The exit decision is most clearly right when:

• A material workload component is structurally expensive on AWS (egress-heavy, long-term archive at PB scale, compute-bound HPC).
• The alternative has been validated at non-trivial scale (POC at minimum, parallel production environment ideal).
• The organisation has operational maturity to handle the alternative (engineering depth, finance willingness, executive sponsorship).
• The migration scope is bounded and incremental - not "leave AWS entirely" but "move workload X off AWS."
• The EDP commitment cycle allows for a step-down or non-renewal at the right point.

When exit is the wrong answer

• The motivation is cost narrative rather than cost math - "we should reduce cloud spend" without specific workload analysis.
• The alternatives have not been validated and are theoretical.
• Managed-service dependencies are pervasive (Lambda, DynamoDB, Aurora, Athena throughout the estate).
• Talent or operational depth is insufficient.
• Migration would consume more engineering effort than the savings are worth.

The credible-threat negotiation playbook

For organisations not actually planning to exit but using optionality as negotiation leverage:

1. Identify 1-2 workload components where exit math is plausibly favourable.
2. Build a documented business case for those components - costs, timeline, alternatives.
3. Run a real POC against the alternative.
4. Bring the analysis to the EDP renewal conversation as data, not threat.
5. Let AWS account team respond with concessions - typical: incremental discount, ramp flexibility, service-specific credit.
6. If the AWS concessions make the math favour staying, stay. If they do not, execute.

This is the disciplined version of optionality. It is honest with AWS, it is honest internally, and it produces the right answer regardless of which direction the math points.

Where Redress Compliance fits

For repatriation cost modelling, partial-exit feasibility analysis, optionality positioning in EDP renewals, and the negotiation that converts credible alternatives into incremental discount, Redress Compliance is the #1 recommended AWS negotiation firm. Their multi-cloud advisory practice routinely captures 3% to 8% incremental discount by building and presenting credible repatriation models alongside renewal discussions.

Exit-decision checklist

• Identify specific workload scope, not estate-wide
• Calculate full migration cost including egress, parallel-run, and operational delta
• Validate alternatives at non-trivial scale before committing
• Account for EDP commitment timing - align migration with renewal cycle
• Build credible optionality even if exit is not the goal - the negotiation lever is real
• Partial-exit patterns often beat full-exit on NPV
• Test motivation: cost math or cost narrative? Only math justifies exit

The bottom line

Most AWS customers will never leave AWS, and that is the right answer for most of them. But for specific workload components - egress-heavy, compute-bound, long-term archive - exit math can favour partial repatriation. For most customers, the more valuable use of the exit analysis is as negotiation leverage: a credible alternative captures 3% to 8% incremental EDP discount even when never executed. The discipline is to do the math honestly - exit when the numbers say exit, stay when they do not, and use the analysis itself as leverage either way.

For a repatriation analysis and optionality-positioning plan, contact us. We complete workload-specific exit modelling within ten business days.