DORA Exit-Strategie für Kubernetes: 6 Lehren aus Projekten

Gastbeitrag aus der Praxis: Dieser Artikel stammt von Pexon Consulting, dem Betreiber dieser Seite und selbst Kubernetes-Dienstleister. Er beschreibt eigene Projekte und Erfahrungen und ist nicht Teil unserer neutralen Vergleiche.

TL;DR

Eine DORA-Exit-Strategie für Kubernetes ist erst belastbar, wenn der Ausstieg einmal geprobt wurde. Wir bei Pexon sehen in regulierten Projekten, dass die Kubernetes-API portabel ist, der Klebstoff zum Anbieter aber nicht: Identitäten, Load Balancer, Storage und Ingress. Wer diese Bindungen inventarisiert und Daten getrennt plant, kann den Ausstieg belegen.

Was verlangt DORA beim Ausstieg aus einem Kubernetes-Dienst?

DORA verpflichtet Finanzunternehmen, für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, Ausstiegsstrategien und Ausstiegspläne einzurichten. Grundlage sind Artikel 28 Absatz 8 und Artikel 30 der Verordnung (EU) 2022/2554, anwendbar seit dem 17. Januar 2025. Läuft eine solche Funktion auf Managed Kubernetes, betrifft die Pflicht den Cluster.

Dieser Beitrag ist ein gekennzeichneter Praxisbericht von Pexon Consulting, dem Betreiber dieser Seite. Wir beschreiben, wie wir Ausstiegsfähigkeit im Kubernetes-Betrieb aufbauen, mit den Angaben, die wir auf pexon-consulting.de veröffentlicht haben. Den Rahmen mit Artikel 30, Informationsregister und Audit-Trail haben wir im Praxisbericht Kubernetes in Banken beschrieben, das C5-Testat in BSI C5 Kubernetes. Hier geht es nur um den Ausstieg.

Die beste deutschsprachige Orientierung kommt nicht aus dem Gesetz, sondern aus dem Protokoll des Sonderfachgremiums IT “Cloud/Ausstieg” vom 27.11.2023, in dem Bundesbank, BaFin, Banken und Versicherer die Anforderungen an den Cloud-Ausstieg diskutiert haben. Es ist ausdrücklich kein Implementierungsleitfaden, sondern ein Orientierungsrahmen. Wir nutzen es in Projekten als Gliederung:

Punkt	Inhalt	Quelle
Geltung DORA	ab 17. Januar 2025 (Artikel 64)	Bundesbank-Protokoll
Pflicht	Ausstiegs-Strategien und -Pläne für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen (Art. 28 Abs. 8 und Art. 30)	Bundesbank-Protokoll
Fokus	unbeabsichtigte oder unerwartete Beendigung, nicht der geplante Wechsel	Bundesbank-Protokoll
Zeithorizont	mindestens benötigte Ausstiegsdauer und vertragliche Kündigungsfrist des Anbieters	Bundesbank-Protokoll
Prüfung	Strategien und Pläne regelmäßig und anlassbezogen überprüfen, Pläne regelmäßig und anlassbezogen testen	Bundesbank-Protokoll
Einstufung	ob der Dienst eine kritische oder wichtige Funktion stützt, entscheidet das Finanzunternehmen	Pexon DORA-Seite

Lehre 1: Die Strategie schreibt die Bank, die Ausstiegsfähigkeit entsteht im Betrieb

Die Exit-Strategie ist ein Dokument des Finanzunternehmens. Ob sie trägt, entscheidet sich aber an Fragen, die nur der Clusterbetrieb beantworten kann: Welche Exportwege gibt es, in welchen Datenformaten liegen die Daten, wie sieht der Übergabepfad aus, und wann wurde die Wiederherstellung zuletzt geübt? Diese Punkte setzt Artikel 30 Absatz 3 im Betrieb voraus, und danach fragen Bankkunden im DORA-Fragebogen.

Wir halten die Rollen in jedem Projekt schriftlich auseinander. Ob ein Dienst eine kritische oder wichtige Funktion stützt, entscheidet der Kunde, nicht wir. Was wir liefern, ist der Betriebsteil: Exportwege, Datenformate, ein beschriebener Übergabepfad und ein Protokoll der geübten Wiederherstellung. Auf unserer Compliance-Seite steht der Ablauf mit Bestandsaufnahme in Woche 2 bis 3 und Lückenschluss in Woche 4 bis 8.

