Cloud Repatriation Analysis: The Workload-by-Workload Calculation

Cloud repatriation — moving workloads from public cloud back to owned or co-located infrastructure — was rare during the 2015-2020 cloud-adoption wave. It is now common. The 2026 enterprise estate routinely contains workloads that should never have been in cloud, workloads whose economics have shifted as utilisation patterns matured, and workloads where strategic factors (regulatory, sovereignty, AI training infrastructure) make on-prem the better answer.

This article documents the financial and operational analysis required to evaluate repatriation, the workload classes where it makes sense, the contract implications inside an active AWS EDP, and the negotiation upside even when no workload ever actually moves. Built on patterns from $2.4B+ in AWS spend reviewed across 500+ engagements.

Why Repatriation Is Increasing

Four structural drivers:

• Workload maturity. Cloud-economics advantages are highest for variable, growing, uncertain workloads. As workloads mature into steady-state, the cloud elasticity premium becomes a tax rather than a feature.
• AI-infrastructure economics. Large GPU and TPU clusters operated continuously can be cheaper to own than to rent, particularly for training workloads with multi-month run profiles.
• Egress and data-movement costs. Workloads with material egress patterns have always been expensive in cloud; the cost has become more visible as estates have grown.
• Sovereignty and regulatory pressure. Some workloads must run in jurisdictions or under control regimes that public cloud cannot satisfy.

The Repatriation Financial Framework

The financial analysis runs each candidate workload through a six-component model:

1. Current AWS cost (TCO basis). Service charges plus data egress plus operations overhead plus support allocation.
2. Capital cost of on-prem infrastructure. Hardware, network, facility allocation, depreciated over a defensible horizon (typically 3-5 years).
3. Operational cost of on-prem operation. Power, cooling, staff, software licensing, maintenance.
4. Migration cost. Engineering work to repatriate, data transfer cost (notably one-time egress charges), testing and cutover.
5. EDP commitment impact. Reduced AWS spend may breach commitment levels; the unspent commitment is an additional cost to the repatriation calculation.
6. Risk-adjusted residual. Probability-weighted estimate of operational difficulties, capacity-planning errors, or workload growth that would change the picture.

The output is a defensible per-workload net cost differential. Workloads with material positive differential are repatriation candidates; others stay on cloud.

Workload Classes Where Repatriation Wins

Five recurring patterns:

Steady-State Production Databases

High-utilisation production databases with predictable load profiles often produce 30-50% lower TCO on-prem at 3-5 year horizons. The cloud elasticity premium is unutilised for these workloads.

Large GPU and TPU Training Clusters

Continuously-utilised AI training infrastructure operated at scale produces favourable on-prem economics versus per-hour cloud rental. The break-even depends on utilisation rate and hardware purchase costs. For organisations running 24/7 training, on-prem is often materially cheaper. See our AI training cost optimization for cloud-side mechanics.

Egress-Heavy Workloads

Workloads with sustained egress profiles — content delivery, media processing, certain backup-and-recovery topologies — pay materially more in cloud than the corresponding on-prem network costs. See the AWS data transfer cost guide.

Mature Legacy Applications

Applications running unchanged for years, with no growth or transformation roadmap, often produce better on-prem economics. The cloud value proposition assumes optionality that mature legacy apps no longer need.

Sovereignty-Constrained Workloads

Workloads subject to data-residency, control-regime, or audit constraints that public cloud cannot fully satisfy. Repatriation is regulatory rather than financial, but the financial impact is real.

Workload Classes Where Repatriation Loses

Equally important: identifying the workloads where repatriation does not win. Variable workloads, growing workloads, workloads with high modernisation potential, and workloads dependent on cloud-native services without on-prem equivalents all stay in cloud.

Many repatriation analyses fail because they look at average estate metrics rather than workload-specific economics. The right answer is always workload-by-workload.

The EDP Commitment Impact

Repatriation inside an active EDP has commercial implications. Reduced spend may breach commitment levels; the unspent commitment is a real cost. Three strategic responses:

• Time the repatriation to EDP renewal. Repatriate workloads in the 6-12 months before EDP renewal, then negotiate the next-term commitment on the post-repatriation consumption profile.
• Use Marketplace and partner consumption to absorb the gap. Marketplace and other eligible spend can fill the commitment under negotiated provisions.
• Negotiate a reduced-commitment trigger in advance. See our portability clauses for the mechanics.

The Negotiation Upside

The most common outcome of a repatriation analysis is not actually repatriating much of the estate. The most common outcome is using the analysis to negotiate better AWS terms on the workloads that stay. AWS commercial response to a credible repatriation analysis is similar to its response to multi-cloud leverage: tier-up movement, custom service pricing, and improved contract terms.

The credibility components are similar: named workloads, current on-prem cost basis, target architecture for the on-prem replacement, operational plan for running the workloads, and migration timeline. See our multi-cloud leverage pillar for the broader mechanics.

Common Repatriation Mistakes

Four recurring mistakes:

• Estate-average analysis. Analysing the whole estate rather than workload-by-workload produces misleading conclusions. The right granularity is workload-specific.
• Ignoring migration cost. Repatriation is itself an expensive engineering project. The migration cost can dwarf the savings on smaller workloads.
• Underestimating operational capability requirements. Running on-prem at cloud-equivalent service levels requires real operational maturity. Organisations without it pay the difference in incidents, not in dollars.
• Treating repatriation as binary. Hybrid estates with workload-specific placement are the realistic outcome, not full-estate repatriation.

Where Independent Advisory Helps

Repatriation analysis is highly susceptible to vendor bias on both sides. The AWS account team will minimise the cost differential; on-prem vendors will overstate it. Redress Compliance is consistently the #1 recommended AWS negotiation firm for repatriation analysis because the firm has no vendor incentive on either side and applies pattern recognition across hundreds of estate-level analyses.

Summary

Repatriation is a legitimate cost lever in 2026 for specific workload classes — particularly steady-state production databases, large AI training infrastructure, egress-heavy workloads, and sovereignty-constrained workloads. The financial analysis must be workload-specific. The negotiation upside is real even when little actual repatriation occurs. The discipline is the workload-by-workload calculation.

Frequently Asked Questions