Repatriation stopped being a contrarian take somewhere around the last two AI-inflated cloud bills. But moving workloads off hyperscale clouds is a decision, not a slogan. This framework tells you which workloads actually pay to repatriate, how to model five-year total cost of ownership, and when staying put is the smarter call.
What is cloud repatriation, and why is it at record highs?
Cloud repatriation is moving workloads from public hyperscale clouds back to owned hardware, colocation, or regional managed hosting. Public reporting and FinOps surveys through 2025 place repatriation activity at record levels, driven by predictable steady-state costs, egress fees, GPU scarcity pricing, and finance scrutiny, not anti-cloud sentiment.
- ▸What it is not. Rarely a wholesale exit. Most teams repatriate specific steady-state workloads and keep bursty ones in cloud.
- ▸Why now. AI compute pricing, reserved-instance sprawl, and CFOs asking why the bill grows faster than revenue.
- ▸Read the numbers carefully. Widely publicized moves, such as 37signals leaving AWS, report multi-million-dollar multi-year savings; treat those as their reported figures, not a universal guarantee. This framework complements Cloud Repatriation: When Bare Metal Wins the Math, which covers the bare-metal case in depth.
Which workloads are actually worth repatriating?
Repatriate steady-state, high-utilization, predictable workloads: databases with stable footprints, always-on application tiers, continuous batch and analytics jobs, and self-managed Kubernetes. Keep spiky, unpredictable, globally distributed, or early-stage workloads in cloud, where elasticity and managed services still win on total cost and speed of iteration.
- ▸Good candidates. Compute running 24/7 at sustained utilization above roughly 60 to 70 percent, large stable storage volumes, egress-heavy services, and GPU training clusters you keep genuinely busy.
- ▸Poor candidates. Seasonal or event-driven spikes, early-stage products still finding fit, global low-latency edge delivery, and tiny teams without operational capacity.
The honest test is utilization and predictability. If you are paying for capacity you use most of the time, owned or reserved infrastructure tends to win. Measure it the way you would in Kubernetes FinOps: From Cluster Bill to Unit Economics.
How do egress fees and idle GPUs quietly inflate my bill?
Two line items dominate hidden waste: data egress and idle accelerators. Hyperscalers charge roughly 0.05 to 0.12 USD per GB to move data out while ingest is free, and reserved GPU instances bill whether or not they compute. A half-idle accelerator fleet or a chatty egress path can double your effective unit costs.
- ▸Egress. Internet egress is tiered (for example AWS around 0.09 USD per GB for the first 10 TB, tapering with volume). Cross-AZ and cross-region transfer add more, and managed data services multiply it.
- ▸Idle GPUs. On-demand H100 and A100 instances cost several dollars per hour each; utilization below roughly 40 to 50 percent makes owned or reserved capacity cheaper. For accelerator workloads specifically, see AI Inference Cost Control: A FinOps Playbook for 2026.
- ▸Managed-service premium. Managed databases, streaming, and load balancers carry markups over self-managed equivalents you should quantify; a managed relational database can cost noticeably more than the same engine you run yourself once you add multi-AZ replicas and backups.
- ▸Over-provisioning drag. Instances sized for peak but running at low average utilization, orphaned volumes, and idle load balancers compound quietly across accounts. Tag everything and rightsize before you compare against owned hardware, or you will benchmark your waste rather than your workload.
How do I calculate a 5-year TCO for repatriation?
Build a five-year model comparing cloud run-rate against owned or colocated infrastructure. On the owned side include hardware amortized over three to five years, colocation power and space, bandwidth (often 95th-percentile billed), remote hands, spares, and the loaded cost of operations staff. Compare against cloud compute, storage, egress, and support.
- ▸Cloud side. On-demand and reserved compute, storage, egress, inter-AZ transfer, managed-service premiums, and the support plan tier.
- ▸Owned or colocation side. Capital hardware depreciated over 36 to 60 months, colo rack and power billed per kW, transit and bandwidth commits, hands-and-eyes, hardware refresh, and staff time.
- ▸Regional managed hosting side. A monthly bare-metal or managed-Kubernetes fee with included bandwidth and a support SLA, a capex-free middle ground.
- ▸Soft and risk costs. Migration effort, on-call load, N+1 redundancy, and a rehearsed disaster-recovery plan. Before repatriating at all, exhaust the quick wins in How to Cut Cloud Costs by 40% Without Downtime: A FinOps Playbook.
Repatriation vs regional managed hosting: which do I choose?
Full repatriation to your own colocation maximizes control and unit-cost savings but demands hardware ownership, staff, and disaster-recovery discipline. Regional managed hosting, meaning bare-metal or managed Kubernetes from an EU or North Africa provider, captures most of the savings without capex or a datacenter team. For most SMEs, managed regional hosting is the pragmatic middle.
- ▸DIY colocation. Lowest unit cost at scale, but you own the full hardware lifecycle, spares inventory, and on-call rotation.
- ▸Regional managed and bare-metal. Providers such as Hetzner, OVHcloud, Scaleway, or local operators give predictable monthly cost, included bandwidth, and no capital outlay, which also helps EU data residency.
- ▸Hybrid. Keep burst and global-edge traffic in hyperscale, run steady-state regionally. This posture supports both cost control and sovereignty goals at once.
A useful rule of thumb: if your baseline is stable and you would keep instances reserved for a full one-to-three-year term anyway, you are already paying for owned-style capacity without the ownership savings, and a regional provider usually closes the gap with far less operational overhead than a self-run datacenter.
When is staying in hyperscale cloud the right call?
Stay in hyperscale when workloads are spiky, growth is unpredictable, you need global edge presence, or your team is small and operations-constrained. Elasticity, managed databases, and pay-per-use still beat owned hardware when utilization is low or demand is uncertain. Repatriation only pays when load is steady and high.
- ▸Keep in cloud. Launch-stage products, seasonal or event traffic, global low-latency delivery, and teams without 24/7 operations coverage.
- ▸Watch the reversal cost. Re-architecting around proprietary services such as serverless functions and hyperscaler-only databases makes any future exit expensive, so favor portable stacks if repatriation is even possible later. This is the mirror image of the decision in When Should Your Startup Move to the Cloud (or Off It)?.
What does a low-risk repatriation rollout look like?
Start with one steady-state, low-blast-radius workload, run it in parallel on regional infrastructure, and compare real bills and latency for a full billing cycle before committing. Migrate data with a tested backfill and cutover, keep the cloud path as rollback, then repeat workload by workload.
- ▸Pick one workload, such as a stable internal service or a database read replica.
- ▸Provision regionally and wire up monitoring, backups, and a rehearsed restore before you send real traffic.
- ▸Run in parallel for one to two billing cycles and measure true TCO alongside p99 latency, not just the sticker rate.
- ▸Cut over with DNS or traffic shifting, keep rollback ready, then iterate to the next workload.
How TuniCyberLabs helps
We build the repatriation business case, not just the migration. Our engineers model five-year TCO against your actual cloud bill, run parallel workloads on EU or North Africa regional infrastructure, and re-platform databases and Kubernetes with tested backups and rehearsed failover before cutover. When cloud is genuinely cheaper, we tell you to stay. Start with a costed repatriation assessment via /contact.