Ein Satz aus dem Bundesbank-Protokoll hat unsere Arbeit am stärksten geprägt: Eine einmalige Erstellung eines Ausstiegskonzepts zu Vertragsbeginn reiche nicht aus, weil es nach kurzer Zeit die tatsächliche Cloud-Nutzung nicht mehr abbilde. Für einen Kubernetes-Cluster, der jede Woche neue Deployments sieht, gilt das doppelt. Die Exit-Dokumentation muss deshalb aus dem laufenden Betrieb fortgeschrieben werden, nicht aus dem Vertragsordner.

Lehre 2: Kubernetes ist portabel, der Klebstoff zum Anbieter nicht

Die Kubernetes-API selbst ist der portabelste Teil der Plattform. Die CNCF zählt mehr als 90 zertifizierte Kubernetes-Angebote, und die Konformität stellt sicher, dass jedes davon die erforderlichen APIs unterstützt. Was nicht zertifiziert ist, sind die Anbindungen an Identität, Netz und Storage des Anbieters. Dort sitzt die eigentliche Bindung.

Das Bundesbank-Protokoll beschreibt das Muster allgemein: Cloud-Anbieter bieten oft nur Mechanismen zum Export von Daten an, nicht aber den Transfer von Konfigurationen und Metadaten. Im Cluster sehen wir diese Bindungen immer an denselben vier Stellen:

Baustein	Beispiel Azure AKS	Beispiel AWS EKS	Was beim Ausstieg passiert
Pod-Identität	Entra Workload ID: Label `azure.workload.identity/use`, Annotation `azure.workload.identity/client-id` (Microsoft Learn)	EKS Pod Identity mit Agent als DaemonSet, nur auf Amazon EKS (AWS Docs)	Zugriffe auf Secrets und Datenbanken müssen neu verdrahtet werden
Load Balancer	Service-Annotationen wie `service.beta.kubernetes.io/azure-pip-name` (Microsoft Learn)	Annotationen des AWS Load Balancer Controllers	Annotationen werden auf dem Ziel ignoriert, IPs und DNS ändern sich
Storage	StorageClasses mit Azure-Disk- oder Azure-Files-Provisioner	StorageClasses mit EBS- oder EFS-Provisioner	Volumes ziehen nicht mit, Daten brauchen einen eigenen Pfad (Lehre 4)
Ingress	Application Gateway oder eigener Controller	AWS Load Balancer Controller oder eigener Controller	Routing-Regeln müssen in das Ziel übersetzt werden

Die Zahlen hinter den Identitätsdiensten zeigen, wie tief die Bindung reichen kann. EKS Pod Identity erlaubt bis zu 5.000 Zuordnungen pro Cluster und ist laut AWS auf EKS Anywhere und auf selbst betriebenen Clustern auf EC2 nicht verfügbar. Auf AKS gelten maximal 20 Federated Identity Credentials je Managed Identity. Das ist kein Mangel der Dienste, sie sind für ihre Plattform gebaut. Es heißt aber: Jede dieser Zuordnungen ist eine Zeile im Ausstiegsplan.

Lehre 3: Erst inventarisieren, dann über Ziele reden

Bevor wir mit einem Kunden über ein Exit-Ziel sprechen, zählen wir die Bindungen im Cluster. Dafür reichen kubectl und jq, und das Ergebnis ist die Liste, an der sich der Aufwand des Ausstiegs ablesen lässt. Ohne diese Liste schätzt jeder Ausstiegsplan, und Schätzungen halten keiner Prüfung stand.

Unser Einstieg auf einem AKS- oder EKS-Cluster sieht so aus:

