Raus aus der Cloud? Wie Exit-Strategien und souveräne Architektur konkret aussehen.

Wenn morgen Ihr Cloud-Provider die Preise verdoppelt — wie schnell wären Sie raus? Und wohin?

Im vorherigen Teil dieser Serie ging es um die Risiken: Vendor-Lock-in, Kostenexplosion, Ausfälle, Datenschutz, Schatten-IT, Monokultur. Die Problemanalyse steht. Dieser Teil geht von der Diagnose in die Handlungsebene: Was lässt sich architektonisch, vertraglich und organisatorisch tun — nicht irgendwann, sondern jetzt?

Nicht als Fünfjahresplan, nicht als Foliensatz für die nächste Vorstandssitzung — sondern als greifbare Entscheidungen, die man heute treffen kann.

Cloud-Exit ist kein Fantasie-Szenario

Lange galt „raus aus der Cloud” als absurd. Zu teuer, zu komplex, zu riskant. Inzwischen gibt es genug Praxisberichte von Unternehmen, die Workloads zurückholen — oft aus Kosten- und Kontrollgründen. Ein deutscher Mittelständler holte seine Engineering-Daten nach drei Jahren aus der Cloud zurück — Ergebnis: 20 Prozent Kostensenkung und kürzere Deploy-Zyklen. Kein Einzelfall. Wer Workloads repatriiert, gewinnt nicht nur Kostentransparenz zurück, sondern auch Architekturhoheit: eigene Release-Zyklen, eigene Sicherheitsstandards, eigene Entscheidungen über Verfügbarkeit.

Das BSI empfiehlt explizit, dass KRITIS-Betreiber eine dokumentierte Exit-Strategie als Teil ihrer Cloud-Architektur vorhalten. Das ist kein Nice-to-have — es ist inzwischen quasi Stand der Technik.

Trotzdem planen die wenigsten ihren Ausstieg, bevor sie einsteigen.

Was eine Exit-Strategie bedeutet

Ein Cloud-Exit-Plan ist kein Panikknopf. Es ist ein strukturiertes Szenario, das man beim Einstieg mitdenkt — und regelmäßig testet.

Technische Grundlagen

Datenformate offen halten. Wer proprietäre Exportformate akzeptiert, hat keinen Exit, sondern eine Illusion. Offene Standards sind keine Kür, sondern Voraussetzung.
Exportpfade dokumentieren. Welche Daten liegen wo? Wie kommen sie raus? In welchem Format? Mit welchem Aufwand? Das muss nicht täglich aktuell sein — aber es muss existieren.
Infrastructure as Code einsetzen. Wer seine Infrastruktur deklarativ beschreibt, kann sie reproduzieren — unabhängig vom Provider. Terraform, Pulumi oder OpenTofu machen Umgebungen portabel.

Testen und Validieren

Test-Migrationen durchführen. Regelmäßige Trockenübungen in andere Umgebungen zeigen, ob der Exit tatsächlich funktioniert oder nur auf dem Papier steht. Eine Exit-Strategie, die nie getestet wird, ist eine PowerPoint-Beruhigungspille.
Failover-Szenarien proben. DNS-Umschaltungen, Disaster-Recovery-Tests, Lastverteilung auf alternative Infrastruktur — wer das nie übt, scheitert im Ernstfall an Kleinigkeiten.

Infrastruktur und Backup

Backups außerhalb derselben Cloud. Snapshots beim gleichen Anbieter sind kein Offsite-Backup. Wenn der Anbieter ausfällt, fallen die Snapshots mit aus. Das gilt besonders für Infrastrukturklassen wie Compute, Storage und Netzwerk — wer alle drei beim selben Provider hat, hat keinen Fallback, sondern einen Single Point of Failure.
Zeit- und Kostenrahmen schätzen. Ein Exit in drei Monaten ist etwas anderes als einer in drei Jahren. Wer die Zahlen nicht kennt, kann nicht verhandeln.

Vertragliche Absicherung

Exit-relevante Bedingungen gehören in den Vertrag — nicht in ein internes Dokument, das niemand liest. Datenexportformate, Übergangsfristen, Löschfristen nach Vertragsende und Unterstützungspflichten bei Migration sollten vertraglich fixiert sein, bevor man unterschreibt.

