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 infrastructure runs primarily on US-based servers under US jurisdiction, exposing your data to the CLOUD Act. Hetzner operates data centres in Germany and Finland, fully within the EU and GDPR framework. Beyond data sovereignty, Hetzner is dramatically more cost-effective: comparable cloud servers often cost 50-80% less than 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?