Cloud Repatriation in 2026: Why DevOps Teams Are Quietly Moving Workloads Off AWS

By Surbhi | DevOps · FinOps · Cloud Engineering · AWS · Platform Engineering

Three years ago, if you had told a room full of DevOps engineers that a serious company was planning to delete its entire AWS account, the reaction would have been somewhere between disbelief and concern for that company’s future. Today, when 37signals’ CTO says exactly that in public, the reaction from most of the DevOps community is a quiet nod, and a mental note to go check their own Cost Explorer dashboard.

I want to start with a confession: for most of my career, “cloud repatriation” was a phrase I associated with legacy enterprises that had failed to modernise — the kind of company still running COBOL and unwilling to change. It was not a phrase I associated with well-run, cloud-native, Kubernetes-fluent engineering organisations. That association has aged badly. In 2026, some of the most technically sophisticated platform teams in the industry are the ones quietly moving specific, well-understood workloads off the public cloud and onto infrastructure they control directly — and they are not doing it because they misunderstood the cloud. They are doing it because they understood it too well.

This is not a “the cloud is dead” article. It is not a “go build your own data centre” article either. It is the honest, practitioner-level breakdown of what is actually driving this trend, which specific workloads make sense to repatriate and which absolutely do not, what the real numbers look like once you strip away the marketing on both sides, and how to evaluate this for your own infrastructure without either dogmatically defending the cloud or naively assuming bare metal solves every problem.

The Numbers That Made This a Boardroom Conversation

I do not want to lead with anecdotes, because the anecdotes are only interesting once you see how consistent the underlying data is across multiple independent sources.

IDC’s most recent report found that 80% of enterprises are bringing at least some workloads back from the public cloud in 2026. That is not a fringe statistic from a vendor with an incentive to inflate it — it is echoed by a Barclays CIO survey showing 86% of Chief Information Officers plan to move at least some public cloud workloads back to private cloud or on-premises environments, and by Flexera’s 2025 State of the Cloud Report, which found that managing cloud costs is the single biggest challenge cited by 84% of respondents.

The financial outcomes being reported are not marginal. Organisations pursuing strategic repatriation are commonly reducing infrastructure spending by 30 to 60 percent, and 61% of enterprises report cost reductions of over 25% after repatriation. These are not one-off anecdotes from unusually inefficient AWS deployments — they are consistent enough across independent surveys that the pattern itself has become the story.

The important nuance, which most headlines strip out entirely: only about 8 to 10 percent of organisations are doing a full cloud exit. Gartner projects that 90% of organisations will be operating in hybrid cloud models through 2027, and 92% already do. The real story of 2026 is not “the cloud is failing.” It is that engineering organisations that spent a decade treating “move everything to the cloud” as an unquestioned strategic default are now doing the workload-by-workload analysis that should probably have happened from day one — and a meaningful fraction of what they find does not belong there.

What Cloud Repatriation Actually Means in 2026

Cloud repatriation is the process of moving applications, workloads, or data from a public cloud provider — AWS, Azure, or GCP — back to on-premises data centres, colocation facilities, or alternative infrastructure providers that operate outside the traditional hyperscaler pricing model.

It is important to be precise about what this is not. It is not a rejection of cloud computing as an architectural philosophy. The engineering practices that cloud adoption popularised — infrastructure as code, containerisation, horizontal scaling, GitOps-driven delivery, API-driven provisioning — remain exactly as valuable regardless of where the underlying compute physically lives. Teams that repatriate well are not abandoning the DevOps practices that made cloud adoption productive. They are running those same practices against different infrastructure.

The specific destinations vary considerably in 2026. Some organisations move to fully self-managed on-premises data centres. Others use colocation facilities where they own the hardware but rent the physical space, power, and network connectivity. A growing number use “cloud-adjacent” providers — Hetzner, OVH, Civo, and similar operators that offer dedicated or virtualised compute at a fraction of hyperscaler pricing, without the full operational burden of running your own data centre from scratch.

The distinction that matters most for a DevOps audience specifically: modern repatriation platforms increasingly let teams retain an AWS-like developer experience — self-service provisioning, automation, Kubernetes-native tooling — while running on dramatically cheaper underlying infrastructure. The old framing of repatriation as “give up developer experience to save money” is becoming less true as the tooling matures, which is precisely why more sophisticated engineering organisations are willing to consider it seriously.

The Egress Fee Trap Nobody Fully Appreciates Until They Try to Leave

If there is one number from this research that should make every DevOps engineer pause, it is this: moving just one petabyte of data out of AWS S3 can incur egress fees ranging from $90,000 to $120,000.