Für Organisationen mit regulatorischen Anforderungen gibt es inzwischen Roadmaps, die den Exit-Prozess nach Organisationstyp aufschlüsseln.

Multi-Cloud: Diversifizierung mit Augenmaß

Die naheliegende Antwort auf Single-Cloud-Risiken heißt: verteilen. Multi-Cloud senkt Vendor-Lock-in, weil Workloads über mehrere Anbieter laufen und bei Ausfall eines Providers nicht alles steht.

Aber Multi-Cloud ist kein Gratis-Upgrade. Die organisatorische und sicherheitstechnische Komplexität steigt — mehr Verträge, mehr Schnittstellen, mehr Angriffsfläche, mehr Know-how nötig. Besonders unterschätzt: Identity- und Berechtigungsmanagement über mehrere Plattformen hinweg. Wer Nutzerkonten, Rollen und Zugriffsrechte über zwei oder drei Clouds synchron halten muss, baut sich schnell eine Fehlerquelle, die schwerer wiegt als der Vendor-Lock-in, den man vermeiden wollte. Das ist kein Gegenargument — sondern ein Plädoyer für durchdachtes Design statt reflexhaftem „wir machen jetzt Multi-Cloud”.

Was Multi-Cloud leisten kann:

Kritische Dienste verteilen. E-Mail bei Anbieter A, Dateien bei Anbieter B, Identity bei einem dritten — statt alles aus einer Hand.
Verhandlungsmacht erhalten. Wer jederzeit wechseln kann, bekommt bessere Konditionen. Wer nicht wechseln kann, zahlt, was verlangt wird.
Ausfallresilienz erhöhen. Wenn ein Dienst ausfällt, aber die Daten auf einer anderen Plattform liegen, steht nicht alles still.

Was „souveräne Cloud” tatsächlich heißt

Der Begriff wird inflationär verwendet. Jeder Anbieter, der ein Rechenzentrum in Frankfurt hat, nennt sich inzwischen „souverän”. Aber was bedeutet das tatsächlich?

Gaia-X verfolgt das Ziel einer interoperablen, europäischen Daten- und Cloud-Infrastruktur, die Konzentration bei wenigen Hyperscalern und juristische Abhängigkeit reduzieren soll. Erste Anbieter erreichen inzwischen hohe Souveränitäts-Labels wie Gaia-X Label Level 3 in Verbindung mit BSI- und ANSSI-Standards.

Souveräne Cloud heißt im Kern:

Kein Zugriff durch außereuropäische Jurisdiktionen. Weder CLOUD Act noch FISA 702 greifen, weil der Betreiber keiner US-Muttergesellschaft untersteht.
Transparenz über Betrieb und Datenverarbeitung. Audit-Rechte, dokumentierte Prozesse, keine Black Box.
Interoperabilität und Portabilität. Offene APIs, standardisierte Formate, kein proprietäres Ökosystem, das den Wechsel verhindert.

Das klingt nach Utopie? Teilweise. Aber die Richtung stimmt. NIS2 verlangt von betroffenen Unternehmen nachweisbare Sicherheitsmaßnahmen in der Lieferkette — wer seinen Cloud-Anbieter nicht auditieren kann, hat ein Compliance-Problem. DORA geht für den Finanzsektor noch weiter und fordert explizite Exit-Pläne für kritische IKT-Dienstleister. Und der EU Data Act schafft ab September 2025 erstmals ein Recht auf Datenportabilität gegenüber Cloud-Anbietern — inklusive der Pflicht, Wechselgebühren schrittweise abzuschaffen. Die regulatorische Landschaft drückt immer stärker in Richtung Souveränität.

Der pragmatische Mittelweg

Nicht jeder kann und muss morgen alle Workloads migrieren. Aber jeder kann heute klarer gestalten, wo die Abhängigkeiten liegen. Der erste Schritt ist Priorisierung: Welche Systeme sind geschäftskritisch? Wo ist die Abhängigkeit am größten? Und wo wäre ein Wechsel am schmerzhaftesten? Wer diese drei Fragen beantwortet, weiß, wo er anfangen muss.