# 1. Services mit anbieterspezifischen Load-Balancer-Annotationen
kubectl get svc -A -o json | jq -r '.items[]
  | select((.metadata.annotations // {}) | keys | any(test("azure-|aws-load-balancer")))
  | "\(.metadata.namespace)/\(.metadata.name)"'

# 2. Pods mit Azure Workload ID
kubectl get pods -A -l azure.workload.identity/use=true \
  -o custom-columns=NS:.metadata.namespace,POD:.metadata.name

# 3. StorageClasses und ihre Provisioner
kubectl get storageclass -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner

# 4. Ingress-Klassen und Controller
kubectl get ingressclass

# 5. Alle CRDs, die nicht aus dem Kubernetes-Kern stammen
kubectl get crd -o custom-columns=NAME:.metadata.name | grep -v 'k8s.io'

Die Ausgabe legen wir mit Datum in die Nachweisablage. Aus ihr entsteht die Tabelle, die eine Revision lesen kann: Bindung, betroffene Anwendungen, Ersatz auf dem Ziel, geschätzte Dauer. Das Bundesbank-Protokoll nennt als Gegenmaßnahmen ausdrücklich migrationsfreundliche Technologien und Architekturentscheidungen. Das Inventar zeigt, wo diese Entscheidungen fehlen, und es ist die Grundlage, um sie nachzuholen.

Lehre 4: Daten sind der langsamste Teil des Ausstiegs

Manifeste lassen sich in Minuten auf einen anderen Cluster bringen, Daten nicht. Velero, das verbreitete Open-Source-Werkzeug für Backup und Migration, migriert Volume-Snapshots nicht nativ zwischen Cloud-Anbietern. Zwischen EKS und AKS ist Snapshot-Sharing nicht möglich. Für diesen Weg braucht es File System Backup oder den CSI Snapshot Data Mover.

Wir planen den Datenpfad deshalb getrennt vom Anwendungspfad. Die Eckdaten aus der Velero-Doku zur Cluster-Migration, Stand v1.18.4 als aktuelle Version auf der Release-Seite:

Gemeinsamer Speicher: Beide Cluster zeigen auf denselben Object-Storage-Bucket, Backups werden standardmäßig im Minutentakt synchronisiert.
Versionen: Die Wiederherstellung muss auf derselben oder einer neueren Kubernetes-Version laufen. Welche Versionen Ihr Ziel-Anbieter anbietet, zeigt Kubernetes Version Support.
Volumes: Zwischen Anbietern sichern wir mit File System Backup auf Basis von Kopia. hostPath-Volumes werden dabei nicht unterstützt.
Große Dateien: Datenbankdateien brauchen beim Scan lange. Für Datenbanken ziehen wir deshalb einen Dump oder die Replikation der Datenbank selbst vor.
Aufbewahrung: Velero-Backups haben eine Standard-TTL von 30 Tagen. Für Exit-Tests setzen wir sie bewusst.

Ein Exit-Test mit Velero läuft bei uns in zwei Befehlen, einer auf jedem Cluster:

# Quellcluster: Backup mit Dateisystem-Sicherung aller Pod-Volumes
velero backup create exit-test-2026-11 --default-volumes-to-fs-backup

# Zielcluster (gleicher Bucket, Backup-Location read-only): Wiederherstellung
velero restore create --from-backup exit-test-2026-11
velero restore describe --details exit-test-2026-11-<suffix>

Velero verwendet für alle Backup-Repositories einen gemeinsamen statischen Schlüssel. Wer Zugriff auf den Bucket hat, kann die Daten entschlüsseln. In regulierten Projekten gehört der Bucket deshalb in dieselbe Zugriffs- und Protokollierungslogik wie der Cluster selbst. Welche Storage-Klassen und Preise die Anbieter für das Ziel bieten, vergleicht die Redaktion im Kubernetes-Storage-Vergleich.

Lehre 5: Der Cluster muss aus Git neu entstehen können

Ein Ausstieg ist im Kern ein Neuaufbau an anderer Stelle. Das funktioniert nur, wenn der Sollzustand des Clusters vollständig in Git liegt: Infrastruktur als Code, Anwendungen über GitOps, Konfiguration ohne manuelle Änderungen. Was nur im laufenden Cluster existiert, existiert nach dem Ausstieg nicht mehr.

Zwei unserer veröffentlichten Referenzen zeigen beide Seiten. Bei einem Industrieversicherer mit mehr als 2.000 Mitarbeitern haben wir Azure App Services auf AKS migriert, mit Terraform, neuen Azure-Pipelines und ArgoCD für GitOps. Der Release-Zyklus liegt seitdem bei zwei Wochen. Bei einem Genossenschaftsversicherer aus den Top 10 in Deutschland betreuen wir seit September 2022 eine On-Premise-Plattform mit Rancher und Spinnaker für mehr als 30 Entwicklerteams. In der Case Study steht als Ausgangslage offen “On-Premise ohne Ausstiegspfad”. Heute laufen parallele PoCs mit Azure Landing Zones und ArgoCD, damit Workloads portierbar bleiben, ohne Big-Bang-Migration.

Die Lehre daraus: Ein Ausstiegspfad muss nicht in die Public Cloud führen und nicht aus ihr heraus. Er muss existieren und geübt sein. Wie GitOps auf den verschiedenen Managed-Angeboten aufgesetzt wird, vergleicht die Redaktion unter GitOps auf Managed Kubernetes.

Lehre 6: Ausstiegspläne veralten auch ohne Anbieterwechsel

Ausstiegspläne müssen nicht nur regelmäßig, sondern auch anlassbezogen überprüft werden. Ein Anlass muss kein Vertragsproblem sein. Es reicht, dass eine Komponente wegfällt, von der der Plan ausgeht. Das deutlichste Beispiel 2026 war ingress-nginx, der Ingress-Controller aus dem Kubernetes-Projekt selbst.

Das Projekt hat seine Best-Effort-Wartung im März 2026 beendet, das Repository wurde am 24.03.2026 archiviert. Seitdem gibt es keine Releases, keine Bugfixes und keine Updates für Sicherheitslücken mehr. Bestehende Installationen laufen weiter, das Projekt empfiehlt aber eine Implementierung der Gateway API. Für einen Ausstiegsplan heißt das: Wer “Ingress-Regeln laufen unverändert auf dem Ziel” geschrieben hat, plant mit einer Komponente, die nicht mehr gepflegt wird.

Wir prüfen deshalb bei jedem Upgrade drei Fragen gegen den Ausstiegsplan:

Komponenten: Ist jede Komponente im Plan noch gepflegt und auf dem Ziel verfügbar?
Ziel: Gibt es den vorgesehenen Ziel-Anbieter mit Region, Version und Storage noch so, wie der Plan annimmt?
Ressourcen: Sind die im Plan genannten Personen und Rollen noch da? Das Bundesbank-Protokoll nennt die Verfügbarkeit der Ressourcen ausdrücklich als Testgegenstand.

Beim Ziel weist das Protokoll auf einen Punkt hin, den viele Pläne übersehen: Die möglichen Migrationsziele sind wegen der Marktkonzentration begrenzt, und wenn viele Unternehmen gleichzeitig aussteigen, trifft hohe Nachfrage auf knappe Ressourcen. Ein vorab qualifiziertes Ziel mit Testlauf ist deshalb mehr wert als eine Liste möglicher Anbieter. Welche Managed-Kubernetes-Angebote mit deutscher Region als Ziel in Frage kommen, zeigt die neutrale Übersicht Managed Kubernetes Deutschland, Fragen zu CLOUD Act und Rechtsraum behandelt souveräne Cloud Anbieter.

Was kostet ausstiegsfähiger Kubernetes-Betrieb bei Pexon?

Ausstiegsfähigkeit ist bei uns kein eigenes Produkt, sondern Teil des Nachweis-Betriebs. Der laufende Betrieb mit Audit-Trail kostet 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung, eine geprobte Wiederherstellung als Übung 2.000 bis 4.000 EUR. Wer zuerst den Zugriffspfad und das Ziel klären will, beginnt mit einer Sprechstunde für 450 EUR.

Baustein	Preis (netto)	Inhalt
SLA-Gap-Analyse	kostenlos, 60 Minuten	Ist-Aufnahme, Abgleich mit Prüf- und Kundenanforderungen
Architektur-Sprechstunde	450 EUR Festpreis, 90 Minuten	Welcher der vier Betriebswege (Public AKS, Private AKS mit eigenen Keys, EU-Hoster, Bare Metal) zur Prüferfrage passt
NIS2-/C5-Modul	1.500 bis 3.000 EUR pro Monat	monatlicher Audit-Trail, Änderungshistorie, Zugriffsnachweise, Register-Zulieferung
DR- bzw. Exit-Übung	2.000 bis 4.000 EUR je Übung	Szenario und Abnahmekriterium vorab, Übung im echten Cluster, Protokoll mit Zeiten und Abweichungen
Zugriffspfad-Pilot	ab 14.500 EUR Festpreis, 6 Wochen, ein Cluster	Bestand, Vier-Wege-Tabelle, Dokument, Übergabe an den Prüfer

Quellen sind unsere Seiten zu Kubernetes-Compliance (Stand 19.08.2026), zum DORA-Fragebogen (Stand 20.08.2026) und zu souveränem Kubernetes (Stand 30.08.2026). Die Servicezeit ist Montag bis Freitag, 08:00 bis 18:00 Uhr MEZ, ohne 24/7-Zusage. Compute und Storage zahlen Sie getrennt an Ihren Anbieter.

Offen benannt, was bei uns noch nicht fertig ist: Das Nachweis-Paket entsteht gerade, ein Muster zeigen wir erst nach Abnahme, und für die Liste der Verarbeitungsorte und Subunternehmer gibt es noch kein Muster. Rechtsberatung geben wir nicht, und wir beurteilen nicht, ob Ihr Dienst eine kritische oder wichtige Funktion stützt. Abgenommen ist ein Ausstiegsnachweis bei uns erst, wenn ein Wiederaufbau auf dem Ziel mit Protokoll vorliegt, nicht wenn das Dokument fertig ist.

FAQ

Muss jeder Kubernetes-Cluster einer Bank eine DORA-Exit-Strategie haben?

Nein, die Pflicht nach Artikel 28 Absatz 8 DORA gilt für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen. Ob ein Cluster eine solche Funktion stützt, entscheidet das Finanzunternehmen in seiner Einstufung. In der Praxis betrifft das schnell die Produktionscluster, auf denen Kundenanwendungen oder Zahlungsprozesse laufen.

Was kostet eine geprobte Exit-Übung für einen Kubernetes-Cluster?

Bei Pexon kostet eine Übung mit Szenario, Durchführung im echten Cluster und Protokoll 2.000 bis 4.000 EUR netto je Übung. Dazu kommen die Kosten des Zielclusters beim Anbieter für die Dauer des Tests. Der laufende Nachweis-Betrieb liegt bei 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung.

Exit-Strategie vs. Notfallplan: Was ist der Unterschied?

Ein Notfallplan stellt den Betrieb nach einem Ausfall beim selben Anbieter wieder her. Eine Exit-Strategie beschreibt, wie der Dienst den Anbieter verlässt, auch wenn dieser kündigt oder ausfällt. Technisch überschneiden sich beide bei Backup und Wiederaufbau, der Exit verlangt aber zusätzlich ein Ziel außerhalb des bisherigen Anbieters.

Reicht Velero als Exit-Werkzeug für Kubernetes?

Velero deckt Manifeste und Volume-Daten ab, migriert aber Volume-Snapshots nicht nativ zwischen Cloud-Anbietern. Zwischen EKS und AKS braucht es File System Backup oder den CSI Snapshot Data Mover. Datenbanken sichern wir besser über Dump oder Replikation. Identitäten, Load Balancer und Ingress übersetzt Velero nicht, die gehören in den Ausstiegsplan.

Ist ein Managed-Kubernetes-Dienst schwerer zu verlassen als ein eigener Cluster?

Die Kubernetes-API ist bei über 90 zertifizierten Angeboten dieselbe. Schwer wird der Ausstieg durch anbieterspezifische Bausteine wie Pod-Identitäten, Load-Balancer-Annotationen und StorageClasses. Ein eigener Cluster hat diese Bindungen ebenfalls, nur an andere Komponenten. Entscheidend ist, wie viele davon Ihr Inventar zählt.

Wie oft muss ein Ausstiegsplan getestet werden?

DORA und das Bundesbank-Protokoll nennen keine feste Frequenz. Das Protokoll verlangt, Pläne regelmäßig und anlassbezogen zu testen, mit risikoorientiert festgelegtem Umfang. Wir empfehlen eine Übung pro Jahr und eine zusätzliche nach jeder größeren Änderung, etwa einem Wechsel des Ingress-Controllers oder des Identitätsmodells.

Quellen

Deutsche Bundesbank: Protokoll Sonderfachgremium IT Cloud/Ausstieg (27.11.2023, PDF) (abgerufen 5. November 2026)
Pexon: DORA-Compliance im Fragebogen vom Bankkunden (abgerufen 5. November 2026)
Pexon: Kubernetes-Compliance NIS2, DORA, C5 (abgerufen 5. November 2026)
Pexon: Souveränes Kubernetes, Zugriffspfad statt Flagge (abgerufen 5. November 2026)
Pexon Case Study: On-Premise Kubernetes für einen Genossenschaftsversicherer (abgerufen 5. November 2026)
Pexon Case Study: Migration zu Azure Kubernetes Service (abgerufen 5. November 2026)
CNCF: Certified Kubernetes Software Conformance (abgerufen 5. November 2026)
Velero Docs: Cluster migration (abgerufen 5. November 2026)
Velero Docs: File System Backup (abgerufen 5. November 2026)
Velero Releases (GitHub) (abgerufen 5. November 2026)
Microsoft Learn: Microsoft Entra Workload ID auf AKS (abgerufen 5. November 2026)
Microsoft Learn: Standard Load Balancer in AKS (abgerufen 5. November 2026)
AWS Docs: EKS Pod Identity (abgerufen 5. November 2026)
GitHub: kubernetes/ingress-nginx (Retirement) (abgerufen 5. November 2026)