EKS, AKS oder GKE verlassen: Kubernetes Cloud Exit in Phasen

Abhängigkeiten des Clusters vor dem Ausstieg bewerten lassen? Der Cloud-Exit-Check ab 1.490 € netto stuft jeden Dienst als übertragbar, ersetzbar oder umzubauen ein und liefert Zielarchitektur, Migrationspfad mit Rückfallweg und ein Festpreisangebot. Als Ziel kommt unter anderem Kubernetes auf Hetzner in Frage.

Kubernetes-Manifeste, die nur die Kubernetes-API nutzen, laufen auf jedem konformen Cluster. Der Ausstieg aus EKS, AKS oder GKE ist trotzdem mehr als ein Umzug der Manifeste, weil Load Balancer, Ingress, Volumes, Identitäten, Registry, Logs und Netzwerkmodell an der Cloud hängen. Der Leitfaden behandelt die drei Dienste als Migrationsquellen, trennt Portables von Gebundenem, beschreibt sechs Phasen mit Parallelbetrieb und Rückfallweg und zeigt, was der Datentransfer kostet. Am Ende steht eine Checkliste. Stand Oktober 2026.

Inhaltsverzeichnis

• Was portabel ist und was nicht
• Anbietergebundene Bausteine in EKS, AKS und GKE
• Das Vorgehen in sechs Phasen
• Daten verschieben: Volumes, Datenbanken, Registry
• Cutover und Rückfallweg
• Egress und Datenübertragung beim Ausstieg
• Ziele: wohin der Cluster zieht
• Fristen, Data Act und UP KRITIS
• Checkliste: Abhängigkeiten inventarisieren
• Unser Vorgehen bei WZ-IT
• Stand und Methodik
• Weiterführende Guides

Was portabel ist und was nicht

Portabel ist, was nur die Kubernetes-API nutzt: Deployments, StatefulSets, ConfigMaps, Services vom Typ ClusterIP, Helm-Charts und das GitOps-Repository. Gebunden ist, was der Cluster über die Cloud-Integration bezieht. Der cloud-controller-manager bettet die cloudspezifische Steuerlogik ein. Ein Service vom Typ LoadBalancer erzeugt bei Anbietern mit externen Load Balancern automatisch einen Load Balancer, jede StorageClass nennt über provisioner das Volume-Plugin, und Ingress-Controller werden häufig über Annotationen konfiguriert, deren Bedeutung vom jeweiligen Controller abhängt.

Anbietergebundene Bausteine in EKS, AKS und GKE

Belege, Load Balancer und Ingress: AWS, Azure, GKE-Load-Balancer, GKE Ingress. Volumes: EBS, Azure Disks, Persistent Disk. Identität: EKS, AKS, GKE. Netzwerk und Add-ons: VPC CNI, Azure CNI, EKS-Add-ons, AKS-Add-ons.

Das Vorgehen in sechs Phasen

Die Quelle bleibt bis zum Schluss unverändert und lauffähig. Jede Phase hat ein Ergebnis und eine Bedingung, unter der sie zurückgesetzt wird, ohne die Produktion zu berühren.

Für Phase 2 gelten drei Regeln. Der Zielcluster hat mindestens die Kubernetes-Version der Quelle, denn Velero stellt nicht in einen Cluster mit niedrigerer Version wieder her. Der Ingress geht auf die Gateway API: ingress-nginx wird seit März 2026 nicht mehr gepflegt, und für das NGINX-Add-on von AKS liefert Microsoft kritische Sicherheitspatches bis November 2026. Zertifikate werden vor dem Cutover ausgestellt: cert-manager kennt HTTP01 und DNS01, und HTTP01 braucht einen Namen, der schon auf den neuen Cluster zeigt.

Daten verschieben: Volumes, Datenbanken, Registry

Volumes. Velero migriert Snapshots von Volumes nicht providerübergreifend; für Volume-Daten zwischen Cloud-Plattformen nennt die Dokumentation das File System Backup, das die Dateien über die Knoten liest, und den CSI Snapshot Data Mover. Laut Dokumentation sichert das File System Backup nur Volumes, die ein Pod eingebunden hat, wird als Beta geführt und braucht bei großen Dateien wie Datenbanken lange für die Deduplizierung. Die Entwicklungsversion der Dokumentation nennt zusätzlich, dass die Wiederherstellung auf Azure Files (SMB) und Blob-FUSE-Mounts Besitzrechte ohne Fehlermeldung verlieren kann. Hier laufen Dateivolumes über File System Backup, Datenbanken über Replikation oder Dump. Der Backup-Speicher wird im Zielcluster schreibgeschützt eingebunden (--access-mode=ReadOnly, wie empfohlen).

