Denys Zaruin

Posted on Oct 29 Edited on Oct 29 Originally published at moveinfra.eu

Moving from AWS to Hetzner: What You Gain and What You Must Build

#cloud #aws #hetzner #cloudmigration

Originally published on moveinfra.eu.

Moving from AWS to Hetzner gives European companies much lower compute and network costs, predictable monthly billing, and strict German legal jurisdiction, while requiring engineering teams to self-manage services that AWS runs for them. Hetzner provides core infrastructure building blocks—including virtual servers, dedicated bare-metal machines, block volumes, S3-compatible object storage, private networks, firewalls, and load balancers—at a fraction of hyperscaler prices. However, Hetzner does not offer managed relational databases (like AWS RDS), managed Kubernetes (like Amazon EKS), managed caching (like ElastiCache), or serverless queues and functions. If your architecture relies on these services, migrating to Hetzner means deploying and operating them yourself on virtual or dedicated servers, or choosing another European provider that offers managed platform services.

Key takeaways

Substantial cost reductions on compute and egress: Hetzner bundles generous outbound data transfer (typically 20 TB per server in European locations) and charges a single flat rate for compute, removing the complex per-gigabyte NAT gateway and egress fees common on AWS.
True European jurisdiction: Hetzner Online GmbH is headquartered in Germany and operates data centers in Nuremberg and Falkenstein (Germany) and Helsinki (Finland), keeping your infrastructure outside the reach of US extraterritorial laws.
No managed databases or Kubernetes: Unlike AWS, Hetzner focuses strictly on Infrastructure as a Service (IaaS). You must run PostgreSQL, MySQL, Redis, and Kubernetes on your own cloud or dedicated instances using open-source tools and automation.
Simpler networking and permissions: You trade AWS's sprawling IAM policies and multi-layered VPC billing for straightforward cloud firewalls, private networks, and project-based API tokens.
Regulatory tailwinds for switching: Under the EU Data Act (Regulation (EU) 2023/2854), cloud providers can charge no more than their direct cost for switching egress until January 12, 2027, after which switching fees are banned completely.

Why European companies move from AWS to Hetzner

For most 10-to-300-person companies in Europe, the initial push to evaluate Hetzner comes from looking at the monthly AWS bill. On AWS, compute is rarely the only major expense. Costs accumulate through managed service premiums, per-gigabyte charges for traffic passing through NAT gateways, cross-availability-zone data transfer fees, and outbound internet egress.

Hetzner structures its pricing around flat, predictable resource usage. Whether you rent shared-CPU virtual machines, dedicated-CPU cloud instances, or physical bare-metal servers through Hetzner Robot, the monthly ceiling is clear. In European regions, cloud servers include 20 TB of outbound traffic per month at no additional charge, and internal traffic over Hetzner Private Networks is free. You should always check Hetzner's official pricing page for current figures, especially following their June 2026 price adjustments on dedicated hardware, as exact numbers depend on server generation and location.

The second driver is legal and operational sovereignty. Even if you deploy workloads in the AWS Frankfurt (eu-central-1) region or use the AWS European Sovereign Cloud, the underlying provider remains Amazon, a US corporation subject to the US CLOUD Act. Hetzner Online GmbH is a privately owned German company founded in 1997. When you host in its German or Finnish data centers, both the physical hardware and the corporate parent fall strictly under EU and national law. For companies subject to strict GDPR interpretations by enterprise customers, or financial entities building exit strategies under the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), moving to a domestic European provider simplifies compliance audits.

Finally, there is engineering clarity. AWS offers over two hundred services, which often leads small engineering teams to build overly complex architectures. Moving to Hetzner forces a return to standard Linux servers, containers, and open-source software that can run anywhere.

AWS to Hetzner service mapping

Before planning a migration, both technical leads and finance teams need an honest view of how AWS components translate to Hetzner. Some services map directly, while others shift operational responsibility back to your team.

