How to Migrate from AWS to Hetzner
Step-by-step guide to move your cloud infrastructure from Amazon Web Services to Hetzner, the cost-effective German hosting provider.
Prerequisites
- An AWS account with documented infrastructure
- A Hetzner Cloud account
- SSH access to both environments
- Basic server administration skills
Steps
-
Audit AWS resources
Inventory all EC2 instances, databases, storage buckets, and networking configurations in your AWS account.
-
Provision Hetzner servers
Create equivalent cloud servers or dedicated machines in Hetzner Cloud matching your workload requirements.
-
Migrate databases
Export databases from RDS or self-managed instances and import them into your new Hetzner database servers.
-
Transfer applications
Deploy your application code and configurations to the new Hetzner infrastructure using your CI/CD pipeline.
-
Update DNS
Point your domain DNS records to the new Hetzner server IP addresses with reduced TTL for quick rollback.
-
Testing and cutover
Run full integration tests on Hetzner, then perform the final cutover and decommission AWS resources.
Why Migrate from AWS to Hetzner?
AWS is a US company, so the data it hosts — even in its EU regions — is exposed to the CLOUD Act. Hetzner is a German company with its own data centres in Germany and Finland, fully within the EU and GDPR framework. (Hetzner also offers cloud locations in the US and Singapore; choose Nuremberg, Falkenstein or Helsinki to keep your data in the EU.) Beyond data sovereignty, Hetzner is dramatically more cost-effective: comparable cloud servers often cost a fraction of their AWS equivalents, with transparent pricing and no hidden egress fees.
Hetzner also runs its data centres on renewable energy and has a strong commitment to sustainability, making it a responsible infrastructure choice.
Detailed Migration Steps
Step 1: Audit AWS Resources
Before migrating, create a complete inventory:
- List all EC2 instances with their specs (CPU, RAM, storage)
- Document RDS databases (engine, version, size)
- Catalog S3 buckets and their total storage usage
- Map VPC networking, security groups, and load balancers
- Note any AWS-specific services (Lambda, SQS, etc.) that need alternatives
Use aws cli or the AWS Console to export this information. Services tightly coupled to AWS (like Lambda) will require refactoring.
Step 2: Provision Hetzner Servers
Using the Hetzner Cloud Console or the hcloud CLI:
- Create cloud servers matching your EC2 instance specifications
- Select the data centre location (Falkenstein, Nuremberg, or Helsinki)
- Set up firewalls equivalent to your AWS security groups
- Configure private networks for inter-server communication
- Attach volumes for persistent storage needs
Step 3: Migrate Databases
For PostgreSQL or MySQL databases:
- Create a database dump on AWS:
pg_dumpormysqldump - Transfer the dump file to Hetzner via
scporrsync - Import on the Hetzner server:
psqlormysql < dump.sql - Verify row counts and data integrity
- Set up replication temporarily if you need zero-downtime migration
Step 4: Transfer Applications
Deploy your application stack on Hetzner:
- Use your existing CI/CD pipeline (GitLab CI, GitHub Actions) pointed at Hetzner
- Install dependencies and configure environment variables
- Set up reverse proxy (nginx/Caddy) and TLS certificates (Let’s Encrypt)
- For S3 replacement, consider Hetzner Object Storage or a self-hosted MinIO instance
Step 5: Update DNS
Prepare for the switchover:
- Lower DNS TTL to 60 seconds at least 24 hours before cutover
- Update A/AAAA records to point to Hetzner IPs
- Update any CNAME records for subdomains
- Monitor DNS propagation with tools like
digor whatsmydns.net
Step 6: Testing and Cutover
- Run full integration and load tests against the Hetzner environment
- Perform a final database sync if using replication
- Switch DNS and verify traffic flows to Hetzner
- Monitor application logs and metrics closely for 48 hours
- Decommission AWS resources only after confirming stability
Tips for a Smooth Migration
- Use Hetzner’s Terraform provider for infrastructure-as-code deployments
- Consider a parallel-run period where both environments handle traffic
- Set up monitoring early (Prometheus, Grafana) on Hetzner before cutover
- Keep AWS resources for 30 days post-migration as a rollback safety net
- Budget for potential egress charges from AWS during the data transfer phase
Was this helpful?