Entscheidung vorbereiten: Cloud-Exit-Check zur Zielwahl. Erstgespräch vereinbaren.
Von AWS zu einer europäischen Cloud wechseln beginnt mit der Frage, welche Dienste am Ziel gebraucht werden und wer sie betreibt. Ein Serververgleich beantwortet diese Frage nur teilweise. Dieser Ratgeber vergleicht die Zielwahl, nicht einzelne Tarife. Stand: Oktober 2026. Die Prüfpfade sind unsere Empfehlungen; es handelt sich weder um Benchmarks noch um einen Kundentest.
Inhaltsverzeichnis
- Zuerst Dienste und Zuständigkeiten erfassen
- Fünf Zielanbieter nach Betriebsmodell vergleichen
- AWS-Abhängigkeiten einzeln auflösen
- Region und Kontrollanforderungen festlegen
- Kosten und Abnahme vor der Auswahl prüfen
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Zuerst Dienste und Zuständigkeiten erfassen
Erstellen Sie pro Anwendung ein Inventar: Compute, Datenbank, Objektspeicher, Identitäten, Queues, Zeitsteuerung, DNS und Deployment. Ordnen Sie jedem Eintrag einen Verantwortlichen zu. Notieren Sie zusätzlich, welche AWS-Schnittstelle im Code oder in der Infrastrukturdefinition vorkommt und welche Geschäftsprozesse davon abhängen.
Unsere Empfehlung: Trennen Sie Muss-Funktionen von Komfortfunktionen. Ein benötigter Datenbanktyp kann ein Ausschlusskriterium sein; ein anderes Administrationsportal meist nicht. Für jeden Kandidaten sollte dieselbe Liste gelten. Andernfalls vergleichen Sie einen selbst administrierten Server mit einem Plattformdienst, ohne den zusätzlichen Betrieb einzurechnen.
Die Entscheidungsvorlage sollte außerdem festhalten, was bei AWS bleiben darf. Ein Teilwechsel ist ein eigener Entwurf mit dokumentierten Datenflüssen, Zugängen und Störungszuständigkeiten. Wer AWS verlassen möchte, muss nicht jede Anwendung im selben Projekt verändern.
Fünf Zielanbieter nach Betriebsmodell vergleichen
Die Tabelle nennt belegte Bausteine und daraus abgeleitete Prüfaufträge. Sie ist keine Rangliste. Die Produktauswahl ist bewusst begrenzt und behauptet weder Vollständigkeit noch Funktionsgleichheit mit AWS.
| Kandidat | Belegter Ausgangspunkt | Unser Prüfauftrag vor der Zielwahl |
|---|---|---|
| Hetzner | Cloud-Server | Serverbetrieb, Datenbankbetrieb und benötigte Zusatzdienste getrennt kalkulieren |
| STACKIT | Verwaltetes PostgreSQL Flex | Erweiterungen, Zugriffe und Verantwortungsgrenzen für die Datenbank prüfen |
| IONOS | Managed PostgreSQL | Datenbankbedarf und Netzwerkanbindung mit dem Zielprodukt abgleichen |
| OVHcloud | Managed Kubernetes | Containerplattform, persistente Daten und Betriebsumfang gemeinsam bewerten |
| Scaleway | Managed PostgreSQL und MySQL | Datenbankprodukt, Zugangspfad und Anwendungskompatibilität prüfen |
Für einen Serverpfad ist Hetzner ein möglicher Kandidat. Wenn der bisherige Entwurf stark auf verwaltete Datenbanken oder eine verwaltete Containerplattform setzt, sollten Sie entsprechende Produkte der anderen Kandidaten mitprüfen. Daraus folgt kein allgemeiner Sieger: Die richtige Zuordnung entsteht erst aus Ihrem Inventar.
Ein Anbieter kann mehrere Rollen abdecken. Die Tabelle beschränkt ihn nicht auf den genannten Dienst. Fragen Sie für jede benötigte Funktion nach der konkreten Produktdokumentation, der gewählten Region und der aktuellen Leistungsbeschreibung. Ein Produktname allein ist kein Abnahmekriterium.
AWS-Abhängigkeiten einzeln auflösen
Empfohlenes Raster für die Bestandsaufnahme:
| AWS-Bezug im Bestand | Zu dokumentierende Entscheidung | Abnahmepunkt |
|---|---|---|
| EC2 und Server-Images | Neuer Serveraufbau oder geeigneter Image-Transfer | Boot, Treiber, Netz, Anwendung und Wiederherstellung |
| RDS oder Aurora PostgreSQL | Ziel-PostgreSQL und benötigte Erweiterungen | Schema, Rollen, Daten und Anwendungsabfragen |
| S3 | Benötigte API-Aktionen, Metadaten und Auslieferung | Upload, Download, Rechte und verwendete Sonderfunktionen |
| Lambda oder Ereignisverarbeitung | Ersatzlaufzeit und Trigger je Funktion | Wiederholungen, Fehlerpfade und Berechtigungen |
| IAM und weitere dienstübergreifende Bindungen | Neue Identitäten und Rechte je Zugriffspfad | Erlaubte sowie ausdrücklich verbotene Zugriffe |
S3-Kompatibilität ist kein Nachweis für vollständige Funktionsgleichheit. Hetzner führt beispielsweise nicht unterstützte Aktionen wie Bucket-Replikation und Tagging auf. Ein Entwurf, der davon abhängt, braucht einen gesonderten Ersatz. Unterstützte S3-Aktionen.
Unsere Empfehlung für proprietäre Schnittstellen: Dokumentieren Sie zuerst Eingabe, Ausgabe, Berechtigungen und Fehlerbehandlung. Entscheiden Sie danach über den Ersatz. Ein ähnlicher Produktname ersetzt diesen Vertrag zwischen Anwendung und Infrastruktur nicht.
Region und Kontrollanforderungen festlegen
Ein europäischer Anbieter ist keine automatische Festlegung auf einen deutschen oder europäischen Standort. Hetzner dokumentiert Cloud-Standorte in Deutschland und Finnland sowie in den USA und Singapur. Standortübersicht.
Wir empfehlen daher eine eigene Spalte für die gewählte Region, Sicherungsziele, Administratorzugriffe und externe Verbindungen. Prüfen Sie Verträge und Datenschutzanforderungen für den konkreten Aufbau mit den zuständigen Stellen. Dieser Vergleich vergibt kein pauschales Compliance- oder Souveränitätssiegel.
Kosten und Abnahme vor der Auswahl prüfen
Vergleichen Sie dieselben Positionen über denselben Betrachtungszeitraum: Ressourcen, Speicherwachstum, Traffic, Lizenzen, Betrieb und Wiederherstellung. Erfassen Sie Migration, Parallelbetrieb und gegebenenfalls Anwendungsumbau zusätzlich. Lassen Sie unklare Werte als offen stehen, statt sie mit einer pauschalen Sparquote zu ersetzen.
Vor der Beauftragung sollte eine technische Abnahme definiert sein: repräsentativer Datenbestand, Anwendungspfade, Rechteprüfung, Backup-Wiederherstellung und dokumentierter Rückweg. Das ist eine Empfehlung für die Planung, keine Behauptung über durchgeführte Tests. Kündigung und Löschung der Quelle empfehlen wir erst nach Abnahme und geklärten Aufbewahrungspflichten.
Wenn die kritischen Funktionen am Ziel nicht nachgewiesen sind, ist die Auswahl noch offen. Dann sind weiterer Klärungsbedarf oder ein begrenzter Teilwechsel sachlich bessere Ergebnisse als eine bereits festgelegte Anbieterempfehlung.
Unser Vorgehen bei WZ-IT
Der Cloud-Exit-Check ist der Einstieg für die offene Entscheidung: Bestandsaufnahme, Kostenanalyse, Lock-in-Bewertung, Zielarchitektur und Migrationspfad. Die AWS-zu-Hetzner-Migration passt, wenn dieses Ziel feststeht. Weitere Migrationspfade finden Sie im Migrations-Hub.
Für die Anfrage genügen als Ausgangsmaterial die genutzten Dienste, Kostenexporte, Datenmengen, gewünschte Regionen und bestehende Betriebszuständigkeiten. Der konkrete Leistungsumfang wird vor der Beauftragung abgegrenzt. Die hier verglichenen Herstellerprodukte begründen keine zusätzlichen WZ-IT-Partner- oder Supportzusagen.
Weiterführende Guides
- AWS und Hetzner: Preise und Betrieb vergleichen
- Hetzner-Alternativen nach Anforderungen auswählen
- Cloud Repatriation von Anbieterwechsel unterscheiden
Zielwahl prüfen: Im Cloud-Exit-Check werden Bestand und Migrationspfad eingeordnet. Erstgespräch vereinbaren.
Für Linode, DigitalOcean und weitere Ausgangsplattformen ergänzt der Vergleich US-Cloud und europäischer Alternativen die dienstbezogene Zielwahl.