That figure is not a rounding error or an edge case. It is the structural mechanism that makes hyperscaler pricing function less like a utility and more like a subscription with an exit penalty attached. Ingress — data flowing into AWS — is free. Egress — data flowing out — is billed, and billed heavily, precisely at the moment you have decided you want to leave.

The 37signals case makes this concrete in an almost theatrical way. When the company announced its intention to fully exit AWS, the scale of data involved was large enough that AWS reportedly waived $250,000 in egress fees just to facilitate the departure — which is itself a remarkable signal about how significant those fees would otherwise have been, and about how aware hyperscalers are of the retention effect that egress pricing creates.

For DevOps teams evaluating multi-cloud or repatriation strategies, this economic reality changes the calculus in a specific way: the decision to concentrate large volumes of data inside one hyperscaler is not just an architectural decision, it is a decision with a real, quantifiable exit cost attached from day one. Teams building new systems in 2026 are increasingly factoring projected egress costs into their initial architecture decisions, not just their eventual repatriation decisions — because by the time you are trying to leave, the fee structure has already done its work.

The 37signals Story — And What It Actually Proves

The most widely cited case study in this entire trend is 37signals — the company behind Basecamp and HEY — and it is worth understanding what actually happened, because the headline numbers get repeated more often than the underlying reasoning.

37signals’ leadership published a detailed breakdown of their cloud spend that showed an AWS bill of roughly $3.2 million per year. Their projection, after moving to owned and leased hardware, was that the overall yearly infrastructure bill would drop to well under a million dollars on-premises — without adding extra staff to manage it. The storage migration component alone reportedly saved $1.3 million per year: AWS had been charging approximately $1.5 million annually for S3 storage that costs less than $200,000 to operate on owned hardware — an 87% reduction on that specific line item.

The company’s stated five-year savings projection is $10 million, and its stated intention was to eventually delete its entire AWS account.

What this case study actually proves is narrower than the headline suggests, and understanding that narrowness is the useful part. 37signals runs workloads that are genuinely well-suited to repatriation: predictable, well-understood traffic patterns for a mature product with years of operational history, substantial storage volumes where hyperscaler markup compounds significantly, and an engineering organisation with the operational maturity and existing systems expertise to run hardware directly without needing to rebuild that capability from scratch.

This is not proof that repatriation is right for a two-year-old startup with unpredictable, potentially explosive growth, uncertain traffic patterns, and a small team that has never operated anything below the level of a managed Kubernetes service. The 37signals case is a data point about what is possible for a specific category of workload and organisation — not a universal instruction to follow.

Why This Is Happening Now, Specifically

Understanding the timing matters, because “cloud is expensive” is not a new observation — engineers have complained about AWS bills for over a decade. What changed to turn a long-standing complaint into a boardroom-level strategic shift in 2026 specifically?

Cost visibility finally caught up with cost reality. FinOps practices that mature engineering organisations have spent the past several years building — detailed tagging, per-team cost allocation, granular usage dashboards — mean that CFOs and engineering leaders now have genuinely accurate visibility into what specific workloads actually cost, rather than a single opaque monthly total. That visibility is precisely what makes the repatriation conversation possible: you cannot make an informed decision to move a workload off the cloud if you never had clear enough data to know what that workload was costing you in the first place.

High-profile outages made the “the cloud is more reliable than what I could build myself” argument harder to make with a straight face. The Cloudflare outage of November 2025, caused by a bug in its Bot Management system, rendered a significant portion of the internet’s dependent services inaccessible. AWS’s us-east-1 region has experienced recurring degradation events through late 2024 and 2025 affecting major streaming and consumer platforms. These incidents do not prove that on-premises infrastructure is inherently more reliable — a poorly run data centre is certainly less reliable than a well-run hyperscaler region — but they meaningfully weakened the assumption that “the cloud” as a category is simply, unconditionally more reliable than any alternative, which was one of the founding justifications for cloud-first strategy in the first place.

Regulatory and data sovereignty pressure genuinely intensified. The EU’s NIS2 Directive and various national data protection frameworks have pushed some organisations — particularly in regulated industries and specific jurisdictions — toward infrastructure choices that guarantee data remains under clear local legal jurisdiction, rather than technically residing in a regional data centre while remaining subject to laws like the US CLOUD Act, under which data hosted with US-owned hyperscalers can, in certain circumstances, be subject to US legal process regardless of where it is physically stored.

