TL;DR — For most mid-scale SaaS workloads we run on Hetzner, not AWS. On equivalent compute and bandwidth, Hetzner is typically 4–8× cheaper. AWS still wins where you actually use its managed services — DynamoDB, Lambda, EventBridge, multi-region failover — but most products use a fraction of what they pay for.
The math, on a real workload
Take a typical mid-scale SaaS profile: 4 application servers (8 vCPU / 32GB each), a primary PostgreSQL with one replica, Redis cache, object storage (~500 GB), CDN, and ~10 TB egress per month.
| Component | AWS (approx) | Hetzner (approx) |
|---|---|---|
| 4× app servers (8 vCPU / 32GB) | ~$1,200 /mo | ~$200 /mo |
| Postgres + replica (managed) | ~$600 /mo (RDS db.r6g.xlarge×2) | ~$120 /mo (self-managed on dedicated) |
| Redis cache | ~$150 /mo (ElastiCache) | ~$15 /mo (self-managed) |
| Object storage (500 GB) | ~$12 /mo (S3) | ~$5 /mo (Storage Box) |
| 10 TB egress | ~$900 /mo | $0 (included) |
| Total | ~$2,860 /mo | ~$340 /mo |
That is a ~8× difference. Even adding operational overhead — backup automation, monitoring, OS patching — Hetzner stays cheaper by a wide margin.
What AWS gives you that Hetzner does not
- Managed services depth. DynamoDB, Lambda, EventBridge, Step Functions, Kinesis. If you use these heavily, the migration cost is significant.
- Multi-region failover. Route 53 + cross-region replication is genuinely turnkey on AWS.
- Compliance posture. If your enterprise customers require AWS-specific certifications in their security questionnaires, that constraint may be non-negotiable.
- Auto-scaling primitives. ASGs, ECS Fargate, Lambda concurrency — Hetzner has nothing equivalent without you building it.
When to stay on AWS
- You actively use managed services (DynamoDB, Lambda, SQS) for more than 30% of the workload
- You need multi-region active-active failover
- Enterprise customers contractually require AWS
- You are early-stage and engineering time is more valuable than infrastructure cost
How to migrate without bringing complexity
- Containerize first. Docker on AWS first, then move the same containers to Hetzner. No rewrites.
- Replace managed services with self-managed equivalents on day one. Move SQS to a PostgreSQL queue or Redis Streams; replace DynamoDB with Postgres JSONB; replace Lambda with long-running workers.
- Keep an escape hatch. Hetzner’s network and DNS interoperate fine with Cloudflare and AWS — you can fall back to AWS for one component (e.g. SES, Route 53) if needed.
- Invest in monitoring before migration. Self-managed databases need observability. Set up Prometheus + Grafana + Sentry before you cut over, not after.
The honest cost of self-managed
The cost AWS users do not pay shows up elsewhere on Hetzner: someone has to set up replication, run backups, patch the OS, monitor disk space and design the failover. With senior engineers on the team, this is a few days a month — well worth the savings. With a junior team, it is a constant time sink. The choice is not just price; it is who is operating the platform.
Frequently asked questions
Does Hetzner have multi-region failover like AWS?
Hetzner has multiple data centers in Germany and Finland plus a US presence, but multi-region failover is not built-in like Route 53 + multiple AWS regions. You build it yourself with floating IPs, replication and DNS — feasible, but more work.
Is Hetzner suitable for production?
Yes — many SaaS companies run production on Hetzner. The trade-off is fewer managed services, so you operate more of the stack yourself. For most mid-scale products, the cost savings outweigh the operational delta.
Working on something similar?
T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.