Wer heute auf Microsoft 365 setzt, kann trotzdem:

E-Mail-Archivierung separat halten — nicht beim gleichen Anbieter, der auch den Posteingang betreibt.
Kritische Daten in einer souveränen Cloud oder On-Prem belassen — nicht alles muss in OneDrive liegen.
Offene Identitäts- und Backup-Lösungen nutzen — statt sich auch bei IAM und Disaster Recovery an denselben Anbieter zu binden.
Verträge mit Exit-Klauseln verhandeln — Datenexport, Übergangsfristen, Formatgarantien.
Cloud Security Posture Management einsetzen — Tools wie Wiz, Prowler oder Checkov machen Konfigurationsrisiken sichtbar, bevor sie zum Problem werden.

Wichtig ist nicht das dogmatische Nein zur Cloud, sondern das durchdachte Design von Abhängigkeiten.

Architektur als politische Entscheidung

Jede Architekturentscheidung ist auch eine politische. Wer alles in eine US-Cloud legt, entscheidet sich — ob gewollt oder nicht — für ein bestimmtes Rechtsregime, eine bestimmte Verhandlungsposition, eine bestimmte Zukunft.

Das heißt nicht, dass US-Cloud per se falsch ist. Aber es heißt, dass diese Entscheidung nicht dem IT-Einkauf allein überlassen werden sollte. Geschäftsführung, Datenschutz, Compliance, Fachbereiche — alle müssen verstehen, was sie da unterschreiben. Und welche Alternativen sie ausschlagen.

Souveränität ist dabei kein Zielzustand, den man einmal erreicht und abhakt. Recht ändert sich, Märkte verschieben sich, Technologien entwickeln sich weiter. Wer heute souverän aufgestellt ist, kann morgen durch eine Übernahme, ein neues Gesetz oder eine geopolitische Verschiebung wieder in der Abhängigkeit landen. Souveränität ist ein fortlaufender Prozess — kein Projekt mit Enddatum.

Die Frage ist nicht „Cloud oder keine Cloud”. Die Frage ist: Wessen Cloud, zu welchen Bedingungen, mit welchen Daten, und mit welchem Exit-Plan?

Digitale Souveränität beginnt nicht mit Technologie, sondern mit Entscheidungen: welche Daten, welche Verträge, welche Exit-Wege. Wer das früh klärt, bleibt Herr der eigenen Architektur.

Quellen

BSI: Empfehlungen zur Exit-Strategie bei Cloud-Dienstleistungen — KRITIS-Leitfaden.
8 Key Steps of a Cloud Exit Strategy — Strukturierter Exit-Plan.
Successful Cloud Exit Strategy (Arvato Systems) — Praxisleitfaden mit Test-Migrationen.
Practical Roadmap for Cloud Exit — Exit-Pläne nach Organisationstyp.
A Practical Guide to a Successful Public Cloud Exit — Repatriation in der Praxis.
Multi-Cloud vs. Single-Cloud: Which Is More Secure? — Sicherheitsvergleich.
Multi-Cloud vs Single Cloud: Which Is Best? — Komplexität und Entscheidungshilfe.
Gaia-X: The Bid for a Sovereign European Cloud — Europäische Cloud-Infrastruktur.
Cloud Temple: First Gaia-X Label Level 3 Certification — Souveränitäts-Zertifizierung.

Weiterlesen

Cloud in Europa: Ja zur Cloud – aber wo bleiben die Alternativen? — Europäische Alternativen zu US-Diensten
Lift and Shift – Übergang oder Sackgasse? — Cloud-Migration strategisch gedacht
Digitale Souveränität: Deutschland zwischen Anspruch und Abhängigkeit — Die deutsche Perspektive
Lidl, Microsoft und Google: Unabhängigkeit oder nur ein Wechsel der Abhängigkeit? — Wenn Konzerne eigene Cloud-Wege gehen
Datenschutz und Kontrolle – der unterschätzte Vorteil lokaler Modelle — Alternative: Daten lokal halten
„Der beste Service für den Kunden”: Wie Softwareanbieter mit Abos Abhängigkeiten schaffen — Die Mechanik hinter SaaS-Abhängigkeit