Alternativen zu Hetzner.

Hetzner ist der umgekehrte Fall zu den meisten Tools auf dieser Seite: kein US-Platzhirsch, den man verlassen will, sondern einer der stärksten europäischen Kandidaten in unserem eigenen Verzeichnis. 1997 als Familienunternehmen in Gunzenhausen gegründet, EU-eigen, EU-gehostet in Falkenstein, Nürnberg und Helsinki, ISO 27001 und BSI C5 Typ 2 testiert, mit CLOUD-Act-Risiko: Keines und Preisen ab €4. Wer nach einer Hetzner-Alternative sucht, tut das fast nie wegen der Souveränität. Es geht um das, was Hetzner bewusst nicht verkauft: Managed Databases, Managed Kubernetes, Enterprise-SLAs, breite GPU-Kapazität oder eine französische Public-Sector-Qualifikation.

Diese Seite kartografiert elf europäische Alternativen anhand derselben vier Fragen, die wir überall stellen: Wem gehört das Unternehmen, wo liegen die Daten, was decken die Zertifizierungen tatsächlich ab, und was kostet der Umzug. Der nützliche Rahmen ist nicht „weg von Hetzner", sondern: die Souveränitätshaltung behalten, die Services ergänzen, die Hetzner weglässt, und genau wissen, was dieser Aufpreis kauft.

Die drei Namen, die man vorab kennen sollte: Scaleway (Frankreich, Paris; das Nächste an einem Feature-Superset von Hetzner, mit Managed Kubernetes, Managed Databases, Serverless und GPU-Instanzen), OVHcloud (Frankreich, Roubaix; die größte europäische Cloud, starke Bare-Metal-Range und SecNumCloud-qualifizierte Tarife) und IONOS (Deutschland, Frankfurt und Berlin; der deutsche Peer mit Enterprise-SLAs, BSI C5 und IT-Grundschutz). Alle drei sind EU-eigen und EU-gehostet.

Der Wechsel zwischen europäischen IaaS-Anbietern ist die sanfteste Migrationskategorie auf dieser Seite. Was mitkommt:

• Die Souveränitätshaltung. Neun der elf Alternativen sind EU-eigen und EU-gehostet; Exoscale (Schweiz) sitzt mit Schweizer Residency knapp außerhalb der EU, und Contabo wird aus der EU betrieben, gehört aber seit 2022 US-Private-Equity.
• ISO 27001 durchgehend, dazu BSI C5 bei den deutschen Anbietern (IONOS, STACKIT, T Cloud Public) und SecNumCloud bei den französischen (OVHcloud, Scaleway).
• Standard-Linux-Images, cloud-init, SSH-Key-Workflows, stündliche oder sekundengenaue Abrechnung.
• Terraform-/OpenTofu-Provider bei allen Anbietern auf dieser Seite.
• S3-kompatible Object Storage bei Scaleway, OVHcloud, IONOS, UpCloud und anderen.

Auf der Strecke bleibt, oder wird anders bezahlt:

• Hetzners Preisniveau. Nichts auf dieser Seite erreicht es eins zu eins. Die ehrliche Budget-Spanne ist das 1,5- bis 3-Fache Ihrer Hetzner-Rechnung, teilweise kompensiert, wenn Managed Databases selbst betriebene Infrastruktur und die zugehörigen Engineering-Stunden überflüssig machen.
• Die 20 TB inkludierter Egress pro Server. Die meisten Alternativen berechnen Traffic früher; bepreisen Sie Ihren realen Egress vor dem Umzug.
• Snapshot-Portabilität: Hetzner-Snapshots lassen sich nicht exportieren, der Umzug passiert also auf Anwendungs- und Datenebene, nicht auf Image-Ebene.
• Die hcloud-CLI und das Community-Tooling darum herum (hcloud-cloud-controller-manager, csi-driver). Die Alternativen haben eigene Äquivalente, aber Ihre Skripte werden neu geschrieben.
• Hetzners Dedicated-Server-Auktionsmarkt, ein Preisjagd-Instrument ohne echtes Äquivalent anderswo in Europa (OVHclouds Eco-Range kommt am nächsten).

1. Schreiben Sie auf, warum Sie wechseln, bevor Sie einkaufen gehen. „Wir brauchen Managed Postgres und ein echtes SLA" führt zu Scaleway, OVHcloud, IONOS oder STACKIT. „Wir brauchen SecNumCloud im Vertrag" führt nur zu OVHcloud oder Scaleway. „Wir brauchen es günstiger" führt nirgendwohin; Hetzner ist der Boden. Teams, die diesen Schritt überspringen, migrieren tendenziell zweimal.
2. Bringen Sie Ihren Hetzner-Bestand zuerst in Code. Snapshots verlassen Hetzner nicht, die Migrationseinheit ist also Ihr Provisionierungs-Code plus Ihre Daten. Wurden Server von Hand gebaut, schreiben Sie das Terraform oder Ansible zuerst gegen Hetzner und verifizieren es, dann portieren Sie die Definitionen. Das macht aus einem fehleranfälligen Kopierjob ein Re-Deployment.
3. Bewegen Sie zustandslose Lasten zuerst, Daten zuletzt. Deployen Sie Applikationsserver beim Zielanbieter, richten Sie sie auf die noch bei Hetzner laufenden Datenbanken (beide Enden liegen in EU-Rechenzentren, die Latenz innerhalb Europas liegt üblicherweise bei 5–25 ms) und verifizieren Sie das Verhalten unter echtem Traffic, bevor Sie State anfassen.
4. Replizieren Sie Datenbanken, statt sie zu dumpen und wiederherzustellen. Postgres Logical Replication oder MySQL-GTID-Replikation vom Hetzner-Primary zur neuen Managed Database gibt Ihnen ein kontinuierlich synchronisiertes Ziel und einen Cutover, der sich in Sekunden misst. Das ist auch der Moment, in dem Sie aufhören, die Datenbank selbst zu betreiben, was für viele Teams der ganze Sinn des Umzugs ist.
5. Synchronisieren Sie Object Storage mit rclone. Hetzner Object Storage und Storage Boxes synchronisieren mit rclone sync in beide Richtungen auf jedes S3-kompatible Ziel. Fahren Sie den ersten Durchlauf Tage im Voraus, das finale Delta während des Cutovers.
6. Vergleichen Sie den Egress-Posten explizit. Nehmen Sie die letzten drei Monate Hetzner-Traffic-Graphen, wenden Sie die Egress-Preise des Zielanbieters an und schreiben Sie die Zahl ins Entscheidungsdokument. Das ist die häufigste unangenehme Überraschung in Hetzner-Migrationen.
7. Lassen Sie die Hetzner-Server nach dem Cutover einen Monat weiterlaufen. Stündliche Abrechnung macht das Sicherheitsnetz billig. Stufen Sie auf die kleinsten Instanzgrößen herunter, die Ihre Datenkopien noch halten können, beobachten Sie, wie sich die Rechnung des neuen Anbieters einpendelt, und löschen Sie dann.