Cloud Exit Strategie 2027: Data Act, DORA und Kubernetes

Constantin Budin, Plattformberater bei Pexon Consulting | 10 Min. Lesezeit | 29.09.2026

TL;DR: Cloud Exit Strategie mit Kubernetes

Eine Cloud Exit Strategie beschreibt, wie Sie Workloads und Daten zu einem anderen Anbieter oder zurück ins eigene Rechenzentrum bringen, ohne den Betrieb zu unterbrechen. Ab dem 12.01.2027 dürfen Cloud-Anbieter dafür keine Wechselentgelte mehr verlangen. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) prüft mit einem Exit-Test, ob der Plan im Cluster trägt.

Das Problem: Kubernetes ist portabel, der Rest des Stacks nicht

Kubernetes wird oft als Antwort auf Lock-in verkauft. Das stimmt für die Manifeste. Ein Deployment läuft auf AKS, auf einem anderen Anbieter und auf einem Cluster im eigenen Rechenzentrum gleich. Der Lock-in sitzt in allem, was um den Cluster herum gebaut wurde: Managed-Datenbanken, Identitäten, Secret-Speicher, Load-Balancer-Annotationen und Monitoring.

In Reviews sehen wir selten eine fehlende Cloud Exit Strategie. Wir sehen eine Cloud Exit Strategie als Dokument, die nie ausprobiert wurde. Sie nennt einen Alternativanbieter und eine geschätzte Dauer. Welche Dienste dort fehlen, wie lange der Datenexport wirklich dauert und wer den Wechsel an einem Wochenende durchführt, steht nicht darin.

2027 wird diese Lücke teurer. Der Data Act nimmt ab Januar das wichtigste Kostenargument gegen einen Wechsel weg, und die BaFin prüft bei Finanzunternehmen die DORA-Umsetzung 2026 und 2027 nach. Wer einen Wechsel nicht belegen kann, hat dann kein Kosten-, sondern ein Nachweisproblem.

Was ändert der Data Act am 12.01.2027?

Ab dem 12.01.2027 dürfen Anbieter von Datenverarbeitungsdiensten für den Wechsel zu einem anderen Anbieter oder ins eigene Rechenzentrum keine Wechselentgelte mehr erheben. Das schließt Egress-Kosten für die Datenübertragung beim Wechsel ein. Bis dahin sind nur ermäßigte Entgelte erlaubt, die die direkten Kosten des Anbieters nicht übersteigen.

So steht es in Artikel 29 der Verordnung (EU) 2023/2854, dem Data Act, der seit dem 12.09.2025 gilt. Zwei Einschränkungen werden in der Diskussion oft übersehen:

• Nur der Wechsel ist frei. Laufender Egress im Parallelbetrieb mehrerer Clouds bleibt abrechenbar. Wer dauerhaft zwei Anbieter nutzt, zahlt weiter für den Datenverkehr dazwischen.
• Das Entgelt fällt, der Aufwand nicht. Die Migration selbst, der Umbau von Managed-Diensten und der Testbetrieb kosten Personentage, egal was der Anbieter berechnet.

Der Data Act regelt außerdem die Vertragsseite: Wechselrechte, Kündigungs- und Übergangsfristen müssen schriftlich im Vertrag stehen. Für eine Exit-Strategie heißt das, die Fristen aus dem Vertrag in den Plan zu übernehmen, statt sie zu schätzen.

Was verlangt DORA von einer Cloud Exit Strategie?

DORA verlangt für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen, eine Ausstiegsstrategie. Finanzunternehmen müssen aus dem Vertrag aussteigen können, ohne den Betrieb zu unterbrechen, ohne regulatorische Pflichten zu verletzen und ohne die Qualität für Kunden zu mindern. Die Pläne müssen dokumentiert, ausreichend getestet und regelmäßig überprüft sein.

Die Pflicht steht in Artikel 28 Absatz 8 der DORA-Verordnung (EU) 2022/2554. Das Wort, das in Prüfungen den Unterschied macht, ist „getestet“. Ein Plan ohne Testprotokoll ist aus Sicht der Aufsicht ein Entwurf.

Für Unternehmen außerhalb der Finanzbranche ist die Exit-Strategie keine gesetzliche Pflicht in dieser Form. Wir empfehlen sie trotzdem für jeden Cluster, der eine geschäftskritische Anwendung trägt. Der Grund ist nicht die Aufsicht, sondern die Verhandlungsposition: Wer den Wechsel belegen kann, verhandelt Preise und Verträge anders.

Welche Nachweise Auditoren in einer AKS-Landing-Zone zusätzlich sehen wollen, beschreibt unser Beitrag zu DORA und AKS aus Sicht der Auditoren.

Wo steckt der Lock-in in einem AKS-Cluster?

Der Lock-in in einem AKS-Cluster steckt fast nie in den Workloads, sondern in fünf Anbindungen: Identität, Secrets, Datenbanken, Netzwerk-Eingang und Monitoring. Jede davon lässt sich portabler bauen, aber jede Abstraktion kostet Betrieb.

