For the past decade, the dominant message from the tech industry has been clear: move everything to the cloud. AWS, Azure and GCP have spent billions on marketing to convince businesses that migrating to the public cloud is synonymous with modernisation, agility and savings. And in many cases, they are right. But not always.
A growing trend is shaking the industry: cloud repatriation. Companies that migrated to AWS or Azure are moving partially or fully back to their own infrastructure, whether on-premise or colocation. This is not a technological step backwards, but a strategic decision based on financial and operational data.
According to a study by Andreessen Horowitz titled The Cost of Cloud, a Trillion Dollar Paradox, companies could save between 30% and 50% by repatriating stable workloads from the public cloud to their own infrastructure. This is not a fringe opinion: it is an analysis backed by one of the most influential venture capital firms in the world.
What Is Cloud Repatriation
Cloud repatriation is the process of moving workloads, applications or data from a public cloud (AWS, Azure, GCP) back to your own infrastructure: whether dedicated servers in a data centre, colocation or a managed private cloud.
It does not necessarily mean abandoning the cloud entirely. In most cases, repatriation is selective: workloads that do not benefit from the cloud model (stable, predictable, with high resource consumption) are identified and migrated to dedicated infrastructure, while variable workloads, development environments or services requiring global scalability remain in the public cloud.
The result is an optimised hybrid model: each workload runs where it delivers the best performance-to-cost ratio. Not everything in cloud, not everything on-premise, but the intelligent combination of both.
Why Companies Are Repatriating
The decision to repatriate does not come from a whim, but from real problems that emerge when the cloud bill grows and the initial enthusiasm fades. These are the most common reasons:
- payments Hidden costs: AWS and Azure bills include charges that are not apparent upfront: egress fees (cost of moving data out), API request charges, snapshot storage, elastic IPs, logs, monitoring and premium support. A bill that started at EUR 2,000/month can reach EUR 8,000 without the workload having changed.
- lock Vendor lock-in: the more you use the hyperscaler's proprietary services (Lambda, DynamoDB, Cosmos DB, Cloud Spanner), the harder and more expensive it is to migrate. Lock-in is not just technical but also contractual and organisational.
- flag Data sovereignty: regulations such as GDPR, ENS, DORA or sector-specific requirements demand knowing exactly where your data resides and who can access it. With a US-based hyperscaler, the answer is not always clear.
- speed Predictable performance: in the public cloud you share infrastructure with other customers (multi-tenant). This can cause variability in latency, IOPS and network performance. A dedicated server provides guaranteed resources without noisy neighbour interference.
- trending_up Non-linear cost growth: the pay-as-you-go model is attractive for variable workloads, but for stable 24/7 workloads (databases, ERP, backend), paying by the hour is significantly more expensive than a fixed monthly cost.
The Cloud Savings Myth
The most repeated sales pitch from hyperscalers is: "you eliminate upfront hardware investment and only pay for what you use". It is true that the public cloud eliminates CapEx, but it converts everything into recurring OpEx, and that OpEx tends to grow over time.
Consider a real-world scenario: a company needs a server with 32 vCPU, 128 GB RAM, 2 TB NVMe storage and 10 TB monthly transfer. On AWS (EC2 m6i.8xlarge, us-east-1), the monthly cost is approximately USD 1,200-1,500 with a 1-year reserved instance. Without a reservation, we are looking at over USD 2,200/month.
The same resource level on a dedicated server or private cloud with a European provider like EasyDataHost can cost between EUR 400-700/month, with traffic included, no egress fees and data located in Spanish territory. Over 3 years, the cumulative difference exceeds EUR 25,000. Over 5 years, it surpasses EUR 45,000.
The "cloud premium":
What you pay extra in the public cloud is not just for compute resources, but for the platform: the management interface, the APIs, the global network, integration with dozens of services and the third-party ecosystem. If your workload does not need those capabilities, you are paying an unnecessary premium.
Cloud vs On-Premise/Colocation: Comparison Table
The following table compares costs and key characteristics between keeping a workload in the public cloud versus migrating it to on-premise or colocation infrastructure. Figures are based on a server equivalent to 32 vCPU, 128 GB RAM, 2 TB NVMe and 10 TB monthly transfer:
| Criterion | Public Cloud (AWS/Azure) | On-Premise / Colocation |
|---|---|---|
| Monthly OPEX | EUR 1,200-2,200 (instance + storage + egress) | EUR 400-700 (dedicated server or private cloud) |
| 3-year TCO | EUR 43,200-79,200 | EUR 14,400-25,200 |
| 5-year TCO | EUR 72,000-132,000 | EUR 24,000-42,000 |
| Control | Limited to provider configuration | Full: hardware, network, security, hypervisor |
| Egress fees | USD 0.08-0.12/GB (adds up quickly) | Included in the rate or no additional cost |
| Latency | Variable, depends on region and saturation | Minimal and consistent, physical proximity |
| Compliance | Depends on hyperscaler certifications | Full control over data location and access |
Signs You Should Repatriate
Not all workloads should be repatriated. But if you recognise several of these signs in your organisation, it is time to run the numbers:
- arrow_right Your cloud bill is growing over 30% per year without your workloads having changed significantly. Hyperscaler price increases, reserved instance renewals and additional services accumulate.
- arrow_right Your workloads are stable and predictable: databases running 24/7, ERP, email systems, application backends. The pay-as-you-go model adds no value if the load is constant.
- arrow_right You need data sovereignty: your industry (finance, healthcare, public sector) requires that data resides within national territory with full control over who can access it.
- arrow_right Performance is insufficient or unpredictable: you experience latency spikes, throttling or the noisy neighbour effect that impacts your critical applications.
- arrow_right Egress fees are a significant part of your bill: if you move large volumes of data out of the cloud (backups, synchronisations, external APIs), data exit costs can represent 20-40% of your total bill.
How to Plan a Cloud Repatriation
A successful repatriation is not improvised. It requires a structured plan that minimises risk and ensures a smooth transition. These are the key steps:
- search 1. Workload assessment: classify each workload by its usage pattern (stable vs variable), dependencies on proprietary cloud services, compliance requirements and data sensitivity. Stable workloads with no strong dependencies are the first candidates.
- calculate 2. Detailed TCO analysis: calculate the total cost of ownership at 3 and 5 years for each workload, both in cloud and on own infrastructure. Include: compute, storage, networking, licences, support, staff and migration costs.
- memory 3. Hardware and infrastructure selection: choose between dedicated servers, private cloud or colocation based on your needs. Size correctly to avoid over-provisioning.
- sync 4. Gradual migration: do not shut down everything in cloud all at once. Migrate workload by workload, starting with the least critical. Validate performance and stability at each phase before proceeding.
- cloud_sync 5. Interim hybrid phase: during the transition, operate in hybrid mode with direct connectivity between your new infrastructure and the public cloud. This enables migration with zero downtime and rollback capability in case of issues.
Key advice:
Do not attempt to repatriate workloads that rely heavily on the hyperscaler's proprietary services (such as AWS Lambda + DynamoDB + SQS). The cost of refactoring may exceed the savings. Focus your efforts on workloads using standard technologies: VMs, containers, PostgreSQL/MySQL databases, file storage.
Case Study: From Cloud to Own Infrastructure
At EasyDataHost we have guided companies through real cloud repatriation processes. One of our most representative cases documents how a company with stable workloads on AWS achieved a 50% reduction in infrastructure costs by migrating to dedicated servers in our Tier III+ datacenter in Madrid.
The migration was executed gradually over 8 weeks, with an interim hybrid phase during which both infrastructures coexisted. The result: same workload, better performance (40% latency reduction, consistent IOPS), full GDPR compliance and data sovereignty within Spanish territory.
You can read the full details in our case study: Cloud to On-Premise Infrastructure, where we describe the methodology, the numbers and the lessons learned.
The Hybrid Model: The Best of Both Worlds
Cloud repatriation does not have to be an all-or-nothing move. In fact, the companies that achieve the best results typically adopt a hybrid model where the core of their infrastructure (databases, ERP, backend, storage) runs on dedicated servers or private cloud, while variable workloads (marketing campaigns, development environments, on-demand data analysis) remain in the public cloud.
This model offers the best of both worlds: fixed and predictable costs for the operational base, on-demand scalability for peaks, and data sovereignty for critical workloads. The key lies in the connectivity between both environments: direct, private interconnection ensures communication is fast, secure and without surprise costs.
The hybrid model also works as a gradual decoupling strategy. Instead of committing indefinitely to a single hyperscaler, you reduce your dependency progressively. If AWS raises prices or changes terms (as has happened repeatedly), your impact is smaller because your core does not depend on them.
Conclusion
The public cloud is an extraordinary tool, but it is not the universal answer. For many companies with stable workloads, cloud repatriation represents an opportunity to reduce costs, improve performance and regain control over their infrastructure and data. The key takeaways from this article:
- arrow_right Hidden costs in the public cloud (egress, storage, APIs, support) can double or triple the initial budget.
- arrow_right The 3-5 year TCO for stable workloads is significantly lower on own infrastructure or colocation than on public cloud.
- arrow_right Repatriation should be selective and gradual: not everything needs to come back from the cloud, but stable workloads are clear candidates.
- arrow_right The hybrid model (core on-prem + burst to cloud) delivers the optimal combination of cost, performance and flexibility.
- arrow_right Data sovereignty and regulatory compliance are additional compelling reasons to repatriate, especially in regulated industries.
At EasyDataHost we help businesses evaluate, plan and execute the repatriation of workloads from the public cloud. Contact our team for a no-obligation TCO analysis of your current infrastructure and we will help you find the perfect balance between cloud and on-premise.