AWS Service	Hetzner Equivalent	What Changes in Practice
EC2 (Virtual Servers)	Hetzner Cloud VMs / Dedicated Servers	Direct replacement. Available in shared x86, Arm64 (Ampere), dedicated vCPU, and bare-metal options.
EBS (Block Storage)	Hetzner Cloud Volumes	Network-attached block storage expandable up to 10 TB per volume. Attached directly to Cloud VMs.
S3 (Object Storage)	Hetzner Object Storage	Native S3-compatible object storage. Supports standard S3 API calls, buckets, and access keys, though advanced AWS-specific features (like S3 Select or Glacier) are not present.
ALB / NLB (Load Balancers)	Hetzner Cloud Load Balancers	Managed Layer 4 (TCP) and Layer 7 (HTTP/HTTPS) load balancers with automated Let's Encrypt TLS certificates and health checks.
VPC & Security Groups	Private Networks & Cloud Firewalls	Simpler flat private routing across servers and stateful firewall rules applied via server labels or direct assignment.
Route 53 (DNS)	Hetzner DNS Console	Supports standard DNS zone management via UI and API, without complex geo-proximity or latency-based routing policies.
RDS / Aurora (PostgreSQL, MySQL)	None (Self-managed on VMs)	You must install, configure, replicate, and back up databases on Hetzner servers yourself.
EKS / ECS (Containers)	None (Self-managed on VMs)	You must bootstrap and maintain your own Kubernetes cluster (e.g., via k3s, Talos, or kubeadm) on Hetzner VMs.
ElastiCache (Redis)	None (Self-managed on VMs)	Requires running Redis or Valkey directly on virtual machines with Sentinel or cluster configuration for high availability.
SQS / SNS / EventBridge	None (Self-managed on VMs)	Requires deploying RabbitMQ, NATS, Redis streams, or database-backed job queues on your own compute instances.
AWS IAM	Project Access & API Tokens	Hetzner uses team roles at the project level and read/write API tokens rather than granular per-resource policy documents.

What you must build and operate yourself

The financial savings on Hetzner are real, but they are not free money. A portion of what you stop paying Amazon is traded for engineering ownership. Here is what your team must be prepared to build and maintain.

1. Relational databases and high availability

On AWS RDS, enabling Multi-AZ high availability, automated point-in-time recovery (PITR), and minor version upgrades takes a few clicks. Because Hetzner does not offer managed databases, you must build this resilience on top of Hetzner Cloud VMs or dedicated servers.

In a production environment, you should not simply run a single apt install postgresql instance without safeguards. To match RDS reliability, teams typically deploy a two- or three-node cluster managed by open-source orchestrators like Patroni (with etcd or Consul for consensus), or use automated provisioning stacks. You must also configure continuous Write-Ahead Log (WAL) archiving and daily base backups using tools like pgBackRest or WAL-G, pushing encrypted backups to Hetzner Object Storage (or an external backup destination). Crucially, you must test restoring these backups regularly.

2. Kubernetes or container orchestration

If you run microservices on Amazon EKS or AWS Fargate, moving to Hetzner means taking over the Kubernetes control plane. While EKS manages the API servers and etcd nodes for you, on Hetzner you will run both control-plane nodes and worker nodes on your own virtual machines.

Fortunately, the open-source ecosystem around Hetzner is mature. Many European teams run lightweight distributions like k3s or immutable Kubernetes operating systems like Talos Linux on Hetzner Cloud. Hetzner maintains official open-source integrations that make Kubernetes behave like a native cloud environment:

Hetzner Cloud Controller Manager (HCCM): Automatically provisions Hetzner Load Balancers when you create a Kubernetes Service of type LoadBalancer and configures private network routing between nodes.
Container Storage Interface (CSI) Driver: Automatically creates, attaches, and resizes Hetzner Cloud Volumes when your pods request PersistentVolumeClaims.
Cluster Autoscaler: Adds or removes Hetzner worker VMs based on pending pod resource requests.

Even with these drivers, your team remains responsible for upgrading Kubernetes versions, rotating certificates, and monitoring etcd health.

3. Caching, queues, and background jobs

Many AWS architectures rely heavily on SQS for decoupling services, Lambda for cron jobs and webhooks, and ElastiCache for session storage. When moving to Hetzner, architectural simplification helps a great deal.

Instead of replacing every AWS primitive with a separate distributed system, evaluate whether your existing stack can absorb the workload. For example, if you run PostgreSQL, tools like pg-boss (Node.js), Oban (Elixir), or Solid Queue (Ruby) let you run reliable background jobs directly inside your database, removing the need for a separate SQS replacement. If you need high-throughput message brokering or caching, you will need to provision dedicated VMs running Valkey, Redis, or RabbitMQ via Terraform and Ansible, wired into your monitoring stack.

4. Observability, logging, and alerting

Without AWS CloudWatch collecting logs and metrics by default, you need a self-hosted or third-party observability stack. On Hetzner, teams normally deploy the Prometheus and Grafana stack (alongside node_exporter and Loki for logs) on a dedicated monitoring VM, or ship telemetry to a European-hosted observability service. You will also need to configure alert routing (via Alertmanager or similar) to wake up your on-call engineers if a disk fills up or a database node fails over.

5. Access control and secret management

AWS IAM lets you restrict a specific server to reading a single S3 bucket or writing to one DynamoDB table. Hetzner's Cloud API uses bearer tokens that grant access to an entire project. This means you must be careful about where you place Hetzner API keys (such as inside your Kubernetes cluster for the CSI driver). For application secrets that previously lived in AWS Secrets Manager or SSM Parameter Store, you will need to adopt encrypted secrets in Git (using SOPS or Sealed Secrets), use your CI/CD platform's secret injection, or host a vault service like HashiCorp Vault or OpenBao.