AI workloads changed the cost equation for compute-intensive teams specifically. Organisations running AI training or inference workloads consistently, rather than in short bursts, are increasingly finding that dedicated on-premises or colocated GPU infrastructure is more cost-effective than sustained premium hyperscaler rates for equivalent compute, while also providing tighter control over proprietary training data and model weights — a consideration that has become substantially more commercially significant as AI capability itself has become a competitive differentiator.

The Workload Profiling Framework

The single most important analytical tool in this entire conversation is workload profiling — sorting your infrastructure by traffic predictability, because that single variable determines almost everything else about whether repatriation makes sense for a given workload.

Highly predictable, consistently loaded workloads are the strongest repatriation candidates. Large databases with steady query volume, core business applications with well-understood usage patterns, data-intensive analytics platforms running on a predictable schedule, and storage-heavy systems where you can forecast next quarter’s volume with reasonable confidence. These workloads let you buy or lease exactly the capacity you need, rather than paying a premium for elasticity you are not using. If your traffic is consistent — streaming delivery, a stable SaaS product, a data warehouse — bare metal or colocation genuinely tends to win on raw economics.

Highly variable, spiky, or unpredictable workloads should generally stay in the public cloud. If your traffic spikes by an order of magnitude for a single event once a year, or if you are a startup whose growth trajectory could plausibly 3x in the next two quarters, the elasticity the public cloud provides is worth its premium. Repatriating a workload with genuinely unpredictable demand, and then discovering you have under-provisioned your own hardware during a critical traffic spike, is a considerably worse outcome than an expensive but reliably elastic AWS bill.

Development, testing, and experimentation environments almost always belong in the public cloud regardless of your production repatriation strategy. The value of instant provisioning and instant teardown for these environments outweighs the cost savings of dedicated hardware that sits partially idle between test runs.

Disaster recovery and burst capacity frequently remain cloud-based even in organisations that have repatriated their primary production workloads, because paying for elastic standby capacity that activates only during a genuine failover event is exactly the use case the public cloud pricing model rewards.

The practical exercise: pull twelve months of traffic and cost data for your major workloads, plot predictability against cost, and you will very quickly see which workloads cluster into “should probably be repatriated” and which cluster into “the elasticity premium is earning its keep.”

What Actually Gets Repatriated — And What Stays

Based on the pattern across the case studies and data in this research, here is the honest breakdown of what is actually moving and what is not.

Moving to owned or colocated infrastructure: Large, stable storage volumes where S3-equivalent pricing compounds significantly over time. Core relational and analytical databases with predictable query patterns. Long-running compute-intensive workloads, particularly sustained AI training or inference. Internal business applications with stable, well-understood usage across the organisation.

Staying in the public cloud: Customer-facing web applications with genuinely fluctuating traffic. Development and testing environments. Disaster recovery and failover capacity. New product experimentation where usage patterns are not yet established. Global, multi-region applications where hyperscaler edge presence is difficult to replicate independently.

The resulting architecture for most organisations pursuing this strategy in 2026 is not a full exit — it is a deliberate hybrid split, keeping the public cloud for what it does best (elasticity, global reach, rapid experimentation) while moving the predictable, high-volume, storage-heavy core onto infrastructure with a fundamentally different cost structure.

The Talent Gap Nobody Wants to Admit

This is the section that deserves more attention than it typically gets in repatriation discussions, because it is where genuinely well-intentioned repatriation projects go wrong.

Modern DevOps teams are frequently cloud-native but comparatively infra-illiterate in a specific, uncomfortable sense: an engineer who can spin up a production-grade EKS cluster through Terraform in fifteen minutes may have limited direct experience deploying a highly available Kubernetes cluster on raw Ubuntu servers with manually configured network partitioning, storage provisioning, and hardware-level redundancy. The public cloud’s core value proposition was always abstracting away exactly this layer of expertise — and a decade of that abstraction means the expertise it replaced has, in many organisations, quietly atrophied or never been built in the first place.

This is not a criticism of the engineers involved. It reflects a rational allocation of learning time over the past decade, when the public cloud genuinely was the default and building deep bare-metal expertise offered a comparatively low return relative to becoming excellent at cloud-native tooling. But it means that repatriation is not simply a matter of moving workloads and expecting your existing team to operate them the way they operated EKS or RDS. Successful repatriation requires either building genuine systems, networking, and hardware expertise internally, or engaging a managed provider that supplies that expertise as a service — and organisations that skip this step and assume their cloud skills transfer directly tend to be the ones producing the cautionary tales that get cited by cloud-repatriation sceptics.

