Self Hosting on Hetzner vs AWS: The Real Tradeoffs

What you need to know

• Hetzner compute is roughly 10x cheaper than AWS for equivalent specifications. The price difference is real and significant.
• Hetzner does not offer HIPAA BAAs, managed databases with automatic failover, or global distribution across dozens of regions.
• Self-hosting on commodity infrastructure requires DevOps engineering time that has a real cost even if not directly billed.
• For EU data residency requirements, Hetzner's German and Finnish data centers are a compliance advantage over US-based cloud providers.
• The right choice is Hetzner for compute-intensive workloads with strong DevOps capability, and AWS for managed-service-dependent or compliance-sensitive applications.

The core argument

The Hetzner vs AWS decision is not primarily a technology decision. It is a team capability and product requirements decision. Hetzner is genuinely cheaper for raw compute, and the price difference is large enough to matter for products where compute is a significant cost line. A team that can manage its infrastructure competently and does not need HIPAA compliance or heavy reliance on AWS managed services can run a significantly more cost-effective infrastructure on Hetzner.

The hidden cost in the Hetzner choice is the operational overhead of the things AWS manages. A managed RDS PostgreSQL instance on AWS includes automated backups, point-in-time recovery, automatic minor version upgrades, and failover for multi-AZ deployments. Running PostgreSQL on a Hetzner server means the team is responsible for all of those things. A team that has done this before knows what it involves and has the processes for it. A team encountering database management for the first time will discover the operational overhead after the first incident.

In my experience, the team that benefits most from Hetzner is the one that has already operated on AWS and learned what managed services cost (both in money and in operational convenience) before making the switch. Teams that start on Hetzner without prior managed-service experience often underestimate the operational overhead and spend more engineering time on infrastructure than they saved in cloud costs.

Common mistakes

1. Comparing raw compute prices without accounting for managed service replacements. If the team runs PostgreSQL on Hetzner, the correct cost comparison is not Hetzner instance vs RDS instance. It is Hetzner instance + DevOps engineering time for database management vs RDS instance cost. For teams with a dedicated DevOps engineer, the math often favors Hetzner. For teams without one, the math is less clear.

1. Assuming Hetzner is faster to set up than AWS. Hetzner provides servers, not configured infrastructure. Initial setup on Hetzner requires more work than deploying on a PaaS or using managed services: configuring firewall rules, setting up monitoring, deploying load balancers, and configuring deployments. The ongoing cost is lower, but the upfront engineering investment is higher than using managed platforms.

1. Not testing Hetzner's network throughput and latency for the product's use case. Hetzner's European data centers have excellent throughput and latency for European-based users. Products serving primarily US or Asian users may see higher latency from Hetzner's Ashburn data center compared to US-based AWS regions. Test the actual latency from target user locations before committing to Hetzner for a latency-sensitive application.

1. Ignoring the lock-in direction. Moving from AWS to Hetzner requires re-architecting managed service dependencies (replacing RDS with self-managed Postgres, replacing SQS with Redis-based queues, replacing Lambda with container-based jobs). This migration has a real cost. Moving from Hetzner to AWS is easier because managed services are additive. Choose Hetzner when the team is confident it will not need AWS-specific managed services at scale.

1. Not using Hetzner Cloud for elastic compute alongside dedicated servers. Hetzner Cloud (virtual machines) is elastic; dedicated servers have a minimum commitment period. For applications with variable load, using Hetzner Cloud for burst capacity while running base load on dedicated servers combines the cost efficiency of dedicated hardware with the elasticity of virtual instances.

Where to start

1. List the AWS managed services the product currently uses and find their self-managed equivalents. For each managed service, estimate the DevOps time to manage the equivalent self-hosted version. If the total DevOps overhead is less than the cost difference between Hetzner and AWS, Hetzner is the economically favorable choice. If the overhead is comparable or larger, the cost comparison is neutral or negative.

1. Run a pilot deployment on Hetzner for a non-critical service. Deploy one service (a background job processor, a static site, a development environment) on Hetzner. Measure the setup time, learn the operational patterns, and assess whether the team can manage the infrastructure comfortably. This pilot produces real data about the operational overhead before committing the full infrastructure.

1. Calculate the 12-month cost difference for the current infrastructure. Compare what the current AWS monthly bill would be if migrated to Hetzner equivalent servers. Multiply the difference by 12. This is the potential annual saving. Compare it against the estimated migration engineering cost and ongoing DevOps overhead. If the saving is larger, proceed. If it is not, the effort is better spent elsewhere.

Related reading

• Render vs Fly.io vs Railway vs Heroku in 2026
• Serverless vs Containers vs Bare Metal: A Cost and Flexibility Map
• Reserved Instances and Cost Math: When They Pay Off
• Secrets in CI: The Patterns That Avoid Leaks