When Hetzner is the right choice (and when to pick another EU cloud)

Hetzner is an exceptional fit if:

Your team has at least one engineer comfortable with Linux administration, Terraform, and Docker or Kubernetes.
You run compute-heavy, memory-heavy, or bandwidth-heavy workloads where AWS costs scale poorly.
Your architecture is relatively clean—such as a monolithic web application or a sensible set of containerized services backed by PostgreSQL, Redis, and S3 object storage.

However, if your company has no dedicated DevOps or platform engineering capacity, and leadership does not want engineers spending time maintaining database replication or Kubernetes upgrades, Hetzner may require too much operational overhead. In that case, you do not have to stay on AWS. Other European cloud providers—such as UpCloud, Scaleway, or OVHcloud—offer managed PostgreSQL/MySQL databases and managed Kubernetes control planes out of the box. You will pay more per CPU core on those platforms than on Hetzner, but still generally less than on AWS, while keeping managed database convenience under European jurisdiction.

Practical migration checklist: AWS to Hetzner

If you decide to move to Hetzner, follow a structured process to keep downtime to a minimum and preserve a clean rollback path.

Audit your AWS footprint and egress: List every active resource across your AWS regions. Identify hidden dependencies like Lambda functions triggered by S3 events, hard-coded IAM role assumptions (sts:AssumeRole), and proprietary databases like DynamoDB. Note that under Article 29 of the EU Data Act, you can request switching terms from AWS where data egress fees are capped at direct cost until January 12, 2027, and eliminated thereafter.
Define your Hetzner architecture in Terraform: Do not click around in the Hetzner Cloud Console to build production. Use the official hcloud Terraform provider to define your private networks, firewalls, load balancers, and compute nodes. Set up automated configuration management (such as Ansible or cloud-init) to bootstrap your database clusters and container hosts.
Clone object storage with checksums: Create your buckets in Hetzner Object Storage. Use an S3 synchronization tool like rclone to copy objects from AWS S3 to Hetzner, verifying file integrity with checksums. Keep periodic syncs running until cutover day.
Establish live database replication: Rather than taking a multi-hour downtime window to dump and restore your database, set up logical replication from AWS RDS to your new PostgreSQL or MySQL cluster on Hetzner. Connect the two environments over an encrypted VPN tunnel (such as WireGuard) so your Hetzner database stays within seconds of your live AWS database.
Update your CI/CD pipelines: Adjust your GitHub Actions or GitLab CI workflows to deploy your application containers to the new Hetzner environment in parallel with AWS. Run end-to-end tests against the Hetzner staging endpoints.
Lower DNS TTLs and execute the switch: A few days before migration, lower your DNS Time-To-Live (TTL) values to 60 seconds. During a planned low-traffic window, put your application into a brief maintenance/read-only mode, verify that database replication lag is zero, run a final S3 sync, promote the Hetzner database to primary, and update your DNS records to point to the Hetzner Load Balancer.
Maintain a rollback option before cleanup: Keep your old AWS environment running and configure reverse replication from Hetzner back to AWS if possible, or maintain snapshots for at least 30 days. Once everything runs smoothly through a full monthly billing cycle, decommission your AWS resources.

Frequently asked questions

Does Hetzner have an equivalent to AWS S3?

Yes. Hetzner offers native, S3-compatible Object Storage. You can interact with it using the standard AWS CLI, SDKs, or Terraform providers by changing the endpoint URL to Hetzner's regional object storage endpoint. It supports standard bucket operations, access keys, and public/private visibility, though it does not include AWS-specific extensions like S3 Glacier archival tiers or EventBridge notifications.

How do we handle high-availability databases on Hetzner without RDS?

Because Hetzner does not sell a managed database service, high availability is achieved by provisioning multiple Hetzner Cloud VMs across different physical availability zones or data center locations, attached to local NVMe disks or Cloud Volumes. You then run an automated failover manager like Patroni for PostgreSQL, combined with automated backup tools (such as pgBackRest) that stream backups continuously to S3-compatible object storage.

Can we mix Hetzner Cloud VMs and Dedicated Servers in the same network?

Yes. Through the Hetzner vSwitch feature, you can connect dedicated bare-metal servers from Hetzner Robot directly into your Hetzner Cloud Private Networks. This allows teams to run stateless web applications on flexible Cloud VMs while placing heavy, predictable database workloads on high-performance bare-metal NVMe servers over private internal IPs.

Will we have to pay huge AWS data egress fees when moving our data to Hetzner?

Data egress fees are shrinking due to European regulation. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers operating in the EU may only charge the direct cost incurred for switching data egress until January 12, 2027, and from January 12, 2027 onward, all switching charges—including data egress fees when moving to another provider—are banned. Furthermore, AWS offers a specific fee waiver program for customers permanently migrating off the platform under the Data Act framework.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

DEV Community