Cloud Repatriation: When Returning from the Cloud Makes Sense
TL;DR Cloud repatriation describes the partial return of workloads from the public cloud. 37signals (Basecamp) saved $7 million over five years by exiting the cloud. Stable, predictable workloads with high data volume …
TL;DR
- Cloud repatriation describes the partial return of workloads from the public cloud.
- 37signals (Basecamp) saved $7 million over five years by exiting the cloud.
- Stable, predictable workloads with high data volume are the best candidates.
- Repatriation is not an anti-cloud statement, but rational cost optimization.
- Most companies land on a hybrid model: cloud for variable loads, on-premise for baseline.
The cloud promised lower costs, unlimited scalability, and operational simplicity. For many workloads, that’s true. For some, it isn’t. An increasing number of companies are bringing certain workloads back – not out of cloud skepticism, but based on cold, hard math. Cloud repatriation isn’t a step backward; it’s a sign that cloud strategy is maturing.
Why companies are bringing workloads back
The most prominent example: 37signals (Basecamp, HEY) left AWS and saved $7 million over five years, according to CTO David Heinemeier Hansson. The reason? Stable workloads with predictable demand and high data volume – exactly the profile where cloud costs lose out against dedicated hardware.
The math is simple: A server with 128 GB RAM and 2 TB NVMe costs a one-time €5,000-€8,000 and runs for five years. The cloud equivalent costs €500-€1,000 per month – amounting to €30,000-€60,000 over the same period. With stable demand, owning hardware is five to ten times cheaper.
Add data egress fees: AWS charges $0.09 per GB of outbound traffic. Companies transferring terabytes per month pay thousands – just for networking.
Which workloads are suitable for repatriation
Stable baseline workloads with predictable demand: databases, build servers, monitoring systems. Here, the cloud offers no scaling advantage – only ongoing costs.
Data-heavy workloads with high storage and transfer volume: video encoding, big data analytics, backup systems. Data egress fees make the cloud disproportionately expensive.
Latency-sensitive workloads that must run close to the data source: edge computing, IoT processing, local AI inference.
Unsuitable candidates include: variable workloads (seasonal business), global applications (multi-region), startups in growth phase (unpredictable scaling), and teams without ops expertise.
The hidden costs of returning
Repatriation isn’t free. Total Cost of Ownership (TCO) includes: hardware procurement, colocation costs (rack, power, cooling, network), personnel for operation and maintenance, software licenses (VMware, backup, monitoring), and one-time migration expenses.
The critical factor is personnel: a qualified Linux administrator or network engineer costs €70,000-€100,000 per year. Companies without existing ops capacity must factor in these costs. 37signals already had an established ops team – that’s not a given.
The hybrid compromise
The reality for most companies: neither fully in the cloud nor fully on-premise, but a hybrid model. Stable baseline workloads on dedicated hardware (colocation or on-premise), variable workloads and burst capacity in the cloud.
Kubernetes makes this hybrid approach practical: workloads are portable between on-premise and cloud. Tools like Rancher, Anthos, and Azure Arc enable unified management across both environments. GitOps with ArgoCD deploys the same code everywhere.
Decision framework: Cloud, Hybrid, or Repatriation?
Three questions determine the answer: How variable is the demand? Variable load → cloud. Stable load → on-premise feasible. How high is the data volume? High egress volume → on-premise more attractive. Low volume → cloud costs acceptable. Do we have ops expertise? No ops team → cloud (your cloud provider is your ops team). Experienced team → repatriation becomes calculable.
The decision should be workload-specific, not blanket. Even 37signals didn’t move everything out of the cloud – only the workloads where the math was clear.
Frequently Asked Questions
Is cloud repatriation a trend or a niche?
It’s a growing trend, but not a mass movement. Most companies optimize their cloud usage rather than return completely. Partial repatriation – bringing back individual workloads – is more common than full cloud exits. Analysts estimate that 10-15% of cloud workloads will be repatriated in the medium term.
How do you calculate TCO for cloud vs. on-premise?
Compare all costs over five years: cloud (compute + storage + egress + support) vs. on-premise (hardware + colocation + personnel + licenses + maintenance + migration). Crucially, include opportunity costs – time the team spends on infrastructure instead of product development.
Are there lock-in risks when returning?
Yes, especially with cloud-native services (Lambda, DynamoDB, BigQuery). Workloads based on proprietary services require rewriting onto open-source alternatives before repatriation. Kubernetes-based workloads are significantly more portable.
Can small businesses benefit from repatriation?
Rarely. Small businesses typically lack both the ops capacity and the volume to run their own hardware economically. Managed services from cloud providers offer SMEs better value. Repatriation usually only pays off with monthly cloud spending of €50,000+.
What’s the difference between repatriation and hybrid cloud?
Repatriation means moving existing cloud workloads back to your own infrastructure. Hybrid cloud is an architectural pattern where workloads are intentionally distributed across cloud and on-premise environments. Repatriation often leads to a hybrid model – but not every hybrid strategy involves repatriation.
Header Image Source: Pexels / panumas nikhomkhai
