Cloud repatriation stopped being a theory a few years ago. What used to be argued from cost models and architecture diagrams is now backed by named companies publishing real numbers: millions saved, gross margins that jumped, compute costs cut in half. This roundup of enterprise cloud repatriation case studies looks at what actually happened at 37signals, Dropbox, GEICO, and Broadcom when they moved workloads off the public cloud — what triggered the move, what they moved, what it cost to execute, and what it saved. If you're building the business case for your own repatriation project, or just deciding whether one workload is a candidate, Gart's cloud migration engineering team uses exactly this kind of evidence — not vendor marketing — to model the decision.
None of these companies abandoned the cloud outright. Every one of them kept it for the workloads it's genuinely good at — burst capacity, global reach, experimentation — while pulling steady-state, predictable, expensive-at-scale workloads back onto owned or colocated infrastructure. That pattern, not a wholesale cloud exit, is what today's enterprise cloud repatriation case studies actually show.
Why Case Studies Matter More Than Repatriation Theory Right Now
For years, "cloud repatriation" was mostly a hypothetical argued in blog posts and conference talks — the math worked on a spreadsheet, but skeptics could always ask whether it worked in production. That's no longer the objection. According to the Flexera 2026 State of the Cloud Report, enterprises (companies with 1,000+ employees) have already repatriated 21% of their public cloud workloads and data — roughly one in every five workloads that migrated to the cloud has since moved back. That's not a fringe trend; it's a large enough sample that named-company case studies now carry real weight in a CFO or board conversation.
The other reason case studies matter more than general repatriation arguments: every enterprise's cost structure, compliance obligations, and workload mix are different, and a generic "the cloud is expensive" argument doesn't survive contact with a finance team that wants specifics. Named case studies — what a company moved, why, what it cost to execute, and what came back in savings — give engineering leaders a template to run the same analysis against their own environment rather than starting from a blank page.
📊 This is not a mass cloud exodusPublic cloud spending is still growing overall — Gartner forecasts continued double-digit growth in worldwide public cloud expenditure. Repatriation is happening inside that growth, as a rebalancing of which specific workloads sit where, not a reversal of cloud adoption itself.
37signals: The $2M-a-Year Cloud Exit That Started the Conversation
37signals (maker of Basecamp and HEY) had run on AWS since 2006. By 2022, its cloud bill had grown to roughly $3.2 million a year — a steep number for workloads that were stable, predictable, and not actually bursty in the way cloud pricing is optimized for. CTO David Heinemeier Hansson's team ran the numbers and concluded they were paying a large ongoing premium for elasticity they weren't using.
The company replaced AWS EC2 compute with owned Dell servers and swapped expensive EBS network storage for high-performance NVMe arrays, executing the move in stages rather than a single cutover. The results, reported publicly over the following two years, were substantial: monthly cloud spend fell from roughly $180,000 to under $80,000 — about a 60% reduction — after the compute exit alone, and the company reported saving close to $2 million in a single year from cloud repatriation. 37signals projects total savings well over $10 million across five years once the full exit, including the roughly $1.5 million/year S3 storage bill, completes. The move required an upfront hardware purchase, but the payback period was short enough that the company treated it as a routine capital decision rather than a strategic gamble.
37signals' case is useful precisely because it's not a hyperscale internet company — it's a mid-sized SaaS business with steady, forecastable traffic, which describes a large share of the enterprise application portfolio most CTOs manage day to day.
Dropbox: $75 Million Saved and a Gross Margin That Doubled
Dropbox's repatriation predates the current wave by almost a decade, which makes it useful as a long-run data point rather than a hot take. Starting in 2015, Dropbox moved the bulk of its file-storage infrastructure off AWS S3 and onto purpose-built infrastructure across three owned colocation facilities in California, Virginia, and Texas.
The financial results, as reported in Dropbox's own regulatory filings and press coverage, were significant enough to show up in the company's headline financial metrics, not just an infrastructure line item. Dropbox reduced operating expenses by roughly $75 million across the first two years after the migration, netting an estimated $92.5 million in reduced third-party datacenter costs against about $53 million in new owned-infrastructure investment. Gross margin improved from 33% to 67% between 2015 and 2017 — the company attributed this "primarily" to its infrastructure optimization project — and by 2018, AWS usage had dropped to roughly 10% of Dropbox's infrastructure footprint, reserved for burst capacity and specific regional needs rather than core storage.
Dropbox's own engineering leadership framed the decision around control and performance as much as cost: "For us it was about quality and control management," said Dan Williams, then Dropbox's Head of Production — a reminder that repatriation case studies aren't purely a finance story, even when the finance numbers are what make headlines.
GEICO: Repatriating at $300 Million-a-Year Cloud Scale
GEICO's case is instructive for a different reason: scale. The insurer moved over 600 applications to the cloud starting in 2013 and, by 2021, was spending more than $300 million annually across cloud providers without seeing proportional business benefit — particularly on legacy applications that weren't re-architected to actually use cloud-native elasticity.
GEICO's response was to build a homegrown private cloud on Open Compute Project (OCP) open hardware and open-source software, consolidating compute and storage onto a common platform it fully controls. Reported results include a 50% reduction in compute cost per core and more than 60% reduction in cost per gigabyte of storage, compared to running the equivalent workload in public cloud, alongside a stated target of repatriating at least 50% of cloud workloads by 2029 — a multi-year program, not a one-time migration weekend.
GEICO VP Rebecca Weekly summarized the core lesson bluntly: "Just running legacy applications in the cloud is prohibitively expensive." That's a specific and common failure mode — lifting a legacy monolith into cloud VMs without re-architecting it captures none of the cloud's actual cost advantages while still paying its premium.
Broadcom: Pulling Database Workloads Off Public Cloud DBaaS
Broadcom's repatriation case is narrower in scope than 37signals, Dropbox, or GEICO, which makes it a useful example of targeted, workload-specific repatriation rather than an infrastructure-wide exit. The company moved critical database workloads off public cloud database-as-a-service offerings and back onto self-managed infrastructure, reporting savings of over $10 million.
Broadcom's internal analysis, cited across industry coverage of the move, found that a modern private cloud delivers 40-50% lower total cost of ownership than public cloud for steady-state workloads specifically — the same conclusion 37signals and GEICO reached independently, applied here to a single workload category (databases) rather than an entire application portfolio.
🎯 The common thread across all four casesNone of these are "the cloud is bad" stories. Each company kept public cloud for what it does well and moved specifically the workloads that were steady-state, predictable, and large enough in scale that the cloud's flexibility premium stopped paying for itself.
Case Study Comparison: Trigger, Workload, and Result
CompanyPrimary triggerWhat movedReported result37signalsCost — stable workload, paying for unused elasticityCompute (EC2 → owned servers) and storage (EBS → NVMe)~60% lower monthly cloud spend; ~$2M saved in one yearDropboxCost + control over core product infrastructureFile storage (S3 → owned colocation data centers)$75M OpEx saved over two years; gross margin 33% → 67%GEICOCost at scale — legacy apps not benefiting from cloud-native designCompute + storage (public cloud → OCP private cloud)50% lower compute cost/core; 60%+ lower storage cost/GBBroadcomCost — steady-state database workloads on DBaaSDatabases (public cloud DBaaS → self-managed infrastructure)$10M+ saved; 40-50% lower TCO for the workloadCase Study Comparison: Trigger, Workload, and Result
What These Enterprise Cloud Repatriation Case Studies Have in Common
Read across all four, and the same three conditions show up every time a repatriation project actually delivered the projected savings:
The workload was steady-state, not bursty. Every case involved compute, storage, or database workloads with predictable, forecastable utilization — exactly the profile that gets the least benefit from cloud elasticity pricing and the most benefit from owning fixed capacity.
Scale was large enough to amortize the hardware investment quickly. Owning servers only beats renting them once utilization is high and consistent enough, long enough, to clear the upfront capital cost — which is why all four companies were already spending seven or eight figures a year on the workload before moving it.
The team kept public cloud for what it's genuinely good at. None of these companies went all-in on-prem. Burst capacity, secondary regions, and experimentation stayed on public cloud in every case — the repatriation was surgical, not total.
This is the same maturity curve Gart's own cloud repatriation and the hidden cost of elasticity pillar guide describes: repatriation isn't a rejection of cloud strategy, it's what happens once an organization has enough operating history to price workload placement correctly instead of defaulting to "cloud-first" for everything.
Gart Solutions' Own Repatriation-Adjacent Case Studies
The named enterprise examples above are useful for benchmarking, but Gart's own client work shows the same cost-optimization and infrastructure-control patterns at a scale closer to what most mid-market and growth-stage engineering teams are actually working with. In AWS Migration & Infrastructure Localization for a Sportsbook Platform, a multi-region, Infrastructure-as-Code rebuild cut deployment time from 4 hours to 22 minutes while meeting jurisdiction-specific data residency rules — the same "control over where data lives" driver behind Dropbox's and GEICO's moves.
Cutting AWS Costs by 40% for a Music Promotion Platform shows targeted cost optimization on a specific workload rather than a full infrastructure exit, closer in shape to Broadcom's database-only repatriation, while Uncovering Hidden Costs: Optimizing Cloud Storage Operations in Azure is a storage-cost audit that surfaces the same kind of silently-accumulating spend that eventually pushed 37signals to act.
Gart has also documented three separate AWS-to-Hetzner migrations with real before/after numbers in Is Hetzner a Good Alternative to AWS? Real Migration Cases — a useful companion read if your repatriation candidate is a European workload where EU-based colocation, rather than fully owned hardware, is the realistic destination.
A Framework for Testing Your Own Repatriation Case
Before treating any of the case studies above as a template, run your own candidate workload through the same filter that made these four projects succeed rather than stall out as an unfunded initiative.
SignalGood repatriation candidateBetter left on public cloudUtilization patternSteady, 24/7, predictable (core databases, primary compute)Bursty, seasonal, or experimental (marketing sites, new features)Annual cloud spend on this workloadHigh enough (typically seven figures+) to amortize hardware quicklyLow — hardware payback period would exceed its useful lifeGrowth trajectoryFlat to slow-growing — capacity planning is realisticRapidly scaling or unpredictable — elasticity has real valueData residency / compliance needRegulatory requirement for a named location or physical controlNo specific jurisdictional constraintInternal ops capabilityTeam can operate hardware/colocation, or is willing to build that muscleNo appetite to take on physical infrastructure operationsA Framework for Testing Your Own Repatriation Case
Most enterprises land somewhere in the middle: one or two workloads score clearly on the left column while the rest of the estate stays right where it is. That's exactly the hybrid pattern Gart's full cloud-vs-on-premises comparison walks through in more architectural detail: repatriation decisions get made workload-by-workload against a TCO model, not as an all-or-nothing infrastructure strategy.
Where Repatriation Projects Go Wrong
The case studies above are the success stories that got published. The projects that stall or underdeliver tend to fail for a narrower, more predictable set of reasons:
Underestimating the operational shift. Owning or colocating hardware means your team now owns capacity planning, patching, and physical redundancy — work the cloud provider was quietly doing. Infrastructure consulting engagements exist specifically to close this gap before go-live, not after an outage.
Moving compliance-sensitive data without re-validating controls. A workload that met audit requirements under a cloud provider's shared-responsibility model doesn't automatically stay compliant once your team owns the physical and network layer — see Gart's breakdown of managing HIPAA-regulated PostgreSQL during a repatriation for what changes.
Treating it as all-or-nothing. Every successful case study above kept a meaningful cloud footprint. Teams that try to exit the cloud entirely, rather than moving the specific workloads that meet the criteria above, tend to rebuild the same elasticity problem on-prem instead of solving it.
The security and compliance side of this decision deserves its own deep dive — Gart's companion piece on IT infrastructure security best practices, strategies, and tools covers what silently stops being "someone else's problem" once a workload leaves managed cloud infrastructure, alongside the architectural patterns in multi-cloud Kubernetes: the power and the peril for teams building the hybrid layer that connects owned infrastructure back to the cloud workloads that stay.
Repatriation Strategy & Execution
Deciding whether your own workloads belong on-prem, colocated, or in the cloud?
Gart Solutions builds the same kind of workload-by-workload TCO model behind the case studies above — then designs and executes the migration, whether that means AWS-to-Hetzner colocation, a hybrid Kubernetes architecture, or a full infrastructure buildout, without losing the compliance posture you started with.
Cloud Migration Services
Cloud Cost & TCO Assessment
IT Infrastructure Consulting
Infrastructure Audit
Hybrid & Multi-Cloud Kubernetes
DevOps & SRE
Disaster Recovery & Failover
Talk to a migration specialist
Explore our infrastructure management services →
You might also like
Why Companies Are Migrating to Hetzner: From AWS, Azure & Legacy Systems
OVH vs AWS: The Enterprise Decision That Defines Your Next Two Years
Best 20 Cloud Migration Companies
How to Choose a Cloud Provider: AWS vs Azure vs Google Cloud
Security Consulting and Cloud Migration for a Golf Self-Service Platform
Fedir Kompaniiets
Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant
Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the "tech madness" through expert DevOps and Cloud managed services. Connect on LinkedIn.
AWS still offers unmatched scale, but for a large share of production workloads it has become the most expensive way to solve an ordinary infrastructure problem. That is the conclusion three Gart Solutions clients reached independently, in three different industries, before any of them had heard of each other's projects. Each one asked the same question CTOs keep typing into Google: is Hetzner really a viable alternative to AWS, or just a cheaper-looking trap?
This article has been updated for 2026, including Hetzner's two pricing rounds this year, to give you an honest, numbers-first answer — backed by three real migrations Gart Solutions shipped into production.
Gart Solutions has been making waves by strategically shifting away from hyperscale providers like AWS to cost-effective, performance-optimized alternatives like Hetzner.
So, is Hetzner just cheaper, or actually better in some scenarios? Let’s break it all down by diving into real-world deployments, cost comparisons, and expert insights from how Gart Solutions has deployed Hetzner in production environments with striking success.
Is Hetzner Still a Good Alternative to AWS in 2026?
Short answer: yes, for most compute, storage, and bandwidth-heavy workloads — but the margin narrowed in 2026, and it now matters which Hetzner product line you pick. Hetzner raised cloud prices twice this year: a broader adjustment of up to 37% on April 1, and a second round on June 15 that pushed the dedicated-vCPU CPX and CCX lines up by as much as 176%, while the cost-optimized CX and CAX lines rose a more modest 33–38%. Hetzner cited a global DRAM and NVMe price shock driven by AI demand as the cause.
That changes the calculus but doesn't flip it. AWS egress still runs roughly $0.09 per GB outbound, while Hetzner's cost-optimized and shared-vCPU lines still ship with 20 TB of free monthly traffic per instance in EU regions. For bandwidth-heavy products — gaming, streaming, SaaS downloads — that single line item still makes Hetzner the rational default. For RAM-heavy dedicated workloads (large databases, in-memory caches), it's now worth re-running the math against Hetzner's own cost-optimized tier, a dedicated root server, or another EU provider before committing.
Understanding the Cloud Landscape
AWS – The Industry Giant
There’s no denying AWS is the gold standard in cloud computing. With over 200 services spanning compute, storage, networking, databases, machine learning, and more, AWS supports everything from nimble startups to multinational conglomerates. It offers enterprise-level reliability, granular security controls, and geographic coverage that stretches across every continent.
But with this enormous toolset comes equally massive complexity — and cost. AWS operates on a “pay-as-you-go” model that can seem fair in theory, but often ends up being unpredictable and overwhelming.
Egress (outbound traffic) charges, for instance, can be a nightmare for businesses that distribute large files, stream content, or run high-traffic platforms.
And while AWS excels at handling massive scale, its complexity sometimes makes it a burden for smaller teams or simpler projects.
Hetzner — The European Challenger That Grew Up
Hetzner doesn't have AWS's market share, but it has become a default choice for developers, startups, and cost-conscious enterprises across Europe and beyond. Known historically for its flat-rate pricing and high-performance dedicated servers, Hetzner offers both bare-metal and cloud services. Where AWS offers nearly everything, Hetzner focuses on doing fewer things extremely well: raw compute power, consistent bandwidth, and high-speed networking, all on transparent monthly billing.
Hetzner may not have the same market share as AWS, but it’s quietly become a favorite among developers, startups, and cost-conscious enterprises across Europe and beyond. Known for its nonsense pricing model and high-performance dedicated servers, Hetzner offers both bare-metal and cloud services at prices that often make AWS look like luxury shopping.
Where AWS offers nearly everything, Hetzner focuses on doing fewer things extremely well. It excels in areas like raw compute power, consistent bandwidth, and high-speed networking — all while charging a flat monthly fee or minimal hourly rates. And unlike AWS, Hetzner includes generous traffic allowances (often unlimited), which makes it especially appealing for applications with high outbound data needs.
And while Hetzner doesn’t match AWS in the breadth of services, it integrates smoothly with modern DevOps tooling, like Terraform, Kubernetes, Docker, and CI/CD pipelines, making it highly attractive to teams that want performance without vendor lock-in.
Why Companies Seek AWS Alternatives
The High Cost of AWS
It’s not just small businesses complaining about AWS pricing — it’s a known industry pain point.
Let’s say you’re running a content delivery app or SaaS platform — each gigabyte of outbound data gets billed separately. Now imagine 100,000 users downloading or streaming from your app. Suddenly, your monthly cloud costs double, even if your user base hasn’t changed.
This pricing structure often penalizes growth. The more successful your application, the more you pay — not because you’re consuming more compute, but because data transfer is metered heavily.
And then there’s the operational cost of managing AWS. It often takes a team of certified engineers just to maintain and optimize configurations, spot underutilized resources, and ensure security best practices. That’s a hidden cost many businesses overlook.
FactorAWSHetzner (post-June 2026)Compute (cost-optimized tier)~$30–40/mo (2 vCPU/4GB)~€5.49/mo (CX23) — still 4–7× cheaperCompute (dedicated-vCPU tier)~$140/mo (4 vCPU/16GB)~€19.49–24/mo (CPX22-class) — narrower lead vs early 2026Outbound bandwidth~$0.09/GB, no free tier20 TB/month included (EU instances)Managed KubernetesEKS, ~$73/cluster/mo + nodesNo native managed control plane (k3s/RKE via partners)Managed databaseRDS, Multi-AZ failoverSelf-hosted (Gart deploys HA Postgres/MySQL clusters)Regions30+ global regionsGermany, Finland, US, SingaporeGDPR postureEU regions available, US parent entityNative — German-headquartered, EU-only by defaultAWS - Hetzner price comparison
Performance vs. Price Dilemma
One of the major paradoxes with AWS is that while it promises performance, it charges a premium for consistency. Your EC2 instance might perform well today and lag tomorrow due to noisy neighbors (multi-tenant environments). You can pay more for “dedicated” resources, but that quickly spirals out of budget.
With Hetzner, the opposite is often true. You get powerful bare-metal servers or consistently high-performance VMs without needing to guess on pricing tiers. This predictability, both in cost and performance, is a major reason companies start looking beyond AWS.
Gart Solutions’ Cloud Philosophy
Gart Solutions specializes in helping clients modernize IT infrastructure, adopt DevOps best practices, and scale without breaking the bank. Our philosophy revolves around optimizing every layer of the cloud stack — from infrastructure provisioning to deployment pipelines, while keeping budgets in check.
Rather than defaulting to AWS because it’s the “safe choice,” Gart Solutions evaluates each client’s real needs: traffic patterns, performance requirements, cost sensitivity, and automation goals. This leads us to seek infrastructure that aligns more closely with the business model and technical demands of the project.
Choosing Hetzner – Strategic Reasoning
For many of their client projects, Gart Solutions identified Hetzner as the perfect balance of affordability, reliability, and flexibility. The decision to go with Hetzner wasn’t just about cost (though that played a big part). It was also about control, automation, and the ability to manage infrastructure using familiar tools like Terraform, Kubernetes, and Ansible.
By choosing Hetzner, they could build resilient, scalable infrastructure that’s just as capable as AWS-hosted setups but without the headache of unpredictable billing. Whether they were optimizing CI/CD workflows or deploying complex container orchestration, Hetzner’s clean infrastructure model made it easier to build, manage, and maintain robust cloud environments.
They also appreciated that Hetzner doesn’t charge for traffic — making it a godsend for media-rich apps, SaaS tools, gaming platforms, and IoT systems.
Case Study #1 – High-Traffic Gaming Workloads
The Challenge with AWS
Imagine you're launching a gaming platform where users can download large files ranging from 500MB to 1GB. Now imagine 20,000 users doing that repeatedly during a promotional campaign. On AWS, this means enormous outbound data charges.
That’s exactly the problem one Gart Solutions client faced. They had projected annual revenues of about $80,000 from free-to-play game trials, but AWS’s pricing would have eaten up over 60% of that —just from data egress costs.
Using AWS’s EC2 instances and S3 storage initially seemed like a safe, scalable choice. But the hidden cost of bandwidth, especially when the business model relies on large, frequent downloads — was a dealbreaker. Gart quickly realized that if the client stuck with AWS, the entire revenue model would collapse under operational expenses.
Migration to Hetzner
Gart Solutions proposed a switch to Hetzner Cloud. Why? Because Hetzner offers uncapped bandwidth with minimal restrictions and flat-rate pricing, perfect for handling enormous traffic at predictable costs. They rebuilt the platform using a combination of Hetzner's dedicated servers and cloud instances, optimizing download performance through fast SSD storage and CDN acceleration.
To ensure reliability, they implemented failover systems, load balancing, and efficient caching layers. The infrastructure was containerized, making it portable, scalable, and fast to deploy. With Terraform and Docker in place, infrastructure updates could happen in seconds, ensuring seamless rollouts and minimal downtime.
Results and Metrics
Cost Reduction: data traffic expenses dropped by nearly 80% compared to AWS.
Performance: download speeds remained consistent, averaging ~200MB/s per node.
User Experience: zero downtime during traffic surges; smoother gameplay initiation.
Business Impact: client retained a much healthier margin, making the game trial monetization strategy sustainable.
Hetzner didn’t just replace AWS, it enabled a business model that AWS pricing would have killed.
Case Study #2 – Scaling a Global Environmental Platform
Elandfill.io’s Expansion Needs
ReSource International approached Gart Solutions with a clear mission: scale their landfill management software — elandfill.io from local installations in Iceland to a full-scale global SaaS platform. The challenge wasn’t just scaling users; it involved handling enormous datasets including geospatial images, gas emissions records, real-time weather monitoring, and predictive analytics across multiple time zones.
The backend involved PostgreSQL with PostGIS, map rendering, data ingestion pipelines, and alert systems for environmental safety —all of which needed to work in real-time. Doing this on AWS was certainly an option, but the potential cost and service complexity threatened to overwhelm the project in its infancy.
How Hetzner Met the Challenge
Gart Solutions architected the entire SaaS platform on Hetzner Cloud using Kubernetes for orchestration. They built modular services for monitoring, alerting, analytics, and rendering, ensuring the architecture was elastic and easy to maintain.
Key elements included:
Geoserver Optimization: efficient handling of map tile generation and caching.
CI/CD Pipelines: automated testing, deployment, and rollback.
Monitoring & Alerting: Prometheus and Grafana stack for full observability.
They made use of Hetzner’s reliable network and data centers in Germany and Finland to ensure low-latency performance across Europe. For clients outside Europe, the solution was containerized and easily deployable in hybrid-cloud models if needed.
Business Outcomes
Scalability: platform scaled from 1 to 14 countries without downtime.
Affordability: hosting cost reduced by more than 60% compared to initial AWS projections.
Real-Time Data: improved latency and faster alerts for environmental breaches.
Sustainability: the low-cost footprint aligned perfectly with the client’s green tech values.
Hetzner helped turn a local environmental tool into a global digital platform, without the AWS price tag.
Case Study #3 – DevOps in Digital Betting
Betting Platform Infrastructure Problems
A Germany-based digital betting provider was struggling with an outdated infrastructure. They were operating on bare-metal Windows servers, had no automation for deployments, and scaled poorly during live sports events. Everything was done manually — from patches to provisioning. Each code change risked downtime, and traffic spikes during major sports matches regularly crashed the system.
Their CI/CD pipeline was virtually nonexistent, and their infrastructure couldn't support high availability or disaster recovery effectively. The business risk was high and escalating.
Full DevOps Makeover with Hetzner
Gart Solutions rebuilt the architecture from the ground up, starting with a migration to Hetzner’s Linux-based virtual servers. The transformation was executed in three phases:
Mapping Service Dependencies: they audited the system’s critical services, establishing what needed to be containerized and how to break the monolith.
Infrastructure-as-Code: using Ansible and Terraform, they automated provisioning and configuration. This reduced deployment times from days to minutes.
Kubernetes & CI/CD: they rolled out Kubernetes clusters to support containerized workloads, introduced GitLab CI pipelines, and set up observability tools (Prometheus, Loki, Grafana).
Disaster recovery, blue-green deployments, and A/B testing became part of the operational DNA.
Uptime, Performance, and Deployment Success
Uptime: 99.97% availability across 12 months.
Speed: Deployment times reduced from 48 hours to under 10 minutes.
Traffic Handling: Load testing showed platform stability during 3x normal traffic.
Operational Efficiency: Engineers gained back 30+ hours/month previously spent on manual deployments.
Hetzner + Gart’s DevOps framework turned a fragile betting platform into a modern, resilient, cloud-native powerhouse.
How Gart Solutions De-Risks an AWS → Hetzner Move
The three results above didn't happen by copying servers and hoping. Each migration followed the same disciplined process our team runs for every Cloud Migration engagement:
01 — Audit
Map every AWS dependency, egress pattern, and cost driver before touching a single workload.
02 — Architect
Pick the right Hetzner tier (or hybrid mix) per workload — never a blanket "move everything" call.
03 — Migrate
Zero-downtime cutover with Terraform and Ansible, parallel environments, and staged traffic shifts.
04 — Operate
Ongoing SRE and monitoring so the savings hold a year later, not just on day one.
Considering a move but unsure whether your workload still clears the bar after Hetzner's 2026 price changes? Gart Solutions runs a free infrastructure audit that models your real AWS bill against a Hetzner or hybrid build before you sign anything.
Book a Free Cloud Cost Audit →
Comparing AWS and Hetzner Head-to-Head
Cost Structure
If you have high or unpredictable outbound traffic, Hetzner wins hands down.
Performance and Reliability
While AWS offers near-100% uptime SLAs, Hetzner has proven reliability across use cases.
Benchmarks from Gart Solutions show Hetzner’s VMs and bare-metal instances match AWS in I/O speed and network throughput, especially for European users.
DevOps Compatibility
Both support modern DevOps stacks, but AWS has its own ecosystem (CodePipeline, CloudFormation) while Hetzner integrates openly with popular tools like Terraform, Ansible, and Kubernetes.
So, AWS is more integrated but less flexible. Hetzner allows full control.
When to Choose Hetzner Over AWS
Ideal Use Cases
Let’s be honest — no single cloud provider is the right answer for everyone. But if your use case aligns with one or more of the following, Hetzner might just be your secret weapon:
High-Bandwidth Applications Streaming platforms, file-sharing systems, gaming platforms, or SaaS products with large downloads benefit massively from Hetzner’s free, uncapped outbound traffic.
Budget-Conscious Startups If you're just launching a product or bootstrapping your business, AWS costs can be punishing. Hetzner’s flat-rate pricing lets you plan and scale without unpredictable bills.
Self-Managed DevOps Environments Teams that love working with Terraform, Ansible, Kubernetes, and Docker will feel right at home. Hetzner’s clean infrastructure gives you full control, no managed service lock-ins.
Edge and Regional Deployments With Hetzner’s growing global footprint (Germany, Finland, and now the U.S. and Singapore), deploying regionally for latency-sensitive apps is very feasible.
SaaS Builders Looking for Control If your app needs custom infrastructure or tight observability (without vendor APIs), Hetzner gives you the hardware feel in a cloud package.
When AWS Still Wins
However, there are situations where AWS remains the better option:
Need for Managed Services AWS offers robust managed databases, serverless architecture, AI/ML platforms, and global CDN options that Hetzner doesn’t match.
Regulatory Compliance & Certifications If your app requires SOC 2, HIPAA, FedRAMP, or other high-level certifications, AWS provides pre-approved infrastructure for compliance-heavy workloads.
Enterprise Multi-Region Scaling For companies operating across 10+ countries with users worldwide, AWS’s global data centers and traffic routing give them an edge.
If you want flexibility and control at a fraction of the cost, Hetzner is excellent. If you need managed magic and global compliance, AWS is king.
Final Thoughts – Hetzner Is a Smart, Scalable Choice
Here’s the bottom line: Hetzner is not a universal replacement for AWS, but in the right hands, it becomes a cloud powerhouse, especially when paired with smart implementation partners like Gart Solutions.
Through three real-world case studies, we’ve seen:
Case 1: How a gaming company salvaged its monetization model by eliminating bandwidth fees.
Case 2: How a green tech startup scaled globally with geospatial data, using Kubernetes and Hetzner’s compute flexibility.
Case 3: How a legacy betting platform transformed into a fast, scalable, DevOps-driven cloud app with zero AWS involvement.
Hetzner isn’t about bells and whistles. It’s about raw performance, predictable pricing, and giving engineers the tools they need without handholding. And when paired with a team like Gart Solutions, it doesn’t just save money.
So, is Hetzner a good alternative to AWS?
Absolutely. Especially when every dollar, every millisecond, and every gigabyte counts.
There are some thoughts of other users on Reddit, we’ve checked to provide you with the most complete picture on choosing a cloud provider. Link to Reddit thread.
Let’s work together!
See how we can help to overcome your challenges
Contact us
Fedir Kompaniiets
Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant
Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the "tech madness" through expert DevOps and Cloud managed services. Connect on LinkedIn.
Key takeaways
Repatriation is usually selective. Surveys show most enterprises plan to move some workloads back, but only a small minority plan a full exit.
The best candidates are steady, storage-heavy, egress-heavy or latency-sensitive workloads. Bursty, early-stage and globally distributed workloads usually belong in the cloud.
Published savings cases are real but specific: Dropbox and 37signals are large, stable, storage-intensive businesses. Your result depends on your own TCO model.
In our illustrative mid-size SaaS model below, run-rate savings reach about 47%, payback takes roughly two years, and five-year savings are about 28%. With a heavier operations team or a smaller cloud bill, the case weakens or disappears.
In the EU, DORA exit-strategy rules and the Data Act's ban on switching charges (from 12 January 2027) make exit readiness a governance topic, not only a cost topic.
What cloud repatriation is (and isn't)
Cloud repatriation means moving selected workloads, data or applications from a public cloud provider to private infrastructure — colocation, bare metal, a private cloud or an on-premises data centre — while usually keeping other workloads in the public cloud.
It is not a verdict that the cloud failed. For early-stage products, uncertain demand and global distribution, public cloud remains hard to beat. Repatriation becomes relevant later, when some workloads have settled into predictable patterns and the premium paid for elasticity is no longer buying anything.
We find it more useful to think in terms of workload placement: each system runs where its cost, performance and compliance profile fit best, and that placement is reviewed as the business matures.
How widespread is it? What the surveys actually say
The headline figure most often quoted comes from Barclays' CIO survey: in the first half of 2024, 83% of enterprise CIOs said they planned to move at least some workloads back from public cloud, up from 43% in late 2020 (EE Times Europe). A later edition of the survey put the figure at 86% (Cyfuture summary).
Two caveats matter. First, "plan to move at least one workload" is a low bar — it says nothing about what share of spend moves. Second, IDC research cited across the industry suggests only around 8–9% of companies plan a full-scale repatriation (CNIC Solutions summary). The realistic picture is partial moves and hybrid estates, not a mass exodus.
Why the economics shift as workloads mature
Public cloud pricing bundles three things: the infrastructure itself, the provider's operations, and the option to scale up or down at will. Early on, that option is valuable. Once a workload runs at a steady baseline 24/7, you keep paying for flexibility you no longer use.
Andreessen Horowitz's widely cited analysis, The Cost of Cloud, a Trillion Dollar Paradox (2021), put numbers on this for public software companies. The authors estimated that committed cloud spend averaged roughly half of cost of revenue across the companies they studied, and reported one billion-dollar private company whose cloud spend reached 81% of cost of revenue. Based on expert interviews, they used a working assumption that repatriation runs equivalent workloads at one-third to one-half of the cloud cost (a16z).
That analysis is an estimate built on interviews and filings, not a controlled study, and it focused on large software companies. It is a useful frame for why margins matter, not a forecast for any individual company.
The cost drivers to measure in your own bill
This is the Cloud Paradox:
the infrastructure that accelerates early growth becomes a structural tax on mature businesses.
Venture capital and public market analysts have quantified the impact. Across large software companies, cloud spend has been shown to suppress gross margins by 15–25 percentage points. Because valuation is a function of gross profit, this does not merely reduce cash flow—it destroys equity value.
At scale, cloud costs are no longer an operational detail. They become a board-level concern.
From Agility to Efficiency: A Two-Stage Infrastructure Model
The emerging consensus among infrastructure leaders is not “cloud versus on-prem,” but phase-appropriate infrastructure.
Stage 1: The Agility Phase
In the early lifecycle of a product or platform, uncertainty dominates.
Demand is volatile
Architecture is still evolving
Speed matters more than efficiency
Public cloud excels here. Elasticity, managed services, and global reach justify the premium. Paying for flexibility makes sense because flexibility is actively used.
Stage 2: The Efficiency Phase
As products mature, priorities change.
Workloads enter steady state
Usage becomes predictable
Margins and cost per transaction matter
At this stage, elasticity becomes overhead. Enterprises continue paying for burst capacity they no longer need, for abstraction layers they cannot tune, and for network paths they do not control.
Infrastructure Maturity means recognizing when a workload has crossed from Stage 1 to Stage 2—and moving it accordingly.
Deconstructing the Cloud Tax
The “cloud tax” is not a single line item. It is the cumulative effect of multiple structural costs that only become visible at scale.
1. Data Egress and Network Friction
Ingress is cheap. Egress is not.
For data-intensive workloads, network charges routinely account for 20–40% of total cloud spend. Cross-region replication, analytics pipelines, AI training data, and customer exports all trigger fees that are difficult to forecast and harder to optimize.
This creates economic lock-in: data can enter easily, but leaving is expensive.
2. Virtualization Overhead
Public cloud relies on deep abstraction. That abstraction introduces measurable performance loss—typically 5–15% per workload, which must be compensated for with additional compute.
For high-throughput databases, AI inference, real-time analytics, and latency-sensitive systems, this overhead translates directly into higher cost per request and inconsistent performance.
3. Cost Volatility
Usage-based pricing creates financial unpredictability. Infrastructure becomes a variable expense tied not just to growth, but to architectural decisions, user behavior, and even API design.
For CFOs and boards, this volatility complicates forecasting, valuation, and long-term planning.
Rather than relying on generic percentages, these are the line items we examine first in a repatriation assessment:
Data egress and transferInternet egress, cross-region replication, cross-AZ traffic and NAT processing are billed per GB. At AWS list prices, internet egress starts at about $0.09/GB in most regions. For data-heavy products, this line can grow faster than compute.
Steady-state computeInstances running at a stable baseline around the clock are the clearest candidates, especially after Savings Plans or Reserved Instances are already applied.
Storage growth. Object and block storage that grows continuously but is rarely deleted.
Performance-sensitive systemsDatabases, real-time analytics and inference services where you may be over-provisioning to compensate for noisy neighbours or abstraction overhead. The size of that overhead varies by workload, so we benchmark it rather than assume it.
Cost volatility. How much monthly spend deviates from forecast, and how hard that makes budgeting and margin planning.
If you haven't yet optimised the cloud bill itself — rightsizing, commitments, storage tiers, VPC endpoints — do that first. Many "repatriation" cases turn out to be optimisation cases.
See our guide to cloud cost optimization traps.
Real-world cases, with their context
DropboxDropbox's 2018 S-1 filing describes an "Infrastructure Optimization" programme that moved most user data from a third-party provider to its own custom infrastructure in leased colocation facilities. In 2016, payments to the third-party provider fell by $92.5M, offset by a $53.0M increase in depreciation, facilities and support costs — a net decrease of $39.5M. A further $35.1M reduction followed in 2017, for about $74.6M over two years (Dropbox S-1, SEC; GeekWire). Context: Dropbox operates at very large storage scale and kept using AWS for a portion of its storage and for some regions.
37signals (Basecamp, HEY)37signals reported a 2022 cloud bill of about $3.2M. In early 2023 it projected spending roughly $840,000 a year on owned hardware (amortised over five years) and colocation, versus about $2.3M in comparable cloud costs, and estimated $7M saved over five years (DatacenterDynamics). In October 2024 the company said its annual cloud bill had dropped to about $1.3M (remaining S3 storage), that the ~$700K of new servers had been recouped from savings during 2023, and raised its five-year estimate to more than $10M once storage moves too (DatacenterDynamics). Context: these are company-reported figures, and observers note they exclude some costs, such as future hardware refreshes and part of the operations overhead. 37signals also already had operations staff and existing data centre space.
What both cases share: large, stable, storage-heavy workloads, existing in-house infrastructure skills, and a hybrid end state rather than zero cloud.
How we built the numbers: methodology
The worked example below is illustrative. It is a composite of the cost structures we typically see in mid-size SaaS assessments, not a single client's data. These are the assumptions behind it:
ScopeOne production platform: steady compute, ~500 TB of block and object storage, ~150 TB/month of internet egress, managed databases and load balancers.
Cloud baselineCurrent monthly bill after existing Savings Plans and storage-tier optimisation, so we compare against an already-optimised cloud, not list price.
Time horizon3 and 5 years. Hardware is depreciated over 5 years; no refresh falls inside the window.
Upfront costsServer and storage hardware, plus a one-off migration budget covering engineering time, dual-running both environments during cut-over, and data transfer.
Ongoing private costsColocation rack space and power, internet transit, hardware support contracts (8% of hardware cost per year), operations staffing (fully loaded), software licences, and a residual cloud footprint for DR, burst capacity and edge delivery.
ExcludedPrice changes over the period, financing costs, tax effects, and the opportunity cost of engineering time not spent on product.
When we run this for a client, every input comes from their billing exports, utilisation metrics and vendor quotes, and we document each assumption so finance can challenge it.
Worked example: 5-year TCO for a mid-size SaaS platform
Current public cloud spend (monthly, after commitments)
Line itemMonthlyAnnualCompute (after Savings Plans)$46,000$552,000Block + object storage (~500 TB)$14,000$168,000Internet egress (~150 TB)$11,000$132,000Managed databases, load balancers, misc.$9,000$108,000Total$80,000$960,000
Repatriated / hybrid alternative
ItemCostHardware (servers, storage, network) — one-off$650,000Migration, dual-running and data transfer — one-off$250,000Colocation, 4 racks incl. power — per year$120,000Internet transit — per year$36,000Hardware support (8% of hardware) — per year$52,000Operations staffing (1.5 FTE, fully loaded) — per year$165,000Software licences — per year$40,000Residual cloud (DR, burst, CDN/edge) — per year$96,000Ongoing total — per year$509,000
Results
MetricValueRun-rate saving per year$451,000 (≈47% of the cloud bill)Upfront investment$900,000Simple payback≈24 months3-year cumulative cost: cloud vs. hybrid$2.88M vs. $2.43M → saving ≈$453K (≈16%)5-year cumulative cost: cloud vs. hybrid$4.80M vs. $3.45M → saving ≈$1.36M (≈28%)
Note how different the three numbers look. The run-rate saving (47%) is the figure people like to quote. The 3-year saving (16%) is what a CFO sees once the upfront investment is included. Both are true; only one belongs in a board deck without a footnote.
Sensitivity: what breaks the case
ScenarioEffectOperations team needs 3 FTE instead of 1.5Payback stretches to ≈38 months; 5-year saving falls to ≈$530K (≈11%)Cloud bill is $30K/month instead of $80K (smaller footprint, ~$450K upfront, 1 FTE)5-year result turns negative: roughly –$105KWorkload becomes bursty (needs 2× peak capacity on-prem)Hardware and colocation costs rise sharply; usually stay in cloud
The two variables that move results most are operations staffing and the size and stability of the cloud bill. If you can't staff the private environment (or buy managed colocation and remote hands), the savings evaporate.
When repatriation is the wrong move
Repatriation is a poor fit — or premature — in these situations:
Your cloud bill is modestBelow a few hundred thousand dollars a year, fixed costs (staff, contracts, minimum rack commitments) tend to eat the savings, as the sensitivity table shows.
Demand is spiky or unpredictableSeasonal retail, event-driven platforms and new products benefit from paying only for peaks.
You rely heavily on managed or proprietary servicesRebuilding the equivalent of a managed data warehouse, serverless stack or ML platform can cost more than it saves.
You lack infrastructure operations skills and don't want to build or buy them.
You need global reach or low-latency edge delivery in many regions.
You haven't optimised the cloud yetRightsizing, commitments and storage tiering often recover a meaningful share of spend for far less effort.
The architecture is about to changeCommitting to five years of hardware just before a major re-platforming locks in the wrong capacity.
The business case depends on hard-to-forecast growthIf capacity needs could double or halve within two years, flexibility is worth paying for.
In these cases, the right move is usually cloud cost optimisation, better commitment planning, or keeping an exit plan on paper rather than executing it.
AI workloads: a case to model, not to assume
GPU-heavy AI training and inference have renewed interest in dedicated infrastructure. The reasoning: long-running training jobs keep expensive accelerators busy for weeks, large datasets are costly to move repeatedly, and teams want predictable capacity.
The economics are highly specific, though. Compare on-demand, reserved and spot GPU pricing from hyperscalers, specialised GPU cloud providers and colocation options against your actual utilisation. Dedicated GPU clusters pay off when they stay busy; idle accelerators are among the most expensive assets a company can own. For more on planning this, see building AI-ready infrastructure.
Regulation: exit readiness in the EU
Two EU regulations make exit planning a concrete obligation rather than a nice-to-have:
DORA (Digital Operational Resilience Act). Applicable to EU financial entities since 17 January 2025, DORA Article 28(8) requires documented exit strategies for ICT services that support critical or important functions, and these should be tested and reviewed (Swfte overview; FAST LTA).
EU Data Act. Its cloud-switching rules allow only cost-based switching charges until 12 January 2027; from that date, switching charges — including data egress fees tied to a switch — are prohibited. The ban covers switching providers or moving to on-premises, not ordinary day-to-day egress (Lindahl)
Major hyperscalers already waived egress fees for customers making a full exit in 2024. Lower exit costs don't make repatriation automatically worthwhile, but they remove one barrier and make a credible exit plan easier to document. Read more: Digital Sovereignty of Europe: Choosing the EU Cloud Provider.
Why it is more feasible now
A decade ago, leaving the cloud often meant giving up operational convenience. That gap has narrowed:
Kubernetes and infrastructure-as-code (Terraform, Ansible) behave consistently across cloud and bare metal.
Modern deployment tooling supports zero-downtime releases outside hyperscalers.
Open storage and networking standards preserve portability.
Colocation providers offer remote hands and managed facilities, so you don't need to run your own building.
The operational gap is smaller, but not zero. Someone still has to own hardware lifecycle, capacity planning, security patching and incident response.
Regulation and infrastructure sovereignty
Cost and performance are no longer the only drivers.
By 2026, documented exit capability is becoming a regulatory requirement across multiple jurisdictions. Financial services, healthcare, critical infrastructure, and government-adjacent organizations must now prove they can disengage from cloud providers without service disruption.
This shifts repatriation from an optimization choice to a compliance obligation.
Infrastructure that cannot be exited is no longer considered resilient.
Read more: Digital Sovereignty of Europe: Choosing the EU Cloud Provider
Why Cloud Repatriation is feasible now
A decade ago, leaving the cloud meant sacrificing operational convenience. That is no longer true.
Modern deployment tools enable zero-downtime releases on bare metal with minimal operational overhead
Kubernetes behaves consistently across environments
Open storage and networking standards preserve portability
Colocation providers offer managed facilities without hyperscaler markups
The operational gap between public cloud and private infrastructure has narrowed dramatically. What remains is a cost and control gap—and that gap favors maturity.
Building a cloud exit strategy: a maturity framework
Successful cloud repatriation is selective, not absolute.
Audit and classify workloadsIdentify steady-state systems paying for unused elasticity.
Model long-term economicsCompare 3–5 year total cost of ownership, including margin impact—not just infrastructure invoices.
Assess operational readinessDetermine whether to own operations fully or pair private hardware with managed facilities.
Ensure portabilityStandardize data formats, deployment pipelines, and orchestration layers.
Rehearse the exitTreat exit readiness as an operational capability, not a contingency document.
The hybrid maturity era
The future is not cloud-only or on-prem-only. It is hybrid by design.
Public cloud remains the best tool for experimentation, global distribution, and burst workloads
Private infrastructure anchors predictable compute, core data, and margin-sensitive systems
Enterprises that succeed by 2026 will be those that treat infrastructure placement as a strategic lever—not a default setting.
Repatriation is not a step backward.It is the moment an organization proves it understands its own economics.
Strategic priorities for 2025–2026
Identify workloads that have outgrown elasticity
Reassess AI infrastructure economics early
Embed exit readiness into governance
Standardize on portable tooling
Elevate infrastructure cost to a valuation metric
The cloud was never the destination. It was the on-ramp.
Infrastructure Maturity is knowing when to change lanes.
The hybrid end state
In most of the engagements we see, the result is hybrid by design. Public cloud handles experimentation, burst capacity and global distribution. Private infrastructure carries predictable compute, core data and margin-sensitive systems. The placement is reviewed as workloads change — some may move back to the cloud later, and that should be easy too.
Repatriation isn't a step backwards. Done well, it shows an organisation understands its own unit economics well enough to put each workload where it belongs.
Want a fact-based view of your own numbers? Gart's IT audit maps your workloads, models 3- and 5-year TCO from your actual billing data, and shows which systems — if any — are worth moving.
Contact us
