Europäische Zielumgebung prüfen: Der Cloud-Exit-Check ordnet Bestand, Zielarchitektur und Migrationspfad ein. Erstgespräch vereinbaren.
Eine Linode-Alternative in Deutschland kann ein Linux-Server bei Hetzner sein. Für eine Umgebung mit verwaltetem Kubernetes, Datenbank und Objektspeicher reicht diese Antwort jedoch nicht: Die Alternative muss zu den verwendeten Diensten und zum gewünschten Betriebsmodell passen. Hetzner, OVHcloud, Scaleway, IONOS und STACKIT sind mögliche Kandidaten, deren dokumentierte Bausteine wir unten einordnen.
Dieser Vergleich beginnt bei Linode/Akamai, DigitalOcean, AWS, Azure und Google Cloud. Er unterscheidet Ausgangsdienste und mögliche Zielpfade. Der engere Ratgeber AWS verlassen behandelt dagegen die Zielwahl aus Sicht eines AWS-Bestands. Stand: Oktober 2026. Die Auswahl- und Abnahmekriterien hier sind unsere Empfehlungen; wir berichten keine eigenen Benchmarks oder Kundentests.
Inhaltsverzeichnis
- Ausgangsanbieter anhand der Dienste unterscheiden
- Europäische Alternativen nach Workload auswählen
- Linode nicht auf einen VM-Tarif reduzieren
- Datenstandort und Datenschutz getrennt prüfen
- Kosten und Betriebsverantwortung vollständig erfassen
- Den Wechsel mit einer Abnahmeliste vorbereiten
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Ausgangsanbieter anhand der Dienste unterscheiden
Linode gehört zu Akamai. Das ist für den Suchbegriff relevant: Hinter einer Linode-Umgebung können mehrere Akamai-Cloud-Produkte stehen. Der Cloud Manager umfasst unter anderem VMs, Kubernetes-Cluster, NodeBalancers und Object Storage. Akamai: abgeschlossene Linode-Übernahme, Cloud-Manager-Übersicht.
Die Tabelle benennt eine Auswahl dokumentierter Produkte und unseren daraus abgeleiteten Prüfauftrag. Sie behauptet keine Vollständigkeit oder Funktionsgleichheit zwischen den Anbietern.
| Ausgangsanbieter | Beispiele dokumentierter Dienste | Vor einer Zielwahl erfassen |
|---|---|---|
| Linode / Akamai | Linodes, LKE, NodeBalancers, Object Storage | Welche Komponenten liefern Anwendung, Netzwerk und Datenhaltung? |
| DigitalOcean | Droplets, Kubernetes, App Platform, Managed Databases, Spaces | Welche Verantwortung liegt beim Plattformdienst statt beim eigenen Team? |
| AWS | EC2, RDS, S3 und Lambda | Welche Anwendungspfade hängen an AWS-APIs und Berechtigungen? |
| Microsoft Azure | Virtual Machines, Azure SQL, Blob Storage und Functions | Welche Identitäten, Datenmodelle und Integrationen müssen ersetzt werden? |
| Google Cloud | Compute Engine, Cloud SQL, Cloud Storage und BigQuery | Welche Daten- und Analysefunktionen braucht das Ziel tatsächlich? |
Unser Vorschlag: Pro Dienst eine Zeile im Inventar, jeweils mit Datenvolumen, Schnittstelle, Abhängigkeiten und zuständigem Team. Eine Anwendung mit PostgreSQL und Dateien wird anders bewertet als eine Anwendung mit proprietären Ereignis- oder Analysediensten. Diese Einordnung soll die Anbieterauswahl eingrenzen; sie ersetzt keine technische Prüfung.
Europäische Alternativen nach Workload auswählen
Für eine erste Auswahl sind zwei Fragen nützlich: Soll das Ziel vor allem Infrastruktur bereitstellen, oder soll der Anbieter auch Plattformaufgaben übernehmen? Und welche Funktionen müssen unverändert aus Sicht der Anwendung verfügbar bleiben?
| Europäischer Kandidat | Dokumentierter Baustein | Abgeleiteter Auswahlpfad |
|---|---|---|
| Hetzner | Cloud-Server, API und Firewalls, private Netze | Für einen serverbasierten Entwurf prüfen; Administration von Betriebssystem, Anwendung und Datenbank ausdrücklich zuordnen |
| OVHcloud | Managed Kubernetes | Für bestehende Container-Workloads Plattformumfang, Netzwerkanbindung und Datenhaltung abgleichen |
| Scaleway | Kubernetes Kapsule | Als verwalteten Kubernetes-Pfad prüfen; benötigte Integrationen und Betriebsgrenzen erfassen |
| IONOS | Managed PostgreSQL | Bei PostgreSQL-Bedarf Version, Erweiterungen, Zugang und Wiederherstellungsanforderungen abgleichen |
| STACKIT | PostgreSQL Flex | Für eine verwaltete PostgreSQL-Zielarchitektur Funktionen und Zuständigkeiten prüfen |
Die Tabelle zeigt bewusst je einen Einstieg, keine Beschränkung des jeweiligen Portfolios. Ein passender Datenbankdienst ist noch keine vollständige Zielumgebung. Netzwerk, Deployment, Identitäten, Sicherung und Observability gehören in denselben Entwurf.
Unsere Auswahlhilfe: Beginnen Sie bei zwei Kandidaten, die die zwingenden Funktionen abdecken. Notieren Sie bei jedem offenen Punkt, welche Produktdokumentation oder Vertragsanlage fehlt. Ein fehlendes Muss-Kriterium lässt sich so von einer bloß ungewohnten Bedienoberfläche unterscheiden. Für die umgekehrte Ausgangsfrage gibt es den Vergleich Hetzner-Alternativen.
Linode nicht auf einen VM-Tarif reduzieren
Die Linode Kubernetes Engine ist ein verwalteter Kubernetes-Dienst. Ein Ziel aus Cloud-VMs ist daher zunächst ein anderes Betriebsmodell, auch wenn darauf später Kubernetes läuft. Akamai: LKE.
Für den Wechsel von Linode zu Hetzner empfehlen wir folgende Zuordnung als Prüfrahmen:
| Bestand | Entscheidung vor der Migration | Vorgeschlagener Abnahmepunkt |
|---|---|---|
| Linode-VM mit lokaler Anwendung | Zielsystem neu aufbauen oder geeigneten Transferweg festlegen | Start, Treiber, Netzwerk, Dienste und Anwendung prüfen |
| LKE mit persistenten Volumes | Zielcluster und Storage-Anbindung gesondert planen | Datenzugriff, Neustartverhalten und Wiederanlauf prüfen |
| NodeBalancer | Zielregeln für TLS, Healthchecks und Weiterleitung festlegen | Erreichbarkeit und Fehlerpfade prüfen |
| Object Storage | Verwendete API-Aktionen, Rechte und Auslieferung inventarisieren | Repräsentative Objekte und benötigte Funktionen prüfen |
| Verwaltete Datenbank | Zielprodukt und Betriebsverantwortung bestimmen | Daten, Rollen, Abfragen und Wiederherstellung prüfen |
Die Tabellenpunkte sind Planungsempfehlungen, keine Behauptung bereits bestandener Tests. Wenn ein verwalteter Dienst durch eine selbst betriebene Komponente ersetzt wird, muss das Kostenbild genau diese zusätzliche Zuständigkeit enthalten.
Auch Objektspeicher braucht eine Funktionsliste: S3-Kompatibilität bedeutet keine vollständige Funktionsgleichheit. Hetzner dokumentiert beispielsweise nicht unterstützte Aktionen für Bucket-Replikation und Tagging. Ermitteln Sie deshalb vor der Zielwahl, ob Code oder Prozesse diese Funktionen verwenden. Hetzner: unterstützte S3-Aktionen.
Datenstandort und Datenschutz getrennt prüfen
Europäischer Anbieter, deutsche Region und DSGVO-konforme Verarbeitung sind unterschiedliche Prüfpunkte. Hetzner führt Cloud-Standorte in Deutschland und Finnland, aber auch in den USA und Singapur. Der Anbietername allein legt den Datenstandort somit nicht fest. Hetzner: Standorte.
Bei Auftragsverarbeitung regelt Art. 28 DSGVO die Anforderungen an Auftragsverarbeiter und Vertrag. Art. 32 verlangt risikogerechte technische und organisatorische Sicherheitsmaßnahmen. Für Übermittlungen personenbezogener Daten in Drittländer gelten die Voraussetzungen des Kapitels V, beginnend mit Art. 44. Ein EU-Standort allein deckt diese Anforderungen nicht ab. DSGVO: Art. 28, 32 und 44.
Als technische Vorbereitung empfehlen wir eine Datenflussliste: Primärregion, Backups, Protokolle, Monitoring-Ziele, administrative Zugriffe und Unterauftragnehmer. Legen Sie je Eintrag fest, welche Vertragsunterlagen und Nachweise geprüft werden müssen. Die rechtliche Bewertung der konkreten Verarbeitung gehört zu den zuständigen Datenschutz- und Rechtsverantwortlichen.
Kosten und Betriebsverantwortung vollständig erfassen
Unser Vergleichsrahmen enthält laufende Infrastruktur, Plattformleistungen, Traffic, Lizenzen und Betrieb. Einmalige Migration, Anwendungsänderungen und Parallelbetrieb werden separat erfasst. Vergleichen Sie denselben Zeitraum, dieselben Datenmengen und denselben benötigten Leistungsumfang.
| Kostenblock | Empfohlene Unterlage |
|---|---|
| Compute und Speicher | Ressourceninventar, Auslastungsdaten, Wachstum und dimensionierter Zielentwurf |
| Traffic und externe Verbindungen | Abrechnungen und Datenflüsse pro Richtung, einschließlich einer möglichen Teilmigration |
| Verwaltete Dienste | Aktueller Leistungsumfang und entsprechender Zielumfang |
| Betrieb und Wiederherstellung | Zuständigkeiten für Updates, Backups, Wiederanlauf und Störungen |
| Wechsel und Parallelbetrieb | Transferweg, Anpassungen, Abnahme und Rückfallplanung |
Setzen Sie offene Werte nicht pauschal auf null. Wenn für ein Ziel die Betriebszuständigkeit fehlt, bleibt die Kalkulation unvollständig. Ein allgemeiner Preisgewinner lässt sich aus dieser Methode nicht ableiten; dieser Beitrag nennt deshalb weder Sparquoten noch ungeprüfte Tarifvergleiche.
Ein Teilwechsel sollte dieselbe Prüfung durchlaufen. Dokumentieren Sie insbesondere, welche Dienste beim bisherigen Anbieter verbleiben und welche Verbindungen zwischen den Umgebungen dauerhaft gebraucht werden. Die Entscheidung ist dann ein abgegrenzter Zielentwurf statt eines unvollständigen Komplettwechsels.
Den Wechsel mit einer Abnahmeliste vorbereiten
Unsere Empfehlung ist eine Abnahmeliste vor der Umsetzung. Sie enthält pro Anwendung die benötigten Funktionen und die Person, die deren Erfüllung beurteilt. Für Daten und Berechtigungen gehört ein nachvollziehbarer Prüfweg dazu.
- Bestand festhalten: Dienste, Ressourcen, Daten, Zugänge, Abhängigkeiten und Verträge erfassen.
- Ziel bestimmen: Produkt, Region, Betriebsverantwortung und Ersatz für benötigte Schnittstellen festlegen.
- Datenpfad entwerfen: Erstübertragung, laufende Änderungen, Konsistenzprüfung und Sicherung beschreiben.
- Abnahme definieren: Fachliche Abläufe, erlaubte und verbotene Zugriffe sowie Wiederherstellung prüfen lassen.
- Umschaltung planen: Schreibzugriffe, DNS, Beobachtung und Rückfallbedingungen dokumentieren.
- Quelle aufräumen: Erst nach Freigabe sowie Prüfung von Aufbewahrung und Löschung kündigen und entfernen.
Diese Reihenfolge ist ein Planungsrahmen. Sie enthält keine Zusage zu Aufwand, Dauer oder unterbrechungsfreiem Wechsel. Ein ungeklärtes Muss-Kriterium bleibt ein offener Entscheidungspunkt, bis es für den konkreten Zielpfad belegt ist.
Unser Vorgehen bei WZ-IT
Der Cloud-Exit-Check ist der Einstieg, wenn Zielanbieter oder Betriebsmodell noch offen sind. Das Angebot umfasst Bestandsanalyse, Kostenbild, Abhängigkeiten, Zielarchitektur und Migrationspfad. Für einen festgelegten Hetzner-Pfad stehen die Seiten zur Linode-Migration und DigitalOcean-Migration bereit. Weitere Ausgangsanbieter führt der Migrations-Hub.
Hilfreiche Unterlagen für die Anfrage sind Diensteliste, Kostenexport, Datenmengen, gewünschte Regionen und bisherige Zuständigkeiten. Welcher Umsetzungs- oder Betriebsumfang beauftragt wird, richtet sich nach dem konkreten Angebot. Aus der Nennung eines Cloud-Produkts in diesem Vergleich folgt keine zusätzliche WZ-IT-Partnerschaft oder Betriebszusage.
Weiterführende Guides
- Cloud-Exit-Strategie: Kosten und Abhängigkeiten erfassen
- AWS verlassen: europäische Zielanbieter einordnen
- DigitalOcean und Hetzner vergleichen
Zielwahl und Migration eingrenzen: Im Cloud-Exit-Check werden Bestand und Migrationspfad bewertet. Erstgespräch vereinbaren.