Datenbanken. Logische Replikation kopiert zunächst einen Snapshot der Tabellen und überträgt danach laufend die Änderungen. Schema und DDL, Sequenzen und Large Objects werden nicht repliziert (Dokumentation von PostgreSQL 18): Das Schema entsteht vorab per pg_dump --schema-only, die Sequenzen werden vor dem Umschalten nachgezogen. PostgreSQL 19 (Release Candidate, Stand 28.10.2026) kann Sequenzen mit ALTER SUBSCRIPTION ... REFRESH SEQUENCES abgleichen. Die verwalteten Dienste dokumentieren logische Replikation: Amazon RDS, Cloud SQL, Azure Database for PostgreSQL. Wo ein Wartungsfenster genügt, reichen Dump und Restore (RDS-und-Aurora-Guide).

Images und Object Storage. crane copy kopiert Images in die Ziel-Registry und behält den Digest, Manifeste mit Digest-Pinning laufen danach unverändert. Für S3 beschreibt der rclone-Guide den Weg.

Cutover und Rückfallweg

Vor dem Umschalten werden die TTL der DNS-Einträge gesenkt, die Zertifikate per DNS01 ausgestellt und die Rückfallbedingung schriftlich festgelegt. Am Umschalttag laufen vier Schritte:

1. Schreibverkehr stoppen oder die Anwendung in den Lesemodus versetzen.
2. Replikationsverzug auf null prüfen, Sequenzen setzen, Subscription trennen, Zieldatenbank schreibbar schalten.
3. DNS auf den Zielcluster umstellen, lesenden Verkehr zuerst oder schrittweise über gewichtete Einträge.
4. Fehlerrate und Latenz gegen die vereinbarte Schwelle beobachten.

Der Rückfallweg steht vor Phase 5 fest. Die Quelle bleibt unverändert und startbereit. Für die Rückrichtung gibt es zwei Optionen: eine vorbereitete Replikation vom Ziel in die Quelle oder die Festlegung, dass nach dem Cutover nur ein Restore aus dem Backup zurückführt. Die Wahl richtet sich danach, wie viel Datenverlust die Anwendung toleriert.

Egress und Datenübertragung beim Ausstieg

Der Data Act gilt seit dem 12. September 2025. Nach der Darstellung der EU-Kommission entfallen ab dem 12. Januar 2027 Wechselentgelte einschließlich der Entgelte für Datenabfluss; bis dahin dürfen Anbieter ermäßigte Wechselentgelte bis zur Höhe ihrer Kosten erheben (Artikel 29 der Verordnung (EU) 2023/2854). Die drei Hyperscaler haben eigene Programme für den Ausstieg (Stand der Seiten: 28.10.2026):

Alle drei Programme gelten für den Wechsel, nicht für dauerhaften Parallelbetrieb, und verlangen eine Voranmeldung vor dem Transfer. Für dauerhaften Austausch zwischen Clouds nennt Google für europäische Kunden Data Transfer Essentials.

Ohne Gutschrift gilt der Listenpreis, bei Azure zum Beispiel 0,087 USD je GB für die nächsten 10 TB nach 100 GB je Monat (Preisseite, Nordamerika und Europa, Premium Global Network, Abruf 28.10.2026): 9.900 GB × 0,087 USD = 861,30 USD für 10 TB. Die Übertragungsdauer begrenzt den Zeitplan oft stärker als der Preis:

Annahmen: 1 TB entspricht 8.000 Gbit, nutzbarer Durchsatz 70 Prozent der Leitungsrate.

Ziele: wohin der Cluster zieht

Wer eine Managed Control Plane verlässt, übernimmt etcd, Upgrades und Control-Plane-Sicherheit selbst; bei der Wahl der Distribution hilft k3s, RKE2 oder Talos. Migrationsseiten je Quelle: AWS, Azure, Google Cloud.