Wir raten nicht dazu, jede Zeile auf die portable Variante umzustellen. Eine Managed-Datenbank gegen einen selbst betriebenen Operator zu tauschen, nur damit der Exit leichter wird, verlagert das Risiko vom Anbieter ins eigene Team. Aus unserer Sicht ist die richtige Frage pro Anbindung: Wie lange dauert der Umbau im Ernstfall, und passt diese Dauer zur Übergangsfrist im Vertrag?

Welches Betriebsmodell dazu passt, vergleichen wir im Beitrag zu Managed Kubernetes oder Self-Hosted.

Wie testen Sie eine Cloud Exit Strategie im Cluster?

Ein Exit-Test baut die Anwendung in einem zweiten Cluster bei einem anderen Anbieter oder im eigenen Rechenzentrum aus Git und Backup neu auf und misst die Dauer. Er schaltet keinen Produktivverkehr um. Das Ergebnis ist ein Protokoll mit Datum, Dauer, Lücken und Owner für jede Lücke.

Die Schritte, die wir in einem Exit-Test durchgehen:

1. Ziel-Cluster bereitstellen: leerer Cluster beim Alternativanbieter, per Infrastructure as Code.
2. Plattform aus Git: GitOps-Bootstrap, damit Operatoren, Policies und Namespaces entstehen.
3. Images kopieren: in eine Registry, die der Ziel-Cluster erreicht.
4. Cluster-State und Volumes: Velero-Restore aus dem bestehenden Backup, lesend eingebunden.
5. Datenbank: Restore auf einen Zeitpunkt, Abgleich der Datenmenge.
6. Smoke-Test: Anwendung antwortet, Anmeldung funktioniert, Stichprobe der Daten stimmt.

Der Kern sind die Schritte 3 und 4. Das Backup-Ziel wird im neuen Cluster nur lesend eingebunden, damit der Test die Produktion nicht berührt:

# Images in die Ziel-Registry kopieren
crane copy myregistry.azurecr.io/shop/api:1.4.2 registry.ziel.example/shop/api:1.4.2

# Im Ziel-Cluster: bestehenden Backup-Speicher nur lesend einbinden
velero backup-location create exit-test \
  --provider azure --bucket velero-backups \
  --config resourceGroup=rg-backup,storageAccount=stbackupprod \
  --access-mode ReadOnly

velero restore create exit-test-2026-11 \
  --from-backup cluster-state-nightly-20261115020000 \
  --exclude-namespaces kube-system,velero

Velero 1.18.3 ist seit dem 08.09.2026 aktuell und stellt Backups in Cluster anderer Anbieter wieder her, solange der Speicher erreichbar ist. Welche Backup-Ebene was sichert, und warum die Datenbank einen eigenen Weg braucht, steht in unserem Beitrag zum AKS Backup mit Velero, Longhorn und Barman.

Ins Protokoll gehören vier Angaben, sonst ist es für eine Prüfung wertlos: die gemessene Dauer pro Schritt, jede Anbindung, die im Ziel-Cluster fehlte, die Datenmenge und das Ergebnis des Smoke-Tests. Für jede Lücke steht ein Owner und ein Termin daneben. Beim nächsten Test zeigt der Vergleich, ob die Dauer kürzer geworden ist.

Unsere klare Empfehlung: den ersten Exit-Test vor dem 12.01.2027 fahren. Dann wissen Sie, welche Anbindung die Dauer bestimmt, bevor Sie mit dem Anbieter über den Vertrag für 2027 sprechen.

Häufig gestellte Fragen

Was ist eine Cloud Exit Strategie?

Eine Cloud Exit Strategie ist der dokumentierte und getestete Plan, Anwendungen und Daten von einem Cloud-Anbieter zu einem anderen oder ins eigene Rechenzentrum zu bringen. Sie nennt Alternativen, Übergangsschritte, Dauer und Verantwortliche. Ohne Testprotokoll ist sie ein Entwurf.

Entfallen ab 2027 alle Egress-Kosten?

Nein. Ab dem 12.01.2027 entfallen nach dem Data Act die Entgelte für den Wechsel selbst, einschließlich des Egress dafür. Laufender Datenverkehr im Parallelbetrieb mehrerer Anbieter bleibt abrechenbar.

Brauchen Unternehmen außerhalb der Finanzbranche eine Exit-Strategie?

Eine Pflicht in der Form von DORA Artikel 28 gibt es für sie nicht. Für geschäftskritische Anwendungen empfehlen wir sie trotzdem, weil ein belegter Wechselweg die Verhandlungsposition gegenüber dem Anbieter verändert und im Vorfall Zeit spart.

Wie oft sollte ein Exit-Test laufen?

DORA verlangt regelmäßige Tests, ohne eine feste Frequenz vorzugeben. Wir planen einen Test pro Jahr und zusätzlich nach großen Umbauten, etwa einer neuen Datenbank oder einem Wechsel des Identitätsmodells.

Was kostet ein Exit-Test für einen Kubernetes-Cluster?

Die Infrastruktur beim Alternativanbieter kostet für die Testdauer wenig. Den Aufwand machen Vorbereitung, Datenbank-Restore und das Protokoll. Den Umfang für Ihren Cluster klären wir im unverbindlichen Cluster-Check, unser Managed Kubernetes startet ab 2.500 EUR im Monat.

Nächster Schritt

Verwandte Themen