AWS to Hetzner: The Migration Budget, With Current Prices
Most AWS-to-Hetzner case studies quote a 90% saving. That figure was true, and it’s out of date — it assumed Hetzner’s cost-optimized CX line, which repriced in June 2026 and has been showing as unavailable since.
Here’s the same migration at prices you can actually get today.
The worked budget
A small but real production stack: two application nodes, a Postgres database, a load balancer, 2TB of monthly egress and basic monitoring.
On AWS:
| Line | Monthly |
|---|---|
| 2× t3.medium on-demand | $60.74 |
| RDS db.t3.micro Postgres | $21.90 |
| ALB, base plus ~1 LCU | $22.27 |
| Egress, 2TB | $175.32 |
| CloudWatch (illustrative) | $10.00 |
| Total | $290.23 |
On Hetzner, using the CPX line you can currently buy:
| Line | Monthly |
|---|---|
| 2× CPX22 (2 vCPU, 4GB) app nodes | $43.18 |
| 1× CPX22 for Postgres | $21.59 |
| Traffic | included |
| Total | $64.77 |
Saving: $225.46/month, or 78% — about $2,706 a year.
Had the CX line been available at €5.99, the same three boxes would be roughly $19.41 and the saving would be 93%. That’s where the 90% figures in older case studies come from, and it’s why we’re showing both: the headline number moved by fifteen percentage points because of a pricing change, not because the argument got weaker.
And the change is larger than the per-line percentages suggest. Because the cost-optimized tier is showing as unavailable rather than merely dearer, a 4GB buyer’s effective increase is from €5.99 to €19.99 — 234%, not 33%. We worked through what Hetzner now costs against the field, and it is no longer the cheapest option at either 4GB or 8GB.
Where the saving actually comes from
Look at the AWS column again. Egress is $175.32 of a $290.23 bill — 60% of it.
Compute is $60.74. If you migrated only the servers and kept everything else, you’d save far less than the headline suggests. AWS charges $0.09/GB for the first 10TB of data transfer out, which works out at about $92 per terabyte; Hetzner’s overage rate at its European locations is roughly €1 per terabyte.
So the honest framing: this is a bandwidth migration that happens to move your compute too. If your app doesn’t move much data, your saving will be a fraction of the number above, and you should check that before planning anything.
What you now own
Every case study buries this. Moving off RDS and managed services means re-insourcing work that AWS was doing invisibly.
Database backups. RDS took automated snapshots with point-in-time recovery. Self-managed Postgres does not, until you configure pg_dump or WAL archiving, test a restore, and monitor that it keeps happening. Untested backups are not backups.
Database failover. Multi-AZ RDS handled instance failure. A single Postgres container does not. Replication and failover are yours to build if you need them, and most small stacks quietly decide they don’t — which is a legitimate choice, made deliberately rather than by accident.
OS and database patching. Yours now, on a schedule you set and keep.
Monitoring and alerting. CloudWatch had gaps but it existed by default. You’ll want Prometheus and Grafana, or a hosted equivalent, and someone to receive the alerts.
On-call. The one nobody costs. When the box stops at 3am, the answer is you.
A realistic estimate: four to eight hours for the initial setup of backups, monitoring and alerting done properly, then two to four hours a month of patching, checking restores and responding to things. At $50/hour that’s $100–200/month of your time against a $225 saving — which is why this migration makes obvious sense for an infrastructure-comfortable team and much less for a solo founder billing client work at $150/hour.
The saving is real. It is not free.
The practical blockers
Four things that trip up real migrations, in the order you’ll hit them.
Signup review. Hetzner runs identity and fraud checks on new accounts, and new signups are sometimes delayed or ask for documentation. Open the account and get it verified before you plan a cutover weekend — it’s a poor time to discover you can’t provision servers.
Regions. Hetzner’s core locations are German and Finnish, with US locations in Ashburn, Virginia and Hillsboro, Oregon and one in Singapore. The US locations have materially different traffic allowances and, in Singapore’s case, a much higher overage rate than the European ones — so if you’re serving US or APAC users, check the allowance for the specific region before you assume the traffic economics above apply.
The latency difference between those regions is large and easy to measure, because Hetzner publishes a speed-test endpoint per datacentre. We timed them from Nuremberg and from Virginia: the Nuremberg datacentre answered a German probe in 0.60ms and its Ashburn site in 98.74ms. Pick the region your users are on, not the one with the best traffic allowance.
SES, SQS and friends are your problem. Transactional email, queues and object storage aren’t part of this migration — they’re separate replacements. Email in particular: do not try to send transactional mail from a fresh cloud IP. Use a dedicated sending provider and keep that line in your budget.
No equivalent of IAM. If your security model relies on fine-grained cross-account roles, you aren’t migrating servers, you’re rebuilding an access model. That’s the strongest reason on this page not to do this at all.
Do it in this order
- Open and verify the Hetzner account — before anything else, for the reason above.
- Measure your actual egress. It’s the majority of the saving. If it’s small, stop here.
- Replace the non-server services first — email, queues, object storage — while AWS is still running.
- Stand up the new stack in parallel and restore a database snapshot to it.
- Set up backups and monitoring before cutover, not after. This is the step that gets deferred and shouldn’t be.
- Lower DNS TTL a day ahead, then cut over.
- Keep AWS running for a week. Budget for the double-billing month.
- Export data out of AWS deliberately — egress out is charged at the same $0.09/GB, so a 5TB move costs roughly $452 once.
If Hetzner isn’t the answer
Hetzner is the destination this article is about, and worth two caveats before you commit: check CX availability, because the CPX line you’d otherwise use is several times dearer, and check the traffic allowance for your specific region.
DigitalOcean is the middle path at $24 for 4GB — dearer than Hetzner, far cheaper than AWS, with documentation, predictable APIs and generous included transfer. If the reason you’re leaving AWS is cost but the reason you’re hesitating is operational risk, that’s the compromise. Its tracked link isn’t working on our end, so we’ve named it without linking.
IONOS is the other European option and the best value per vCPU we’ve measured — four cores on a 4GB plan at $11 — with a three-month promotional window, so budget the renewal.
Cloudzy bills month-to-month with no term, which suits running a parallel stack during migration without committing to it.
For the broader comparison rather than this specific move, AWS alternatives sorts the options by workload.
How we checked this
AWS pricing is published on-demand rates for us-east-1 read in August 2026: t3.medium at $0.0416/hour (about $30.37/month), RDS db.t3.micro for PostgreSQL at about $21.90/month with storage billed separately, and an Application Load Balancer at $0.0225/hour plus LCU charges. The ALB and CloudWatch figures are the softest in the table — ALB cost depends on LCU consumption and CloudWatch on what you actually log, so we’ve used one LCU and a nominal $10 respectively. Egress is calculated at AWS’s published $0.09/GB after the first 100GB free.
Hetzner’s CPX22 at €19.99 including its IPv4 charge, and the CX23 at €5.99 with its unavailable status, are its published figures, converted at approximately 1.08. We could not verify Hetzner load balancer pricing — its page shows tiers (LB11 with 1TB included traffic, LB21 with 2TB, LB31 with 3TB) but doesn’t display prices without selecting a location. The Hetzner column therefore excludes a load balancer while the AWS column includes an ALB, which flatters Hetzner by whatever that costs. Add it before you rely on the total.
On regional traffic allowances: Hetzner’s own plan data shows markedly smaller included traffic at its US and Singapore locations than in Europe, and a higher overage rate in Singapore. We flagged this in our AWS alternatives piece and repeat it here because a US-region migration may not inherit the traffic economics this article’s headline depends on.
The hours estimate is ours and unmeasured — four to eight hours of setup and two to four hours a month afterwards. It is the number most likely to be wrong for your team, and it’s also the number that decides whether this migration is worth doing, so substitute your own rather than ours.
What we did not do: we have not performed this migration, benchmarked either provider, or run a stack on Hetzner in any US region. The budget is arithmetic on published prices for a stack we defined, not a real invoice from a real migration.
The hosting links above are affiliate links. The article’s advice to measure your egress first, and stop if it’s small, is the one most likely to result in you not migrating at all.
FAQ
How much can I save migrating from AWS to Hetzner?
On a small stack with 2TB of egress, about 78% — $290 down to $65 a month. Older case studies quote 90%, which assumed Hetzner’s cheaper CX line before its June 2026 repricing and current unavailability.
Where does the saving actually come from?
Mostly egress. In our worked example, data transfer is $175 of a $290 AWS bill. AWS charges about $92 per terabyte; Hetzner’s European overage is around €1. If your app doesn’t move much data, the saving shrinks dramatically.
What do I take on by moving off RDS?
Backups with tested restores, failover if you need it, patching, monitoring and on-call. Budget four to eight hours to set up properly and two to four hours a month after.
Are there blockers to signing up with Hetzner?
New accounts go through identity and fraud review, which can delay provisioning. Open and verify the account well before any planned cutover.
Does Hetzner have US regions?
Yes — Ashburn, Virginia and Hillsboro, Oregon, plus Singapore. Check the included traffic allowance for your specific region, because it differs substantially from the European figures.
What about SES, SQS and S3?
Not part of this migration — they’re separate replacements. Transactional email in particular needs a dedicated sending provider; don’t send from a fresh cloud IP.
When should I not migrate to Hetzner?
If you depend on fine-grained IAM, if you’re regulated and multi-region, or if your egress is small enough that the saving doesn’t cover the operational work you’re taking on.
