26 Aug 2026 · by Rehan Azaz

Leaving the cloud is having a moment. Most teams shouldn't.

OpinionCloudInfrastructure

Close-up of a rack switch labelled Cloud Router Switch with blue patch cables looping into it

Every few months a company publishes a post about leaving AWS and cutting its infrastructure bill by sixty per cent, it does the rounds, and my inbox fills with clients asking whether they should do the same. Usually the honest answer is no. Sometimes it is a clear yes. The difference is more predictable than the headlines make it sound.

Why the bill got scary

Cloud pricing rewards workloads that are spiky and unpredictable, and quietly penalises the ones that are steady. If your traffic triples for four hours a day and sits idle overnight, elasticity is a genuine discount. If you run the same forty servers' worth of load every hour of every day for three years, you are renting them at a markup and paying for flexibility you never use.

On top of that, the managed services that make the cloud pleasant — the hosted database, the queue, the load balancer, the observability stack — are priced as convenience, and convenience compounds. So does egress. The bill grows with the company whether or not the architecture needs it to. a16z's widely cited analysis made the version of this argument that stuck: at scale, cloud spend quietly becomes one of the largest line items a public software company has, and it's rarely re-examined once it's baked into the budget.

When staying put is the right call

Small teams. Early-stage products where the shape of the load still changes weekly. Anything with genuinely bursty or seasonal demand. Teams with nobody who wants to be woken up because a disk failed. In all of those cases the cloud is buying you optionality and operational headcount you do not have, and that is worth real money.

When leaving actually pays

A baseline load that has been flat and predictable for years. A bill large enough that a dedicated infrastructure hire is a rounding error against it. An engineering culture that already knows how to run things — capacity planning, patching, hardware on-call — or is willing to build that muscle on purpose. Heavy egress or storage footprints, where cloud pricing is least forgiving. When several of those line up, the savings are real and they repeat every year — 37signals has published its own numbers after doing exactly this, and DHH's account of the decision is the clearest public write-up of what "the maths flips" looks like in practice.

The part the case studies skip

Leaving is not "rent bare metal instead of instances". It is taking back capacity planning, failure domains, physical security, patching, and a migration that eats months of engineering time with nothing the user can see at the end of it. The sixty-per-cent headline almost never prices the team-year it cost to get there, or the salary line it added for good.

What I tell clients

Before anyone draws a data-centre diagram: model your steady-state baseline against a committed-use or reserved plan with your current provider. A lot of the savings people chase is just the discount for promising to stick around, and you can have that without moving anything. Only if that still is not enough, and you have the team to run the alternative, does repatriation earn its risk.

The cloud is not expensive or cheap in the abstract. It is expensive for workloads that do not need what it sells, and most teams are somewhere in the middle — where the fix is a pricing conversation, not a lease.

FAQ

Is cloud repatriation actually cheaper?

Sometimes, and only once you've priced the whole move — hardware, colocation, the team to run it, and the migration itself — against your provider's best committed-use discount, not its list price. For a flat, predictable baseline at real scale it usually is. For spiky or still-changing workloads it usually isn't.

When should a startup avoid leaving the cloud?

Almost always, pre-product-market-fit. Early-stage traffic shapes change weekly, nobody wants to be the on-call for a failed disk, and the cloud is buying optionality and headcount you don't have yet. Repatriation is a scale problem, not a stage-zero one.

What's the difference between reserved instances and repatriation?

A reserved instance or savings plan is a discount for committing to your current provider — no migration, no new operational burden, savings in weeks. Repatriation replaces the provider entirely, which can save more per dollar of compute but adds the cost and risk of owning the hardware and the migration.

What hidden costs does cloud repatriation have?

Capacity planning, hardware failure and replacement, physical security, patching, and a migration that consumes months of engineering time with nothing user-visible to show for it. The published savings headlines are almost always net compute cost only — rarely the team-year it took to get there.

Do committed-use plans really match repatriation-level savings?

Not always, but they capture a meaningful share of it with none of the operational downside, which is why they're worth pricing first. If the gap that's left is still large at your scale, that's the signal repatriation is worth modelling seriously.

Is a hybrid cloud-plus-on-prem approach a middle ground?

Often the right one — steady baseline load on owned hardware, with the public cloud kept for genuine bursts, disaster recovery, or new products whose shape isn't settled yet. It takes the elasticity you actually use and drops the markup on the load that never needed it.