Der Betrieb durch WZ-IT kostet ab 590 € netto je Cluster und Monat inklusive 3 Worker-Nodes, jeder weitere Worker-Node 129,90 €. Beim Hosting in Deutschland kommen die Cluster-Basis ab 129,90 € (HA-Control-Plane mit 3 Nodes, Load Balancer, IPv4, 100 GB Storage, Backup-Speicher) und die Worker-Nodes hinzu: S ab 64,90 € (4 vCPU, 8 GB), M ab 119,90 € (8 vCPU, 16 GB), L ab 179,90 € (Bare Metal, 8 Kerne, 64 GB).

Beträge netto je Monat aus Betrieb, Cluster-Basis und Worker-Nodes, Stand Oktober 2026. Essential ist inklusive, Production sieht 60 Minuten Reaktionszeit auf P1-Incidents vor (Service Levels). Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Das Hosting ist monatlich kündbar, 30 Tage zum Monatsende.

Fristen, Data Act und UP KRITIS

Kündigungsfristen, Commitments und Supportpläne im Vertrag laufen unabhängig vom technischen Zeitplan; der Data Act regelt ab 12. Januar 2027 die Wechselentgelte (siehe oben). Das UP-KRITIS-Papier Empfehlungen zur Vorbereitung einer Exit-Strategie bei Nutzung von Cloud Dienstleistungen (Version 1.0, freigegeben am 31.03.2022, veröffentlicht auf bsi.bund.de) richtet sich an Betreiber Kritischer Infrastrukturen. Seine Fragen lassen sich auf jede Cloud-Nutzung übertragen:

• Rückholbarkeit der Daten garantieren, den Rückholprozess dokumentieren, Datenformate und Zielsystem spezifizieren und das Zielsystem gegebenenfalls vorhalten (Abschnitt 2.1.1).
• Eine Mindestübergangsfrist vertraglich vereinbaren (2.2.2).
• Festlegen, welche Daten in welcher Form benötigt werden, welcher Ausfall akzeptabel ist und welche Umschaltzeiten gelten, nachts oder tagsüber (2.3.1).
• Die Einstiegsadresse von Portalen unabhängig von der Plattform gestalten (2.3.4).

Checkliste: Abhängigkeiten inventarisieren

1. Version und CRDs: Kubernetes-Version, Custom Resources, zugehörige Operatoren. Erledigt, wenn jede CRD im Ziel einen Operator hat.
2. Load Balancer und Ingress: Services vom Typ LoadBalancer, Ingress-Objekte mit Anbieter-Annotationen. Erledigt, wenn jede Annotation eine Entsprechung hat oder entfällt.
3. Storage: StorageClasses, Provisioner, Größen, Zugriffsmodus (ReadWriteMany bei Datei-Diensten). Erledigt, wenn jedes Volume einen Kopierweg hat.
4. Identität und Secrets: Service Accounts mit Cloud-Bindung, Herkunft und Rotation der Secrets. Erledigt, wenn jede Anwendung ihre Zugangsdaten ohne den Quell-Store erhält.
5. Datendienste außerhalb des Clusters: Datenbanken, Queues, Object Storage. Erledigt, wenn die Umschaltung je Dienst getestet ist.
6. Registry und Images: Registry-Hosts, Pull-Secrets, Signaturen. Erledigt, wenn alle Images im Ziel erreichbar sind.
7. Logs, Metriken, Alarme: Agenten, Dashboards, Alarmwege. Erledigt, wenn Alarme dieselben Empfänger erreichen.
8. Netzwerk: Pod- und Service-CIDR, Peerings, VPN, feste Egress-IPs, Freigaben bei Dritten, DNS-Zonen. Erledigt, wenn jede Freigabe umgestellt ist.
9. Managed Add-ons: Liste je Anbieter. Erledigt, wenn jedes Add-on einen Ersatz hat.
10. Verträge: Kündigungsfristen, Commitments, Marketplace-Verträge, Supportpläne, Exit-Programm beantragt. Erledigt, wenn alle Fristen eingeplant sind.
11. Rückfallweg: Bedingung, Rückrichtung, Beobachtungszeit schriftlich. Erledigt, wenn vor dem Cutover freigegeben.

Die Befehle für die Punkte 2, 4, 6 und 9:

# Punkt 2: Services und Ingress mit Cloud-Annotationen
kubectl get svc,ingress -A -o json | jq -r '.items[] | . as $o
  | ($o.metadata.annotations // {} | keys | map(select(test("aws|azure|gcp|cloud\\.google|gke\\.io|alb\\.ingress"))))
  | select(length > 0) | "\($o.kind)/\($o.metadata.namespace)/\($o.metadata.name): \(join(", "))"'

# Punkt 4: Service Accounts mit Cloud-Bindung
kubectl get sa -A -o json | jq -r '.items[]
  | select((.metadata.annotations // {}) | keys | any(test("eks\\.amazonaws\\.com|azure\\.workload\\.identity|iam\\.gke\\.io")))
  | "\(.metadata.namespace)/\(.metadata.name)"'

# Punkt 6: Registry-Hosts der laufenden Images (Images ohne Host kommen von Docker Hub)
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}' \
  | awk -F/ 'NF > 1 && ($1 ~ /[.:]/ || $1 == "localhost") { print $1; next } { print "docker.io (implizit)" }' \
  | sort | uniq -c | sort -rn

# Punkt 9: Managed Add-ons und Pod-Identity-Zuordnungen
aws eks list-addons --cluster-name <name>
aws eks list-pod-identity-associations --cluster-name <name>
az aks show -g <resource-group> -n <name> --query addonProfiles
gcloud container clusters describe <name> --location <location> --format="yaml(addonsConfig)"

Die Annotationen stammen aus der Dokumentation der Anbieter: eks.amazonaws.com/role-arn für IAM-Rollen von Service Accounts, azure.workload.identity/client-id für Entra Workload ID und iam.gke.io/gcp-service-account für GKE-Identitäten mit Impersonation. Der Befehl zu Punkt 4 findet nur annotierte Service Accounts: EKS Pod Identity ordnet Rollen über Zuordnungen in der EKS-API zu (siehe Punkt 9), und GKE kann Service Accounts über IAM-Principal-Bezeichner direkt berechtigen, ohne Annotation. CLI-Referenz: AWS, AWS Pod Identity, Azure, Google Cloud.

Unser Vorgehen bei WZ-IT

Der Cloud-Exit-Check (ab 1.490 € netto) beginnt mit Rechnungen, Ressourcenliste und Architekturunterlagen. Er stuft jeden Dienst als direkt übertragbar, durch Open-Source-Software ersetzbar oder nur mit Umbau ablösbar ein, dimensioniert den Zielbetrieb und liefert Workload-Reihenfolge, Risiken, Rückfallweg und ein Festpreisangebot. Lesezugriffe, Exporte und ein Gespräch mit der IT genügen, die Cloud-Umgebung bleibt unverändert.

Danach baut WZ-IT den Zielcluster, überführt Daten und Anwendungen und sichert Tests, Cutover und Rückfallweg ab. Managed Kubernetes betreibt den Cluster anschließend auf Proxmox, Bare Metal, bei einem europäischen Provider oder als Hosting in Deutschland.

Stand und Methodik

Stand: 28.10.2026. Programme, Preise und Fristen der Anbieter wurden an diesem Tag auf den verlinkten Seiten gelesen und ändern sich ohne Ankündigung; verbindlich ist die Seite zum Zeitpunkt des Antrags. Die Tabelle der gebundenen Bausteine nennt typische Dienste, nicht jede Variante. Die Übertragungsdauer ist eine Rechnung mit offengelegten Annahmen, keine Messung. Der Azure-Listenpreis gilt in USD ohne Rabatte. Das UP-KRITIS-Papier stammt von 2022. Preise von WZ-IT sind Ab-Preise netto. Ein Kostenvergleich mit dem Quellanbieter hängt vom Einzelfall ab.

Weiterführende Guides

• Kubernetes-Backup: die vier Ebenen und Cluster übernehmen: Audit-Checkliste
• Kubernetes auf Hetzner und Kubernetes auf Proxmox als Ziele
• OpenShift-Alternativen für OpenShift als Dienst bei den Hyperscalern
• Cloud-Exit für den Mittelstand, AWS verlassen und Egress-Kosten im Vergleich

Abhängigkeiten, Zielbetrieb und Rückfallweg klärt der Cloud-Exit-Check ab 1.490 € netto. Den Betrieb eines Clusters auf eigener oder gehosteter Infrastruktur beschreibt Managed Kubernetes.