The honest recommendation: before committing to any meaningful repatriation project, audit your team’s actual comfort level with the specific operational layer you would be taking on — Linux administration at the hardware level, physical or virtualised networking configuration, storage array management, hardware capacity planning — separately from their cloud-native Kubernetes and Terraform skills. These are related but genuinely distinct skill sets, and conflating them is the single most common cause of repatriation projects that underdeliver on their promised savings.

Calculating Real Total Cost of Ownership

The comparison that actually matters is never “AWS bill versus hardware cost.” It is total cost of ownership on both sides, calculated honestly.

On the cloud side, your real TCO includes compute, storage, data transfer and egress fees, the licensing costs for managed services you depend on, and — the figure most commonly underweighted — the ongoing engineering time your team spends on cloud cost optimisation, rightsizing, and vendor-specific tooling that would not be needed on a simpler cost model.

On the repatriation side, your real TCO includes hardware acquisition or lease costs, colocation or data centre facility costs, the network connectivity and bandwidth you now need to provision directly, the operational staffing or managed-service cost of running the hardware layer, and the one-time migration engineering cost — which is real, often underestimated, and needs to be amortised honestly across the projected savings period rather than ignored.

A defensible evaluation walks through: identify workloads with high data transfer volume or consistent, predictable compute and storage demand as your repatriation candidates. Calculate the current TCO for those specific workloads on your cloud provider, including every fee category above, not just the headline compute cost. Calculate the projected TCO on your target infrastructure, including hardware, software, colocation, and the operational staffing or managed-service cost required to run it. Determine the break-even point honestly, accounting for the one-time migration cost as an upfront cost against future savings, not as a sunk cost you can ignore.

If that honest comparison still shows a 25%+ reduction — which is what the majority of organisations pursuing this seriously are reporting — the case is real. If the comparison only looks favourable when you exclude engineering time, migration cost, or ongoing operational staffing, you have not actually found savings. You have found a cost that has moved from one line item to another.

The Hybrid Reality — Why Full Exits Are Rare

I want to correct a framing that shows up constantly in repatriation coverage, because it distorts the actual decision most teams are facing.

Full cloud exits are genuinely rare — only 8 to 10 percent of organisations pursuing repatriation are doing anything close to a complete departure from public cloud infrastructure. The dominant pattern, adopted by roughly 70% of businesses pursuing this strategy, is a deliberate hybrid split: public cloud for workloads with variable demand, customer-facing applications with fluctuating traffic, and disaster recovery capacity; private infrastructure for stable, predictable, high-volume workloads like core databases and storage-heavy analytics.

This also resolves an apparent contradiction that trips people up: Azure’s revenue is reportedly growing at roughly 33% and GCP at roughly 35%, at the same time that 80% of enterprises report they are repatriating some workloads. Both figures are accurate simultaneously, because they are not measuring the same thing. New cloud-native companies continue to launch and adopt hyperscalers for the first time, AI-driven demand is pushing total cloud spend upward across the industry, and existing customers are optimising the placement of their specific workloads rather than reducing their total cloud usage to zero. The hyperscalers keep growing while a meaningful fraction of their existing customer base simultaneously moves specific, well-understood workloads elsewhere. This is not contradictory. It is the market maturing past the “move everything, always” dogma of the 2010s cloud-first era into a more deliberate, workload-by-workload “cloud-appropriate” model.

The practical implication for your own planning: do not frame this decision as “should we leave the cloud?” Frame it as “which of our specific workloads are we running on the wrong infrastructure for their actual traffic and cost profile?” That framing produces a genuinely useful hybrid strategy. The binary framing produces either an unjustified full migration or, more commonly, no action at all because the binary question feels too large and risky to answer.

A Practical Repatriation Evaluation Framework

If you want to run this evaluation properly for your own infrastructure, here is the sequence that reflects best practice across the case studies in this research.

Step 1 — Instrument before you decide anything. You need genuine per-workload cost visibility before this conversation can be productive. If you cannot currently answer “what does Service X actually cost us per month, including its share of data transfer and storage,” build that visibility first.

Step 2 — Profile workloads by predictability, not by size. The largest workload in your infrastructure is not automatically your best repatriation candidate. The most predictable one is. Pull twelve months of traffic data and separate your workloads into stable-and-predictable versus variable-and-bursty.

Step 3 — Calculate honest TCO for your top repatriation candidates. Include the real cost of hardware or colocation, the migration engineering effort, and the ongoing operational staffing or managed-service cost — not just the headline hardware price against the headline AWS bill.

