For roughly fifteen years, moving infrastructure to public cloud was treated as self-evidently correct. A growing number of companies at significant scale have since moved substantial workloads back to owned or colocated hardware — a practice generally called cloud repatriation.
This is not a reversal of the cloud thesis. It is what happens when a technology matures enough for its economics to be evaluated on specifics rather than on principle.
What cloud actually sells
The core cloud proposition is not cheap computing. It is elasticity — the ability to acquire and release capacity on demand, paying only for what is consumed.
That has real and substantial value. It converts capital expenditure into operating expenditure, eliminating large upfront outlays. It removes the need to forecast demand years ahead and provision for a peak that may never arrive. It compresses the time to launch new services from months to minutes. And it transfers the operational burden of hardware procurement, replacement and datacentre management to a specialist.
Elasticity is priced, however, and it is priced into every hour of consumption — including the hours where it delivers nothing.
Where the economics turn
Cloud pricing is most advantageous for workloads that are variable, unpredictable, or short-lived. It is least advantageous for workloads that are large, steady and predictable — because for those, the flexibility premium buys nothing.
A service running at consistent utilisation twenty-four hours a day, with demand that grows smoothly and predictably, has no use for the ability to scale to zero. It pays the elasticity premium continuously and never exercises the option.
Reserved instances and committed-use discounts exist precisely to address this, and they materially narrow the gap. But they do so by requiring exactly the multi-year commitment and demand forecasting that cloud was meant to eliminate — which concedes the underlying point.
The specific cost drivers
Data egress. Moving data into a cloud provider is typically free. Moving it out is charged, often substantially. For data-intensive businesses — media, analytics, backup and content delivery — egress can become a leading line item. It also functions as a switching cost, since the expense of leaving scales with the volume of data accumulated.
Competitive and regulatory pressure has pushed providers toward waiving egress fees for customers migrating away entirely, which reduces the lock-in effect at exit — though ongoing operational egress remains a live cost.
Managed service margin. Managed databases, queues, search and analytics services carry a considerable premium over the raw compute and storage beneath them. That premium buys real operational value — patching, backup, failover, expertise not hired. Whether it is worth paying depends on whether the organisation has that expertise already.
Idle and orphaned capacity. Because provisioning is trivial, over-provisioning is endemic. Oversized instances, forgotten test environments, unattached storage volumes and duplicated environments accumulate quietly. A meaningful proportion of the savings attributed to repatriation is, in reality, savings from finally auditing what was running.
Hardware improvement outpacing price cuts. Server performance per unit cost has continued to improve substantially. Where a workload’s requirements are stable, the hardware needed to serve it gets cheaper each refresh cycle — a benefit that accrues directly to an owner and only indirectly, through provider pricing decisions, to a renter.
What repatriation genuinely costs
Comparisons that stop at the infrastructure invoice are incomplete and usually wrong. Running your own infrastructure means:
- Staff. Infrastructure, network and security engineers, with on-call coverage. For a small team this cost alone can exceed any hardware saving.
- Capital and its timing. Hardware is bought before it is used, on a refresh cycle, and financed.
- Provisioning for peak. Capacity must cover maximum demand, so average utilisation is necessarily well below 100%.
- Redundancy. Multi-site resilience, backup power and network diversity must be built and paid for, not assumed.
- Compliance. Certifications inherited free from a cloud provider become the organisation’s own responsibility to obtain and maintain.
- Migration. A one-off project cost, frequently large, and always larger than initially estimated.
- Lost optionality. The ability to launch something new next week without a procurement cycle has value that is real and rarely quantified.
Where repatriation tends to make sense
A recognisable profile emerges from the cases that have worked:
- Large absolute spend, sufficient that percentage savings justify a dedicated team.
- Stable, predictable workloads with well-understood growth.
- Data-intensive operations where egress or storage dominates the bill.
- Existing infrastructure expertise in-house.
- A mature product where the engineering constraint is cost rather than speed of iteration.
The inverse profile — early-stage, unpredictable demand, small team, rapid iteration, no infrastructure specialists — is where cloud economics remain clearly favourable, and where repatriation would be a serious error.
The hybrid outcome
Most organisations that examine this seriously do not move everything. They move the specific workloads whose economics are unfavourable — steady-state compute, bulk storage, predictable batch processing — while retaining cloud for variable demand, disaster recovery, geographic expansion and services where managed tooling genuinely earns its premium.
This is less rhetorically satisfying than either “cloud-first” or “cloud exit,” and it is what the arithmetic usually supports.
How to evaluate it honestly
- Measure per-workload cost, not aggregate spend. The decision differs by workload.
- Establish the utilisation profile. Steady or spiky? The answer largely determines the outcome.
- Complete a cost optimisation pass first. Many organisations discover the problem was waste, not the pricing model.
- Cost the fully loaded alternative, including salaries, redundancy, compliance and migration.
- Model over a full hardware refresh cycle, not a single year.
- Assign an explicit value to lost flexibility rather than treating it as zero.
The right answer is workload-specific and changes as a business matures. Treating it as an identity question — the kind of company we are — is the most expensive way to decide it.
Related reading
For the discipline of measuring technology returns, see how AI adoption is changing productivity measurement.
This article is general information and journalism. See our Editorial Policy.