Von AWS zu Hetzner migrieren: der realistische Leitfaden

Das Internet ist voll mit „AWS zu Hetzner in einem Wochenende!"-Artikeln. Für ein Hobby-Projekt stimmt das sogar. Für ein Unternehmen mit zahlenden Kunden, SLAs und einer Datenbank, deren Verlust existenzbedrohend wäre, ist es fahrlässig. Hier ist der Ablauf, wie er in ernsthaften Projekten tatsächlich aussieht — inklusive der Stellen, an denen es weh tut.

Phase 0: Die Inventur (die fast alle überspringen)

Bevor irgendetwas migriert wird, braucht es eine vollständige Antwort auf drei Fragen: Was läuft? Was redet mit was? Was kostet was? Klingt banal — aber in vier Jahren gewachsene AWS-Accounts enthalten fast immer Überraschungen: vergessene Instanzen, verwaiste EBS-Volumes, Elastic IPs für längst abgeschaltete Dienste, ein Lambda, das seit 2023 stündlich gegen eine tote API läuft.

• Cost Explorer nach Service und Tag auswerten — die Rechnung ist die ehrlichste Inventarliste
• Alle Services mit Abhängigkeiten kartieren (wer spricht mit RDS? was liest aus S3? welche IAM-Rollen existieren wofür?)
• „Zombie-Infrastruktur" markieren: In unseren Projekten sind im Schnitt 5–15 % der Rechnung ersatzlos streichbar — vor jeder Migration

Phase 1: Das Service-Mapping

Jeder AWS-Service bekommt ein Ziel: ein Hetzner-Äquivalent, eine Self-Hosted-Lösung — oder die ehrliche Einstufung „bleibt vorerst". Die Kurzfassung für die häufigsten Fälle:

• EC2 → Hetzner Cloud / dedizierte Server. Der einfache Teil. Faustregel aus der Praxis: gleiche Leistung für einen Bruchteil des Preises, dedizierte vCPUs inklusive.
• RDS (PostgreSQL/MySQL) → selbst betrieben oder HA mit Patroni. Hetzner hat kein Managed-DB-Angebot wie RDS — das ist die wichtigste Architektur-Entscheidung der ganzen Migration. Optionen: dedizierter DB-Server mit sauberem Backup-Konzept (reicht erstaunlich oft), Patroni-Cluster für echtes HA, oder Managed PostgreSQL bei einem zweiten EU-Anbieter.
• S3 → Hetzner Object Storage. S3-kompatible API: Meist genügt ein neuer Endpoint plus rclone sync für die Daten. Achtung bei Features wie Event-Notifications oder Lifecycle-Regeln — die brauchen Ersatzlösungen.
• ELB/ALB → Hetzner Load Balancer plus Traefik/Nginx für das Routing, cert-manager für TLS.
• Lambda/SQS/EventBridge → Container-Worker + NATS/RabbitMQ. Der teuerste Posten. Ehrliche Ansage: Wer tief im Serverless-Ökosystem steckt, migriert hier nicht, sondern baut um. Das kann sich trotzdem rechnen — aber es gehört als Umbau ins Budget, nicht als Umzug.

Die vollständige Übersetzungstabelle — auch für Cognito, CloudWatch, Secrets Manager & Co. — führen wir auf der Alternativen-Seite.

Phase 2: Zielumgebung als Code aufbauen

Die neue Umgebung entsteht parallel — als Terraform/Ansible-Code, nicht als Klick-Session. Das dauert anfangs länger und ist genau deshalb richtig: Ab jetzt ist jede Änderung reproduzierbar, jede Umgebung (Staging = Produktion) identisch, und der Rollback ist eine Frage von Minuten statt von Archäologie. Wie wir solche Umgebungen strukturieren, steht im Detail auf unserer Deployment-Seite.

Phase 3: Daten synchronisieren & Parallelbetrieb

Jetzt kommt der Teil, der über Erfolg oder Wochenend-Katastrophe entscheidet:

1. Datenbank-Replikation aufsetzen: logische Replikation (PostgreSQL) bzw. Replica + Sync zur neuen Umgebung. Ziel: Die neue DB läuft der alten nur Sekunden hinterher.
2. Object-Storage-Sync: initialer rclone-Vollabgleich (bei Terabytes: Tage einplanen — Egress-Kosten für den Abzug aus AWS einmalig ins Budget nehmen), danach Delta-Syncs.
3. Staging unter echter Last testen: Traffic-Replay oder Shadow-Traffic gegen die neue Umgebung. Lasttests, Failover-Tests, Restore-Test des neuen Backup-Konzepts — vor dem Cutover, nicht danach.
4. DNS-TTL senken (z. B. auf 300 Sekunden), Tage vor dem Cutover — der unspektakulärste Schritt mit der größten Wirkung auf die Umschaltdauer.

Phase 4: Der Cutover

Wenn alles Vorherige sauber war, ist der Cutover selbst fast langweilig — und genau so soll er sein: Schreibzugriffe kurz anhalten, finale Datenbank-Synchronisation, DNS umschalten, Health-Checks beobachten. In gut vorbereiteten Projekten reden wir über ein Wartungsfenster von Minuten — oder über gar keins. Die alte AWS-Umgebung bleibt danach noch zwei bis vier Wochen eingefroren bestehen: Sie ist der Rollback-Plan.

Die fünf häufigsten Fehler (die wir aufräumen dürfen)

1. Big-Bang statt Parallelbetrieb. „Wir schalten am Samstag um" funktioniert bis zur ersten Überraschung — und die kommt immer. Parallelbetrieb kostet ein paar Wochen Doppel-Infrastruktur und erspart schlaflose Nächte.
2. Die Datenbank unterschätzen. 90 % der Migrations-Downtime entsteht rund um die Datenbank. Wer hier mit „Dump und Restore reicht schon" plant, plant sein Wartungsfenster in Stunden statt Minuten.
3. Egress-Kosten vergessen. AWS berechnet den Datenabzug. Bei großen S3-Buckets ist das ein realer einmaliger Posten, der in den Business Case gehört — danach ist das Thema Egress dafür für immer erledigt.
4. IAM-Abhängigkeiten übersehen. Anwendungen, die implizit über Instance-Rollen auf AWS-APIs zugreifen, fallen erst in der neuen Umgebung auf — bei der Inventur systematisch nach SDK-Aufrufen suchen.
5. Den Betrieb danach nicht klären. Hetzner betreibt keine Datenbank für Sie. Ohne Antwort auf „Wer patcht, wer überwacht, wer wird nachts geweckt?" wird aus der Ersparnis ein Risiko. Optionen: eigenes Team, Dienstleister, Hygge Care.

Was kostet das — und was bringt es?

Realistische Hausnummern aus typischen Projekten: Migrationsprojekte für Startup-/KMU-Setups liegen zwischen 15.000 und 80.000 € (je nach Komplexität, v. a. Serverless-Anteil und Datenbank-Anforderungen). Dem stehen laufende Einsparungen von meist 50–70 % der Infrastrukturkosten gegenüber — der Break-even liegt damit häufig unter einem Jahr. Für eine erste Schätzung mit Ihren Zahlen: unser Kostenrechner, ohne Anmeldung.