Step 4 — Honestly assess your team’s operational readiness. Do you have, or can you realistically acquire, the systems and networking expertise the target infrastructure requires? If the answer is no and the timeline to build it is longer than your patience for the migration, factor a managed provider into your cost model rather than assuming your cloud-native team will absorb the gap.

Step 5 — Pilot with a single, well-understood workload before committing broadly. Choose the workload that scored highest on predictability and lowest on migration risk. Run it in parallel on both platforms if feasible. Validate your TCO projections against real operational data before expanding the strategy.

Step 6 — Plan for hybrid, not for a cliff-edge exit. Even organisations targeting an eventual full departure, like 37signals, executed the migration in stages over an extended period rather than as a single cutover. Build your plan around incremental, verifiable steps.

What This Means for Your DevOps Career

I want to end on a note that is specifically relevant to engineers reading this rather than just to engineering leadership making platform decisions, because this trend has a genuine career implication.

Cost awareness is no longer a CFO-only concern that DevOps engineers can safely delegate upward. It has become a core engineering competency in its own right, on the same level as understanding Kubernetes networking or CI/CD pipeline design. Engineers who can speak fluently to both the cloud-native and the bare-metal sides of an infrastructure decision — who understand what a Kubernetes cluster looks like on managed EKS versus Docker Swarm-style simplicity or on raw hardware with manually configured networking — are becoming measurably more valuable than engineers who are fluent only in the cloud-native abstraction layer.

This connects directly to something worth taking seriously if you are early or mid-career in DevOps right now: the skillset is shifting from pure cloud optimisation toward genuine hybrid architecture literacy. The engineers who invested the last decade exclusively in learning managed cloud services, without maintaining any underlying systems and networking fundamentals, may find themselves at a disadvantage relative to engineers who kept at least a working knowledge of what is actually happening underneath the cloud abstraction. This is not a call to abandon Kubernetes or Terraform expertise — those remain essential regardless of where the underlying infrastructure lives. It is a call to make sure the layer beneath them has not atrophied entirely.

Final Thought

Cloud repatriation in 2026 is not a referendum on whether AWS, Azure, or GCP are good products. They are, by most objective measures, extraordinarily capable platforms, and they remain the right choice for a large and legitimate category of workloads — variable traffic, global reach requirements, rapid experimentation, and teams that genuinely lack the capacity or interest to operate hardware directly.

What has changed is that engineering organisations now have a decade of real operational and billing data that did not exist when the “cloud-first, move everything” strategy was first adopted as industry dogma. That data is revealing, with increasing consistency across independent surveys and individual case studies, that a meaningful portion of predictable, storage-heavy, steady-state workloads were placed on the most expensive possible infrastructure for their actual usage pattern — not because anyone made a bad decision at the time, but because the analytical tools to make a more granular decision simply were not mature enough yet.

The companies handling this well in 2026 are not the ones dogmatically defending “cloud-first” as an unquestionable strategy, and they are not the ones naively assuming that deleting an AWS account solves every infrastructure problem. They are the ones doing the workload-by-workload analysis that should probably have been standard practice from the beginning, and building the hybrid architecture that places each workload on the infrastructure its actual cost and traffic profile deserves.

That is not a step backward from cloud-native engineering. It is what cloud-native engineering looks like once it grows up.

Keep Reading

These articles connect directly to the cost optimisation and infrastructure topics covered above:

• I Deleted Our Terraform State File at 4 PM on a Friday — the Infrastructure as Code discipline that matters equally whether you run on AWS or bare metal
• GitOps vs Traditional CI/CD in 2026 — deployment patterns that transfer directly to hybrid and on-premises infrastructure
• I Stopped Instrumenting My Code — eBPF Now Watches Everything My Kubernetes Cluster Does — the observability foundation you need before making any infrastructure placement decision
• AWS Lambda Cold Starts Are Now Costing You Money — the kind of granular cost analysis that this entire repatriation trend depends on
• Kubernetes vs Docker Swarm in 2026 — orchestration choices that matter differently depending on whether you are running managed or self-hosted infrastructure
• DevOps Roadmap for 2026: From CI/CD to Platform Engineering — where hybrid infrastructure literacy fits into a modern DevOps career

If this gave you a genuinely useful framework for evaluating your own infrastructure — follow me. I write every week on DevOps, Kubernetes, AWS, FinOps, and platform engineering. Real data. Honest trade-offs. No cloud dogma in either direction.

Tags: Cloud Repatriation, AWS, DevOps, FinOps, Cloud Computing, Platform Engineering, Cloud Cost Optimization, Hybrid Cloud, Infrastructure, Azure, GCP, Cloud Engineering, DevOps 2026, Software Engineering