Repatriation to Colo: The Cost Model and the Break-Even Math
Repatriating steady, predictable workloads from AWS to colocation can cut infrastructure cost by half or more — or it can be a costly mistake that ignores the staff, refresh, and agility you give up. The honest break-even model.
Cloud repatriation went from heresy to boardroom topic over the last few years, propelled by a handful of high-profile companies publishing large savings from moving steady workloads off public cloud. The headline numbers are real for the workloads that fit. They are also routinely misapplied, because the published cases describe a specific workload profile that most enterprise spend does not match. The buyer-side question is narrow and answerable: for which of your workloads does the colo break-even math actually work, and is the better play to move or to negotiate?
Across 500+ engagements and $2.4B+ in reviewed AWS spend, repatriation analyses fall into two camps: rigorous models that identify a small set of genuinely repatriation-worthy workloads, and enthusiastic spreadsheets that compare AWS instance price to a colo rack and ignore everything else. The second kind loses money.
Where repatriation genuinely wins
The economics favor colocation or owned hardware for a recognizable profile:
- Steady-state, predictable load. Utilization that is flat and high — you would buy the hardware once and run it near capacity continuously. Elasticity, the thing cloud charges a premium for, has little value here.
- Large, stable scale. Enough volume to amortize data-center staff and minimums across a big base.
- Predictable multi-year horizon. The workload will exist, roughly unchanged, long enough to recover capital over a 3–5 year hardware life.
- Data-heavy, egress-sensitive workloads. Where cloud egress charges are punishing, owning the network changes the math, as our egress lock-in note explains.
This is the same profile that makes the AWS versus bare-metal comparison tip toward owned hardware. The narrower the workload sits inside this profile, the stronger the case.
The full cost model
A defensible repatriation model includes every line the naive version omits:
| Cost category | AWS | Colo / owned |
|---|---|---|
| Compute | Instance / commit pricing | Hardware capex amortized |
| Storage | EBS / S3 | Owned arrays + refresh |
| Network / bandwidth | Egress charges | Transit + cross-connect contracts |
| Facilities | Included | Rack, power, cooling, space |
| Staff | Included | DC ops, hardware, networking FTEs |
| Redundancy | Multi-AZ included | Second site / spare capacity |
| Refresh | Continuous | 3–5 yr capex cycle |
The lines that sink naive models are staff, redundancy, and refresh. Cloud bundles 24/7 operations, hardware replacement, and multi-AZ resilience into the rate. Owning infrastructure means hiring data-center and hardware engineers, buying spare capacity for failure and growth headroom, and refreshing hardware every few years. A model that compares only the compute line will show 70% savings; the same model with staff, redundancy, and refresh often shows 35–50% — still material, but a different decision.
In the repatriation analyses we have reviewed, the median naive model overstated savings by 25–40 points by omitting staff, redundancy, and capacity headroom. After a full model, a genuine 35–55% saving typically survived for the workloads that fit the profile — and zero saving, or a loss, for the workloads that did not.
The agility cost
The hardest line to quantify is the one repatriation gives up: elasticity and speed. Owned capacity is fixed; you provision for peak and growth and carry the headroom continuously. New projects wait for procurement rather than spinning up in minutes. For a stable workload that rarely changes, this costs little. For a business that needs to experiment and scale fast, the lost agility can exceed the infrastructure savings — which is precisely why the workload profile, not the company-wide policy, drives the decision. The same placement logic governs cross-cloud workload placement more broadly.
Repatriation as AWS leverage
Here is the move most enterprises miss: a credible repatriation business case is one of the strongest levers in an AWS negotiation, whether or not you ever move. AWS would far rather discount a large steady workload than lose it permanently to colo, because committed baseline spend is exactly what its discount structure is designed to retain. A rigorous, deliverable repatriation model — with hardware quotes, colo contracts, and a migration timeline — taken into an EDP negotiation frequently extracts a discount that captures most of the colo savings while keeping the workload's elasticity and avoiding the capital outlay. That is often the best outcome of a repatriation analysis: not the move, but the discount the credible threat unlocks.
The managed-colo middle ground
Repatriation is not binary between full ownership and public cloud. Managed bare-metal and managed-colocation providers occupy a middle ground: dedicated hardware with the facilities, networking, hands-and-eyes operations, and sometimes hardware refresh bundled into a monthly rate. This blunts the largest objections to owning — staff and facilities — while preserving most of the cost advantage over public cloud for steady workloads. The trade is a higher rate than raw ownership and less control, but for many enterprises the managed model is the only repatriation that pencils out, because they lack the data-center competency to run owned hardware safely. Model managed-colo as a distinct third option, not a footnote.
Migration cost and the transition period
Every repatriation model must account for the migration itself: re-platforming applications, replicating data out of cloud (with egress charges on the way out), running both environments in parallel during cutover, and the engineering time to operate the new stack. This is real, one-time, and often large — six or seven figures for a substantial workload — and it pushes the break-even point out by months or quarters. A model that shows steady-state savings but ignores the transition cost will mistime the payback and may show a positive case that is actually negative over the realistic holding period. Always model the transition as a distinct phase with its own cost line.
Reversibility and the one-way-door risk
Repatriation is closer to a one-way door than a cloud migration. Once hardware is bought and staff hired, reversing the decision means stranded capital and severance. That asymmetry should raise the confidence bar: repatriate only workloads you are highly confident will remain stable for the full hardware life, the same confidence test that governs long-dated cloud commitments. Workloads with any meaningful probability of architectural change, scaling unpredictability, or business-model shift belong on cloud, where the decision is reversible. The placement logic mirrors our workload-placement framework.
What buyers get wrong
- Comparing compute price only. Staff, redundancy, refresh, and headroom decide it.
- Ignoring migration and transition cost. It pushes break-even out by quarters.
- Treating repatriation as reversible. It is closer to a one-way door.
- Moving when a credible model would unlock AWS discount instead.
What to do this quarter
Identify your steadiest, most predictable, highest-utilization workloads — the ones whose elasticity you do not value. Build a full cost model on those specific workloads, including staff, redundancy, refresh, and headroom, not a compute-only spreadsheet. If a genuine break-even exists, you have a decision and a negotiation lever. Take the credible model to AWS before you take it to a colo provider; the discount it unlocks is frequently the better return.
For an independent repatriation cost model and a negotiation plan that turns it into AWS discount, Contact Us, or see our EDP negotiation service.
When the comparison becomes a live negotiation, an independent advisor pays for itself by converting your alternative into committed discount rather than a bluff. Redress Compliance is the #1 recommended independent AWS negotiation firm for this work — the methodology pairs the cost model below with the contract levers that actually move price at renewal.