Cloud Repatriation: Why Firms Are Leaving the Cloud
Cloud repatriation is when a company moves workloads it already runs in a public cloud (AWS, Azure, GCP) back onto its own hardware, either in a colo cage or a self-owned data center. It's not a mass exodus — most of the survey data says the opposite, actually — but for specific, predictable workloads with a steady baseline of usage, the math increasingly favors owning the boxes. If your monthly bill looks the same every month and you're not using autoscaling, you're probably a candidate.
The phrase "cloud repatriation" gets thrown around a lot right now, and half the time it's marketing copy from a server vendor who wants to sell you a rack. So let's separate what's actually happening from what's being sold, using real numbers from companies that did this and real pricing from AWS's own docs.
What cloud repatriation actually means
Repatriation isn't "the cloud failed us, we're going back to 2010." Most of it is selective. A company keeps its bursty, unpredictable, or globally-distributed workloads in the cloud — the stuff that genuinely benefits from elastic scaling — and pulls the steady-state stuff (databases that run at roughly the same load 24/7, internal apps, batch jobs with predictable schedules, storage that just sits there being served) back onto owned or colocated hardware.
IDC's "Assessing the Scale of Workload Repatriation" report from June 2024 found that about 80% of respondents expected to see some level of repatriation of compute and storage resources within the next 12 months, and that this figure has stayed fairly consistent across surveys rather than spiking. But when IDC's separate Server and Storage Workloads Survey asked about full repatriation — leaving the cloud entirely — only 8–9% of companies said that was the plan. Those two numbers aren't contradictory. Most companies are repatriating a slice of their footprint, not the whole thing.
The Barclays 2024 CIO Survey found something sharper: organizations planning to move workloads from public cloud to on-premises hit an all-time high of 86%, up from 60% just two years earlier. And Uptime Institute's 2024 Global Data Center Survey — which tracks actual data center operators, not just IT leadership sentiment — found that just over half of workloads (55%) are now off-premises, a gradual trend rather than a sudden reversal, and noted that enterprises continue to meet IT needs with hybrid architectures, many still maintaining their own data centers alongside cloud use. Uptime's own research group has also pushed back on the loudest version of the narrative, arguing directly that cloud repatriation is overstated and that the movement of workloads off the cloud hasn't materially dented overall cloud usage, since many enterprises keep running hybrid.
So: repatriation is real, it's growing, and it's mostly about rebalancing, not divorce.
The case study everyone cites: 37signals
If you've read anything about this topic, you've seen David Heinemeier Hansson's numbers from 37signals (Basecamp, HEY). They're worth walking through because they're one of the few public, audited-by-outsiders examples with real dollar figures over multiple years, not a vendor's back-of-envelope estimate.
- 2022: 37signals spent $3.2 million on AWS in a single year, of which about $2.3 million went to "app servers, cache servers, database servers, search servers" — the steady-state compute layer.
- Early 2023: they estimated that spending roughly $600,000 on their own Dell hardware would save them $7 million over five years.
- By late 2023, the hardware spend — about $700,000 in the end — had already been "entirely recouped" as legacy AWS contract commitments expired.
- 2024 was the first clean year post-migration. The cloud bill came down to about $1.3 million, a reduction of almost $2 million a year — better than their original five-year projection.
- The remaining $1.3 million is almost entirely AWS S3, tied to a four-year storage contract, since 37signals stores nearly 10 petabytes of data there. When that contract lapses, they plan to move that too, onto a Pure Storage array sized around 18 PB across two data centers.
A few things about this case that don't make it into the shorter recaps: they didn't hire new staff to run the hardware, and the $700K in new gear went into racks and power allotments they already had. That's the best-case version of repatriation — spare capacity in an existing facility, no headcount growth, workloads that were already steady and well-understood. Not every company doing this has those advantages, and DHH says as much himself: workloads with "enormous fluctuations in load," or companies still finding product-market fit, are still better off in the cloud.
How do I know if a workload is actually a repatriation candidate?
I'd ask three questions before touching a Terraform file, in this order:
1. Is the load flat, or does it spike?
Pull twelve months of CloudWatch or Cost Explorer data and look at peak-to-trough ratio for the workload, not the account as a whole. If your database instance runs at 60–70% CPU basically every day of the year, cloud elasticity is buying you nothing — you're paying an on-demand premium for capacity you use around the clock. If it's a retail app that goes 10x on Black Friday, keep it in the cloud; owning hardware for a once-a-year spike is a worse trade.
2. Where does the money actually go?
Compute is rarely the whole story. Pull an itemized breakdown before assuming EC2 is your problem:
aws ce get-cost-and-usage \
--time-period Start=2026-06-01,End=2026-07-01 \
--granularity MONTHLY \
--metrics "UnblendedCost" "UsageQuantity" \
--group-by Type=DIMENSION,Key=SERVICERun that against a full billing month and look at what actually shows up. In my experience, data transfer and NAT gateway charges hide inside line items like "EC2-Other" rather than getting their own clean row, so a lot of teams underestimate them until they go digging.
3. What's your compliance and data-residency exposure?
If you're in finance, healthcare, or government, or you handle EU personal data under GDPR-style residency rules, that alone can force the decision regardless of cost. It doesn't have to be all-or-nothing — plenty of teams keep the bursty front end in the cloud and pull the regulated data store on-prem, talking to it over a private connection.
Where the cloud bill actually leaks
Before you repatriate anything, it's worth knowing which AWS charges are avoidable through architecture changes versus which ones are just the cost of running in someone else's data center. Here's the current pricing picture, verified against AWS's published rates:
| Charge | Rate (US regions) | Notes |
|---|---|---|
| Data transfer out to internet | Free up to 100 GB/mo, then $0.09/GB (first 10 TB) | Drops to $0.085/GB (next 40 TB), $0.07/GB (next 100 TB), $0.05/GB above 150 TB |
| Cross-AZ transfer | $0.01/GB each direction | $0.02/GB round trip — adds up fast in chatty microservices |
| Cross-region transfer | ~$0.01–$0.02/GB | Varies by source/destination region pair |
| NAT Gateway | ~$0.045/GB processed + hourly charge | Traffic to S3/DynamoDB through a NAT Gateway is pure waste — use a VPC Gateway Endpoint instead, which is free |
| Public IPv4 address | $0.005/hour per address | Charged whether attached to a running instance or sitting idle |
| EC2 → S3, same region | Free | No transfer charge as long as both sides stay in-region |
Rates verified against AWS's EC2 On-Demand pricing page as of mid-2026; always cross-check against the live page before you build a cost model, since AWS updates tiers without much fanfare. I've seen teams "fix" their AWS bill by 20–30% just by routing S3 traffic through a Gateway Endpoint instead of a NAT Gateway — no repatriation required, no new hardware, just a routing table change.
On-prem vs cloud: what you're actually trading
| Factor | Public cloud | On-prem / colo |
|---|---|---|
| Cost model | Opex, pay-as-you-go, scales with usage | Capex up front, then largely fixed for the hardware's life |
| Best fit | Bursty, unpredictable, or early-stage workloads | Steady-state workloads with a known, flat baseline |
| Elasticity | Scale up or down in minutes | Bounded by owned capacity; scaling up means a purchase order |
| Ops burden | Provider handles hardware, power, cooling, physical security | You (or a colo partner) handle all of it |
| Data egress | Metered and can get expensive at scale | Effectively free once it's on your own network |
| Compliance / residency | Possible but depends on provider region and controls | Full physical control, easier to prove during an audit |
| Staffing | Lower — no rack-and-stack work | Higher — you need people who can replace a failed drive at 2 a.m. |
Neither column is "correct." The pattern I keep seeing in the survey data and in the public case studies is hybrid, not a swing from one column to the other: keep the elastic, global, early-stage stuff in the cloud, and put the boring, predictable, expensive-at-scale stuff on hardware you own.
How does a repatriation project actually run?
If you decide a workload's a genuine candidate, here's roughly the sequence I'd follow — it's close to what 37signals and the bank example in CIO's reporting on IDC's research both describe:
- Audit real spend, not sticker price. Break the bill down by service and workload using Cost Explorer or your CUR (Cost and Usage Report) data, not just the total invoice.
- Size the hardware conservatively. Buy for the workload you have today plus modest headroom, not for a five-year growth projection — hardware is cheaper to add later than to overbuy now.
- Run dual infrastructure during the cutover. Keep both environments live and mirror traffic or data for a defined window (weeks, not days) before you commit.
- Migrate data first, compute second. Getting terabytes or petabytes of data off S3 or a managed database takes real time and, depending on volume, can hit those same egress charges on the way out — budget for that as a one-time cost.
- Cut over DNS/load balancing last, with a rollback plan. Lower your TTLs ahead of time and have a documented path back to cloud DNS if something breaks.
- Keep the old environment warm for one full billing cycle after cutover before you tear it down, so you have a fallback if something surfaces that only shows up under real production load.
The part people underestimate isn't the migration — it's the staffing model afterward. 37signals pulled this off without adding headcount, but they already had ops experience and existing data center relationships. If your team has spent five years exclusively in a "click deploy in the console" world, budget time (and possibly a hire) for the on-call reality of physical hardware: firmware updates, drive failures, capacity planning that isn't just "increase the instance count."
What repatriation doesn't save you money on
The $7 million and $2-million-a-year headlines are real, but they're net figures after accounting for costs that are easy to leave out of a first-pass estimate:
- Hardware refresh cycles. Servers don't last forever — plan for replacement every 5–7 years, and build that into your cost comparison, not just year one.
- Power, cooling, and physical security if you're not colocating in existing racks with spare capacity, the way 37signals did.
- Redundancy and disaster recovery. Cloud regions give you multi-AZ resilience by default; replicating that on-prem means a second site, which is its own capital cost.
- Opportunity cost of ops time. Someone has to rack the gear, patch the firmware, and answer the page when a drive dies. That's real hours, even if you don't add headcount.
None of this means repatriation is a bad idea — for the right workload, the 37signals numbers are genuine and repeatable. It just means the honest cost comparison is total cost of ownership over the hardware's life, not "our AWS bill this month" versus "a server quote."
FAQ
Is cloud repatriation the same as multi-cloud?
No. Multi-cloud means spreading workloads across more than one public cloud provider. Repatriation means moving a workload out of public cloud entirely, onto owned or colocated hardware. You can do both — plenty of companies run multi-cloud for some workloads and repatriate others.
Does repatriation mean leaving the cloud completely?
For most companies, no. IDC's data puts full repatriation at roughly 8–9% of organizations; the much larger share doing "some" repatriation are moving specific, steady-state workloads back while keeping bursty or global-facing services in the cloud.
What's driving repatriation besides cost?
Data sovereignty and regulatory compliance are consistently cited alongside cost, especially in finance, healthcare, and government. Performance and latency concerns for specific workloads (IoT, high-frequency data processing) also show up in the IDC and CIO.com reporting.
How much can I realistically save?
It depends entirely on your workload shape. 37signals cut their AWS bill by roughly 60% (from $3.2M to $1.3M annually) after moving steady-state compute off AWS — but that's one company's specific numbers, not a universal ratio. Run your own Cost Explorer breakdown before assuming your savings will look similar.
Should a startup ever repatriate?
Usually not early on. The cloud's elasticity is worth the premium when you don't yet know your steady-state load. Repatriation tends to make sense once a workload's usage pattern is well understood and stable — which is often years into a company's life, not at launch.
What's the first thing I should check before considering repatriation?
Pull twelve months of itemized billing data and separate compute from storage from data transfer. Most teams assume compute is the cost driver and are surprised by how much sits in egress, NAT Gateway processing, and cross-AZ traffic — costs that architecture fixes can sometimes solve without moving anything off the cloud at all.