Cloud Repatriation: A Practical Guide to Moving Workloads Off the Public Cloud
There is a growing counter-movement in infrastructure. After a decade of “move everything to the cloud,” companies are pulling workloads back to dedicated servers and bare metal. The industry calls it cloud repatriation — and it is driven by one thing: money.
The pattern is consistent. A company migrates to AWS or GCP during its growth phase, when the elasticity of the public cloud genuinely helps. Two or three years later, the workloads have stabilized, the team knows exactly how much compute they need, and the cloud bill has become the second or third largest line item on the P&L. Someone in finance finally asks the question that infrastructure teams have been avoiding: why are we paying this much for servers?
This guide covers what cloud repatriation is, when it makes financial sense, when it does not, and how to execute a migration from public cloud to dedicated infrastructure without breaking production. We include real cost comparisons in both USD and INR, and we are transparent about the trade-offs — because we manage both AWS infrastructure and our own bare metal servers, and we think the honest answer is usually “it depends on the workload.”
What Cloud Repatriation Actually Means
Cloud repatriation is the process of moving workloads from a public cloud provider (AWS, Azure, GCP) back to infrastructure you control — typically dedicated servers, bare metal, or a private cloud running on collocated hardware. It is not about abandoning the cloud entirely. It is about recognizing that some workloads cost dramatically less on dedicated hardware and moving those specific workloads while keeping the rest on the public cloud.
The term gained mainstream attention when Basecamp’s DHH publicly documented 37signals’ move off AWS. Their numbers were stark: cloud spend of roughly $3.2 million per year, replaced by approximately $840,000 in owned and collocated hardware. That is roughly a 75% cost reduction. Over a projected five-year period, the savings amounted to approximately $7 million.
They were not alone. Dropbox completed a much larger repatriation years earlier, moving the majority of its storage infrastructure from AWS to custom-built servers in leased data centers. The reported savings exceeded $75 million over two years. More recently, companies across SaaS, fintech, and e-commerce have quietly executed similar moves, often without the public fanfare.
The common thread is straightforward: once you know your infrastructure needs, the public cloud’s per-unit economics work against you. You are paying a premium for flexibility you no longer need.
Why Companies Are Repatriating: The Economics
Public cloud pricing follows a simple model: you pay for convenience, elasticity, and managed services. That premium is justified when your workloads are unpredictable, when you are scaling rapidly and do not know next quarter’s compute needs, or when you need managed services (RDS, Lambda, SQS) that would take months to replicate in-house.
But cloud pricing has three structural problems that worsen over time:
1. The Utilization Tax
AWS EC2 instances are priced for on-demand flexibility, but most production workloads run 24/7 at relatively stable utilization. You are paying on-demand rates (or at best, reserved instance rates) for hardware that a dedicated server provider can deliver at a fraction of the cost because they are not building in the elasticity premium.
Consider a concrete comparison:
| Resource | AWS (m5.xlarge, Mumbai) | ZenoCloud Dedicated (Equivalent) |
|---|---|---|
| CPU | 4 vCPU | 12 vCPU (Xeon E-2136) |
| RAM | 16 GB | 32 GB DDR4 |
| Storage | 100 GB gp3 EBS | 2 x 480 GB SSD |
| Bandwidth | 2 TB transfer | 2 TB @ 1 Gbps |
| Monthly cost | ~INR 15,000 ($180) | INR 10,900 ($149) |
The dedicated server is cheaper per month and delivers three times the CPU, double the RAM, and nearly ten times the storage. The AWS instance is a fraction of a shared physical server. The dedicated server is the entire machine.
When you multiply this across 10, 20, or 50 instances, the gap becomes enormous. A company running 20 m5.xlarge equivalents on AWS is spending roughly INR 3,00,000 per month. The same capacity on dedicated servers costs approximately INR 2,18,000 — and you get significantly more headroom per server.
2. The Data Transfer Trap
AWS charges for data transfer out of its network. At scale, this becomes a significant hidden cost. If your application serves large files, streams media, distributes software updates, or runs a CDN origin, egress charges alone can add 15-30% to your monthly bill. Dedicated servers typically come with a generous bandwidth allocation (2-5 TB at 1 Gbps) with no per-GB egress fees.
3. The Managed Services Lock-In
AWS managed services (RDS, ElastiCache, SQS, Lambda, DynamoDB) are convenient but expensive. RDS for a db.r5.xlarge PostgreSQL instance costs roughly INR 45,000/month in Mumbai. Running PostgreSQL on a dedicated server with equivalent specs costs a fraction of that — because you are not paying Amazon’s managed service margin. The trade-off is that you manage PostgreSQL yourself (or your hosting provider manages it for you), but for mature engineering teams, this is not a significant burden.
When Cloud Repatriation Makes Sense
Not every workload should be repatriated. The economics favor moving back to dedicated infrastructure when specific conditions are met.
Predictable, Stable Workloads
If your compute needs are consistent week to week — web application servers, database servers, background job processors, internal tools — you gain nothing from cloud elasticity. You are paying a premium for a capability you do not use. These workloads are the primary candidates for repatriation.
High Compute or Storage Density
Workloads that consume significant CPU, RAM, or storage benefit the most from dedicated hardware. Machine learning training and inference, video transcoding, large databases, data warehouses, and storage-heavy applications all fall into this category. The per-unit cost advantage of dedicated hardware is most pronounced at high resource consumption.
Data Sovereignty and Compliance
Regulated industries (fintech, healthcare, government) often face requirements about where data is stored and who has physical access to the hardware. Dedicated servers in a known data center with documented physical security controls can simplify compliance in ways that cloud shared-tenancy cannot.
High Bandwidth Requirements
Applications that serve significant outbound traffic — content delivery origins, media streaming, software distribution, API platforms with large response payloads — save dramatically on dedicated infrastructure where bandwidth is included or charged at a flat rate rather than per-gigabyte.
Established Engineering Teams
Cloud repatriation requires infrastructure competence. You need engineers (or a managed hosting partner) who can handle OS configuration, security patching, monitoring, backup, disaster recovery, and capacity planning. If your team already manages production infrastructure confidently, the operational overhead of dedicated servers is manageable.
When Cloud Repatriation Does Not Make Sense
There are genuine scenarios where the public cloud is the right choice, and repatriating would be a mistake.
Highly Variable or Bursty Traffic
If your traffic swings 5x or 10x between off-peak and peak hours, auto-scaling on the public cloud is genuinely valuable. A flash sale, viral social media post, or seasonal traffic spike can be absorbed by cloud auto-scaling in ways that fixed dedicated infrastructure cannot match without significant over-provisioning.
Global Distribution Requirements
If you need to serve users from 15 regions simultaneously with low latency, the public cloud’s global footprint is hard to replicate. Building out dedicated infrastructure in Mumbai, Singapore, Frankfurt, Virginia, and Sao Paulo is possible but operationally complex and capital-intensive.
Heavy Reliance on Managed Services
If your architecture is deeply integrated with AWS-native services — Lambda functions, Step Functions, DynamoDB, SQS, SNS, Kinesis, SageMaker — the migration cost is not just about moving servers. It is about replacing managed services with self-managed equivalents (or third-party alternatives), which can take months and introduce risk.
Early-Stage Companies
If you are still figuring out product-market fit and your infrastructure needs change quarterly, the cloud’s flexibility is worth the premium. Repatriation makes sense for companies with at least 12-18 months of stable infrastructure patterns to analyze.
Small Cloud Spend
If your total cloud bill is under INR 50,000 per month, the absolute savings from repatriation are unlikely to justify the migration effort. The economics become compelling at INR 1,50,000+ per month, where the percentage savings translate to meaningful absolute numbers.
The Hybrid Approach: Best of Both Worlds
The most practical cloud repatriation strategy is not “move everything off AWS.” It is a hybrid approach that puts each workload on the infrastructure where it is most cost-effective.
What Stays on the Cloud
- Bursty workloads. Auto-scaling groups, serverless functions, anything with unpredictable traffic patterns.
- Global edge services. CDN, DNS, DDoS protection, edge compute.
- Managed services you genuinely depend on. If RDS, ElastiCache, or SQS are deeply integrated and the team does not want to self-manage equivalents, keep them.
- Dev/staging environments. Spin up on demand, tear down when not needed. This is exactly what the cloud is built for.
- Disaster recovery. Use the cloud as a secondary DR site for your dedicated infrastructure. On-demand DR capacity that you only pay for when activated.
What Moves to Dedicated
- Application servers running at consistent utilization.
- Primary databases with known capacity requirements.
- Background job processors running 24/7 workloads.
- CI/CD build servers that run continuously.
- Storage-heavy services — file storage, media processing, backup repositories.
- Internal tools — monitoring, logging, admin dashboards, internal APIs.
The hybrid model gives you the cost advantage of dedicated hardware for predictable workloads while retaining cloud flexibility where it genuinely matters. Most companies that execute a thoughtful repatriation end up with 60-80% of their compute on dedicated infrastructure and 20-40% remaining on the public cloud.
Cost Comparison: A Real-World Scenario
Let us model a mid-sized SaaS company running a typical production stack.
Current Setup on AWS (Mumbai Region)
| Component | AWS Service | Monthly Cost (INR) |
|---|---|---|
| 4 application servers | m5.xlarge (reserved, 1yr) | 42,000 |
| 1 primary database | db.r5.xlarge RDS PostgreSQL | 45,000 |
| 1 read replica | db.r5.large RDS PostgreSQL | 28,000 |
| 1 Redis cache | cache.r5.large ElastiCache | 22,000 |
| Background workers (2 instances) | m5.large (reserved) | 16,000 |
| Load balancer | ALB | 5,000 |
| Storage (500 GB EBS + S3) | gp3 + S3 | 8,000 |
| Data transfer (2 TB out) | Egress | 12,000 |
| CloudWatch monitoring | Logs + Metrics | 6,000 |
| Total | 1,84,000 |
After Repatriation (Hybrid)
| Component | Infrastructure | Monthly Cost (INR) |
|---|---|---|
| 2 dedicated servers (app + workers) | ZenoCloud Dual Xeon E5-2640, 64GB | 57,800 |
| 1 dedicated server (database + Redis) | ZenoCloud Dual Xeon E5-2673, 128GB | 38,900 |
| Load balancer + SSL | Included with managed hosting | 0 |
| Storage (included SSDs + backup) | Included | 0 |
| Bandwidth (2 TB included per server) | Included | 0 |
| 24/7 monitoring + management | Included | 0 |
| AWS (staging + DR + CDN) | Reduced AWS footprint | 25,000 |
| Total | 1,21,700 |
Monthly savings: INR 62,300 (34% reduction) Annual savings: INR 7,47,600
And this is a conservative estimate. The dedicated servers in this scenario provide significantly more raw compute than the AWS instances they replace. In practice, you often consolidate four or five cloud instances onto two dedicated servers because each dedicated server delivers so much more CPU, RAM, and storage than a single cloud VM.
The Migration Process
Moving production workloads from AWS to dedicated servers is not a weekend project. Here is the process we use with our clients.
Phase 1: Assessment (Week 1-2)
Audit your current cloud infrastructure. For each service and instance, document: what it does, how much compute it uses (actual utilization, not provisioned), its dependencies, its traffic patterns, and whether it uses any cloud-native services that would need replacement.
We use your AWS Cost Explorer data, CloudWatch metrics, and architecture diagrams to build a complete picture. The output is a workload classification: each service gets tagged as “repatriate,” “keep on cloud,” or “needs further analysis.”
Phase 2: Architecture Design (Week 2-3)
Design the target architecture on dedicated infrastructure. This includes server sizing, network topology, storage layout, backup strategy, monitoring setup, and the hybrid connectivity between your new dedicated servers and any services remaining on AWS (typically a VPN or direct connect).
Phase 3: Build and Test (Week 3-5)
Provision the dedicated servers. Install and configure the operating system, application stack, databases, and monitoring. Replicate your production data. Run load tests to verify that the new infrastructure handles your traffic profile.
This runs in parallel with your existing AWS infrastructure. Nothing touches production yet.
Phase 4: Migration (Week 5-7)
Execute the migration in stages. Start with the lowest-risk workloads — internal tools, background workers, staging environments. Monitor everything. Once you are confident in the new infrastructure, migrate the application servers. The database migration comes last, typically during a maintenance window with a tested rollback plan.
Phase 5: Optimization and Decommission (Week 7-10)
Fine-tune the new infrastructure based on real production data. Optimize database configuration, tune web server settings, adjust monitoring thresholds. Once everything is stable and the old AWS resources have been idle for at least two weeks, decommission them.
Total timeline: 8-10 weeks for a clean migration with no downtime.
The ZenoCloud Angle: We Will Tell You the Truth
Here is what makes our position unusual in this conversation: we manage both AWS infrastructure and our own bare metal servers. We have certified AWS architects on staff. We also own and operate dedicated servers across data centers in India and the US.
We do not have a financial incentive to push you toward one or the other. If AWS is genuinely the right fit for your workload — because you need global distribution, heavy managed services usage, or extreme burst capacity — we will tell you that and help you optimize your AWS spend instead of repatriating.
If your workloads are stable, predictable, and better suited to dedicated infrastructure, we will tell you that too — and we will handle the migration, management, monitoring, and support so you do not need to build an infrastructure team.
Most companies we work with end up in the hybrid model: dedicated servers for the heavy lifting, AWS for the elastic and globally distributed components. The key is having a partner who understands both sides and optimizes for your total cost, not their revenue.
Common Concerns (and Honest Answers)
“What about reliability? AWS has multiple availability zones.” Dedicated servers can achieve the same availability with proper architecture: redundant servers across multiple racks or data centers, automated failover, real-time replication. A well-architected dedicated setup with a managed hosting provider delivers comparable uptime. We maintain 99.99% uptime SLAs on managed dedicated infrastructure.
“We do not have the team to manage servers.” That is exactly what managed hosting solves. ZenoCloud handles OS updates, security patches, monitoring, backup, disaster recovery, and 24/7 incident response. Your team interacts with the servers the same way they interact with cloud instances — SSH access, deployment pipelines, CI/CD integration — but without managing the underlying infrastructure.
“What if we need to scale up quickly?” Dedicated servers do not provision in 30 seconds like cloud VMs. Typical provisioning is 4-24 hours. For anticipated growth, capacity planning ahead of time is essential. For unexpected spikes, the hybrid approach covers you: keep auto-scaling cloud capacity as a burst layer while running steady-state on dedicated hardware.
“Is this just going back to the old way of doing things?” No. Modern dedicated hosting is not the colo nightmare of 2008. You get bare metal performance with cloud-like management — API-driven provisioning, automated monitoring, infrastructure-as-code compatibility, and managed services layered on top. The operational experience is closer to cloud than it is to traditional hosting.
Who Should Consider Cloud Repatriation
The strongest candidates for cloud repatriation share these characteristics:
- Monthly cloud spend above INR 1,50,000 ($1,800) and growing
- Workloads running at 40%+ average utilization around the clock
- Predictable traffic patterns with limited burst requirements
- Engineering team comfortable with standard DevOps practices
- Data residency requirements (especially India-based companies needing India-hosted infrastructure)
- High storage or bandwidth consumption driving up cloud costs
If three or more of these apply to you, cloud repatriation is worth modeling with real numbers from your specific infrastructure.
Next Step: Free FinOps Audit
We offer a complimentary FinOps audit that compares your current cloud spend against equivalent dedicated infrastructure. We analyze your AWS Cost Explorer data, CloudWatch utilization metrics, and architecture to produce a side-by-side cost comparison for your specific workloads — not generic estimates.
The audit identifies which workloads are candidates for repatriation, which should stay on the cloud, and what the realistic monthly savings would be after migration.
No commitment, no sales pitch. Just numbers. If the numbers say AWS is cheaper for your workloads, we will tell you that.
Request your free FinOps audit — send us your monthly cloud spend and a brief description of your infrastructure, and we will schedule a 30-minute review with our infrastructure team.