Mention leaving AWS and the response is predictable: “You cannot just lift and shift everything to bare metal.”
They are right. You cannot. But that is a straw man. Nobody serious about cloud repatriation is suggesting you fork-lift your entire infrastructure onto Hetzner over a weekend. That is not how modern cloud exit works, and framing it that way kills conversations that companies genuinely need to have.
The All-or-Nothing Trap
The cloud industry has framed the exit question as binary: you are either “all in” on cloud or you are making a terrible mistake. This framing serves cloud providers and the ecosystem of consultancies, tools, and certifications built around them. It does not serve you.
Most companies should be running a hybrid infrastructure — some workloads on public cloud, some on dedicated servers, some on managed platforms that are not hyperscalers. The question is not “cloud or not cloud.” It is “which workloads belong where?”
That question deserves a rigorous answer, not a religious one.
What Modern Cloud Exit Actually Looks Like
I have helped companies move workloads off AWS, Azure, and GCP. None of them moved everything. All of them saved significant money. Here is the actual process:
Phase 1: Workload Classification (2–4 weeks)
Before moving anything, you classify every workload along two axes:
Cloud-native dependency: How tightly coupled is this workload to cloud-specific services? A Lambda function triggered by SQS, writing to DynamoDB, with CloudWatch alarms — that is deeply cloud-native. A Docker container running a Python API with a PostgreSQL database — that is portable.
Traffic pattern: Is the workload bursty or steady-state? Bursty workloads (seasonal spikes, event-driven processing) benefit enormously from cloud elasticity. Steady-state workloads (your main application server running 24/7 at 40–60% utilisation) are paying a premium for elasticity they never use.
This classification usually reveals that 30–50% of workloads are strong candidates for repatriation, 20–30% are borderline, and 20–40% genuinely belong on cloud.
Phase 2: Target Architecture (2–4 weeks)
For each workload you are moving, you design the target state. This is where “not lift and shift” really matters.
A workload running on ECS with an RDS database does not just get copied to a bare-metal server. You might:
- Replace ECS with Docker Compose or Kubernetes (if you have the scale for it)
- Replace RDS with self-managed PostgreSQL using automated backups
- Replace ALB with Caddy or Nginx
- Replace CloudWatch with Prometheus and Grafana
- Replace S3 with MinIO or a cheaper object storage provider
Each replacement is a deliberate architectural choice. Some managed services get replaced with self-hosted equivalents. Others get replaced with simpler alternatives that did not make sense on cloud but are perfect on dedicated hardware.
Phase 3: Parallel Run (4–8 weeks per workload)
This is the phase that “lift and shift” critics forget exists. You do not cut over. You run in parallel.
The workload runs simultaneously on cloud and on the target infrastructure. Traffic is gradually shifted — 10%, 25%, 50%, 100% — with monitoring at every stage. If anything breaks, traffic shifts back instantly.
This is exactly how responsible infrastructure migrations work. It is how cloud migrations work too, ironically. The process is the same; only the direction is different.
Phase 4: Decommission (1–2 weeks per workload)
Once a workload has run on the target infrastructure for a full billing cycle with no issues, you decommission the cloud resources. Not before.
The full process for a single workload takes 8–14 weeks. For a company moving five workloads, you can parallelise, but expect the overall programme to take 4–6 months.
What Stays on Cloud
Not everything should leave. Here is what I typically recommend keeping on a hyperscaler:
Genuinely bursty workloads. If your batch processing job needs 100 cores for 2 hours a day and zero cores for 22 hours, cloud is perfect. You are paying for exactly what you use.
Global edge requirements. If you need content delivery or compute in 40+ regions, CloudFront and Lambda@Edge are hard to beat. Building your own CDN is not a sensible use of engineering time.
Managed AI/ML services. If you are using SageMaker, Bedrock, or similar services for model training and inference, the GPU availability and managed tooling on cloud is genuinely valuable.
Regulatory sandboxes. Some compliance frameworks (FedRAMP, specific healthcare regulations) have pre-approved cloud configurations. Replicating that compliance on dedicated infrastructure may not be worth the audit cost.
Rapid experimentation environments. Spin up, test, tear down. This is what cloud was designed for, and it is still the best at it.
What Should Almost Always Leave
Conversely, some workloads are almost always cheaper off-cloud:
Steady-state web applications. Your main product, running 24/7, with predictable traffic. A dedicated server from Hetzner, OVH, or a colocation facility costs 70–80% less for the same compute and memory.
Databases with predictable storage growth. If you know your database grows 50GB per month and you need 1TB of storage, buying that storage directly is dramatically cheaper than EBS or RDS pricing.
CI/CD pipelines. Build servers run at near-100% utilisation during business hours. Self-hosted runners (GitHub Actions runners, GitLab runners) on dedicated hardware cost a fraction of cloud-hosted build minutes.
Internal tools and dashboards. Low-traffic, low-risk workloads that do not need cloud resilience. A single Hetzner box running your admin panel, monitoring stack, and internal tools costs £40/month instead of £400.
The Hybrid Model
The end state for most companies is not “fully repatriated.” It is a thoughtful hybrid:
- Core application servers on dedicated hardware (60–70% cost reduction)
- Databases on dedicated hardware with automated failover (50–70% cost reduction)
- CDN and edge on a cloud provider or specialist like Cloudflare
- Burst capacity on cloud for spikes and batch processing
- Development and staging on dedicated hardware (massive savings, low risk)
This model gives you the cost efficiency of dedicated infrastructure for predictable workloads, the elasticity of cloud for unpredictable ones, and the flexibility to shift workloads as your needs change.
Why “Just Optimise on Cloud” Is Not Enough
Cloud advocates will say: “You do not need to leave. Just optimise. Use Reserved Instances. Right-size. Use Spot.”
These are all valid tactics, and you should do them regardless. But they have a ceiling. In my experience:
- Right-sizing saves 20–40%
- Reserved Instances / Savings Plans save another 20–30% on committed spend
- Spot instances save 60–90% but only work for fault-tolerant workloads
- Combined, you might save 40–50% from your unoptimised baseline
A 50% reduction is meaningful. But dedicated hardware for steady-state workloads is 70–80% cheaper than on-demand cloud. Even after optimising your cloud spend, dedicated infrastructure is still significantly less expensive for the right workloads.
The optimisation-first approach makes sense as a starting point. It is lower risk and faster to implement. But for companies spending £100k+/month on cloud, optimisation alone is usually not enough to make the economics comfortable.
Starting the Conversation
If you are considering whether some workloads should leave cloud, start with these questions:
- What percentage of our cloud spend is steady-state compute? If it is over 60%, you have strong candidates for repatriation.
- How cloud-native are our workloads? Count the AWS-specific services each workload depends on. Fewer dependencies = easier to move.
- Do we have the operational capacity? You need at least one engineer comfortable with Linux systems administration. If you do not have that, hiring or contracting for it is part of the cost model.
- What is our timeline? Cloud exit is a 4–6 month programme, not a weekend project. Plan accordingly.
The answers will tell you whether cloud exit is worth exploring. Not whether you should move everything overnight — nobody is suggesting that. Whether a phased, workload-by-workload migration could meaningfully reduce your costs.
That is a conversation worth having.
Wondering which of your workloads are candidates for repatriation? Book a Platform Fit Verdict and we will classify your infrastructure and model the savings.