Multi-Cloud ist nicht automatisch souverän:

Warum zwei Clouds noch keine Unabhängigkeit bedeuten

In vielen Unternehmen gilt Multi-Cloud inzwischen als Abkürzung für digitale Souveränität. Wer Workloads auf mehrere Anbieter verteilt, so die verbreitete Annahme, reduziert automatisch Abhängigkeiten und gewinnt Kontrolle zurück. Das klingt plausibel. In der Praxis ist es oft ein Missverständnis.

Denn Multi-Cloud und souveräne Cloud beschreiben nicht dasselbe. Das eine ist zunächst ein Architekturmodell. Das andere ist ein Anspruch an Kontrolle, Portabilität, Rechtsklarheit und tatsächliche Handlungsfähigkeit. Wer beides gleichsetzt, verwechselt technische Verteilung mit strategischer Unabhängigkeit.

Genau das wird in der aktuellen Debatte zum Problem. Viele Organisationen investieren in eine zweite oder dritte Cloud und glauben, damit das Lock-in-Risiko bereits adressiert zu haben. Tatsächlich wird die Lage häufig nur komplexer. Die Zahl der Anbieter steigt. Die Zahl der Schnittstellen steigt. Die Zahl der Betriebsmodelle steigt. Die eigentliche Abhängigkeit bleibt jedoch oft bestehen – oder verlagert sich lediglich.

Die zentrale Frage lautet deshalb nicht, ob mehrere Clouds genutzt werden. Die zentrale Frage lautet, ob ein Unternehmen seine digitalen Kernfunktionen wirklich so betreiben kann, dass Wechsel, Kontrolle und Nachvollziehbarkeit nicht nur auf dem Papier existieren.

Warum Multi-Cloud so attraktiv klingt

Der Reiz von Multi-Cloud ist leicht zu verstehen. Kein einzelner Anbieter soll zu mächtig werden. Kein Ausfall soll die gesamte Betriebsfähigkeit gefährden. Kein Preis- oder Strategiewechsel eines Providers soll das eigene Unternehmen in Geiselhaft nehmen. Dazu kommt ein berechtigtes Interesse, bestimmte Workloads gezielt dort zu betreiben, wo Preis, Performance oder Funktionsumfang am besten passen.

Aus dieser Perspektive ist Multi-Cloud zunächst eine nachvollziehbare Antwort auf reale Risiken. Gerade in gewachsenen IT-Landschaften ist es außerdem ohnehin selten realistisch, alles in einem einzigen Stack zu konsolidieren. Unterschiedliche Teams, unterschiedliche Anwendungen, unterschiedliche Anforderungen an Latenz, Compliance oder Verfügbarkeit führen fast automatisch zu einer gewissen Heterogenität.

Das Problem beginnt dort, wo aus dieser Heterogenität eine falsche Schlussfolgerung abgeleitet wird. Zwei oder drei Anbieter im Portfolio bedeuten noch nicht, dass man unabhängig ist. Sie bedeuten zunächst nur, dass man mehrere Beziehungen gleichzeitig managen muss.

Was Multi-Cloud tatsächlich ist

Multi-Cloud bedeutet im Kern, dass ein Unternehmen Infrastruktur- oder Plattformdienste von mehreren Cloud-Anbietern parallel nutzt. Das kann sehr unterschiedlich aussehen. Manche Organisationen betreiben etwa Frontends bei einem Public-Cloud-Anbieter, speichern Backups bei einem anderen und hosten sensible Datenbanken in einer privaten Umgebung. Andere kombinieren europäische Infrastruktur mit spezialisierten Diensten aus internationalen Clouds. Wieder andere wachsen historisch in eine Multi-Cloud hinein, weil einzelne Fachbereiche unterschiedliche Beschaffungsentscheidungen treffen.

All das kann sinnvoll sein. Aber Multi-Cloud bleibt zunächst ein Betriebsmodell. Es sagt noch nichts darüber aus, ob Anwendungen portabel sind. Es sagt nichts darüber aus, ob Daten ohne Reibungsverluste migrierbar sind. Es sagt nichts darüber aus, ob proprietäre APIs tief in Geschäftsprozesse eingebaut wurden. Und es sagt schon gar nichts darüber aus, ob die zugrunde liegenden rechtlichen und organisatorischen Abhängigkeiten reduziert wurden.

Mit anderen Worten: Multi-Cloud kann ein Werkzeug sein. Souveränität ist ein Ergebnis. Das eine führt nicht automatisch zum anderen.

Was eine souveräne Cloud auszeichnet

Souveränität beginnt dort, wo ein Unternehmen echte Kontrolle über seine technischen und organisatorischen Grundlagen behält. Dazu gehört erstens die Fähigkeit, Workloads verlässlich auf anderer Infrastruktur betreiben zu können. Nicht theoretisch, sondern praktisch. Dazu gehört zweitens die Hoheit über Daten, Schlüsselmaterial, Identitäten und Betriebsprozesse. Und dazu gehört drittens, dass diese Kontrolle nicht von intransparenten Vertragskonstruktionen, proprietären Schnittstellen oder außereuropäischen Machtzentren ausgehöhlt wird.

Eine souveräne Cloud ist deshalb kein Marketingetikett und auch kein einzelnes Produkt. Sie ist das Resultat einer Architektur, die auf offenen Standards, auditierbaren Prozessen, nachvollziehbaren Verantwortlichkeiten und realen Exit-Möglichkeiten basiert. Wer im Krisenfall wechseln könnte, aber im Alltag faktisch nicht wechseln kann, ist nicht souverän. Wer seine Daten in Europa speichert, aber seine zentrale Steuerung an ein nicht transparentes Plattformökosystem abgegeben hat, ist es ebenfalls nicht.

Souveränität ist also nicht die bloße Existenz einer Ausweichroute. Souveränität ist die Fähigkeit, die eigene Infrastrukturentscheidung nicht mit Kontrollverlust zu bezahlen.

Warum Multi-Cloud oft nur nach Unabhängigkeit aussieht

In der Praxis erzeugt Multi-Cloud häufig ein trügerisches Gefühl von Sicherheit. Ein Unternehmen verteilt seine Systeme auf mehrere Anbieter und geht davon aus, damit Vendor Lock-in zu entschärfen. Tatsächlich bleibt die Architektur oft tief an proprietäre Dienste gebunden. Datenbanken, Observability, IAM, Messaging, CI/CD, Secrets Management und Netzwerklogik unterscheiden sich von Anbieter zu Anbieter erheblich. Anwendungen werden nicht portabel gebaut, sondern in mehreren proprietären Umgebungen gleichzeitig verankert.

Das Ergebnis ist kein souveränes Modell, sondern ein doppeltes oder dreifaches Lock-in. Statt einer Abhängigkeit gibt es nun mehrere. Statt einer Betriebslogik müssen mehrere beherrscht werden. Statt klarer Exit-Strategien entstehen Integrationsketten, deren Umzug im Ernstfall noch schwieriger wird.

Besonders sichtbar wird das bei Unternehmen, die ihre Anwendungen zwar containerisieren, aber rundherum vollständig auf proprietäre Managed Services setzen. Nach außen wirkt die Umgebung modern und flexibel. Tatsächlich ist der portable Kern klein, während die betriebsrelevanten Komponenten eng mit dem jeweiligen Provider verbunden bleiben. Ein Wechsel scheitert dann nicht am Container, sondern an den Nebensystemen, die ihn erst produktionsfähig machen.

Genau deshalb ist es ein Fehler, Souveränität allein auf Recheninstanzen oder Kubernetes-Cluster zu reduzieren. Entscheidend ist nicht, ob ein Container theoretisch woanders laufen könnte. Entscheidend ist, ob die gesamte Anwendung einschließlich Storage, Netzwerk, Identity, Telemetrie, Security und Delivery-Prozessen mit vertretbarem Aufwand verlagert werden kann.

Komplexität ist keine Freiheit

Ein weiterer Irrtum in der Multi-Cloud-Debatte ist die Gleichsetzung von Vielfalt und Resilienz. Mehr Anbieter bedeuten nicht automatisch mehr Stabilität. Häufig entsteht vor allem mehr Komplexität. Unterschiedliche Abrechnungsmodelle, unterschiedliche Sicherheitsmechanismen, unterschiedliche Logging-Standards, unterschiedliche Betriebsgrenzen und unterschiedliche Ausfallmodi erhöhen den Steuerungsaufwand massiv.

Diese Komplexität ist nicht neutral. Sie kostet Zeit, Personal, Governance und Fehlertoleranz. Wer mehrere Plattformen gleichzeitig betreibt, braucht mehr Wissen, mehr Dokumentation, mehr Kontrollmechanismen und oft auch mehr Integrationsarbeit. Wenn diese Komplexität nicht bewusst reduziert wird, entsteht keine strategische Beweglichkeit, sondern ein teures Gleichgewicht des Improvisierten.

Gerade Mittelständler unterschätzen diese Nebenwirkungen häufig. Multi-Cloud klingt in Präsentationen nach Zukunftsfähigkeit. Im Alltag bedeutet es oft: mehr Sonderfälle, mehr operative Reibung, mehr Angriffsfläche, mehr Audit-Aufwand. Eine Organisation, die ihre Plattformlandschaft nicht sauber standardisiert, baut mit Multi-Cloud nicht Freiheit auf, sondern Betriebsstress.

Deshalb ist die entscheidende Unterscheidung nicht „eine Cloud oder mehrere". Die entscheidende Unterscheidung lautet: Ist die Umgebung standardisiert, nachvollziehbar und portabel genug, um unter mehreren Anbietern überhaupt steuerbar zu bleiben?

Wo Multi-Cloud sinnvoll ist

All das bedeutet nicht, dass Multi-Cloud grundsätzlich falsch wäre. Im Gegenteil: Es gibt gute Gründe für einen Mehranbieteransatz. Unterschiedliche regulatorische Anforderungen, geografische Verteilung, spezifische Leistungsmerkmale oder Redundanzanforderungen können Multi-Cloud sehr sinnvoll machen. Auch bei Mergers, internationalen Strukturen oder spezialisierten Daten- und Rechenanforderungen ist eine gewisse Verteilung oft realistisch und notwendig.

Der Punkt ist nur: Multi-Cloud funktioniert erst dann strategisch, wenn sie nicht aus Beschaffungszufall entsteht, sondern aus Architekturdisziplin. Wer mehrere Anbieter nutzt, braucht umso mehr Standardisierung auf der eigenen Ebene. Offene Schnittstellen, Infrastructure as Code, GitOps, standardisierte Container-Images, saubere Trennung von Anwendung und Plattform, nachvollziehbares Identity- und Secrets-Management und dokumentierte Exit-Pfade sind keine Kür. Sie sind die Voraussetzung dafür, dass Multi-Cloud nicht zur Dauerbaustelle wird.

Multi-Cloud kann also Teil einer souveränen Strategie sein. Sie ist aber niemals deren Beweis.

Warum souveräne Cloud mehr mit Kontrolle als mit Anzahl zu tun hat

Souveräne Cloud-Strategien beginnen nicht mit der Frage, wie viele Provider im Einsatz sind. Sie beginnen mit der Frage, welche Teile der Wertschöpfung unter eigener oder nachvollziehbarer Kontrolle stehen. Wer betreibt die Infrastruktur? Wer kontrolliert die Schlüssel? Welche Standards werden genutzt? Welche Teile der Plattform sind austauschbar? Welche regulatorischen und geopolitischen Risiken hängen an der Entscheidung? Wie belastbar ist ein Exit tatsächlich?

Diese Fragen wirken zunächst mühsamer als die einfache Formel „Wir machen Multi-Cloud". Aber genau darin liegt der Unterschied zwischen Symbolik und Handlungsfähigkeit. Eine souveräne Architektur muss im Zweifel nicht alles gleichzeitig leisten. Sie muss vor allem kontrollierbar, dokumentierbar und mit vertretbarem Aufwand weiterentwickelbar sein.

Aus ayedo-Perspektive bedeutet das: Souveränität entsteht nicht durch möglichst viele Logos in einer Architekturfolie. Sie entsteht durch offene Betriebsmodelle, portable Workloads, cloud-native Standards und europäische Infrastrukturen, die nicht auf verdeckten Abhängigkeiten beruhen. Eine Container-Plattform auf Basis von Kubernetes, sauberem GitOps, offenen APIs und standardisierten Artefakten kann auf verschiedenen Infrastrukturen laufen. Genau darin liegt ihr strategischer Wert. Nicht in der bloßen Tatsache, dass mehrere Clouds beteiligt sind, sondern darin, dass die Anwendung nicht mit einem einzelnen Plattformmodell verschmilzt.

Warum europäische Anbieter in dieser Debatte wichtiger werden

Wenn Unternehmen Multi-Cloud und Souveränität sauber auseinanderhalten, verändert sich auch der Blick auf Anbieter. Die Frage lautet dann nicht mehr nur, wer den größten Servicekatalog hat. Wichtiger wird, wer offene, nachvollziehbare und regulatorisch belastbare Betriebsmodelle unterstützt. Genau an dieser Stelle gewinnen europäische Anbieter an Relevanz.

Wer Souveränität ernst nimmt, kommt an europäischen Infrastrukturen kaum vorbei. Nicht aus Symbolpolitik, sondern weil Datenhaltung, Rechtsrahmen, Supportwege, Auditierbarkeit und technologische Nachvollziehbarkeit Teil der Infrastrukturentscheidung sind. Anbieter wie Hetzner, IONOS, OVHcloud, Scaleway, STACKIT oder europäisch betriebene Private-Cloud-Modelle schaffen hier eine andere Ausgangslage als globale Plattformen, deren Geschäftsmodell gerade auf maximaler Ökosystembindung beruht.

Für ayedo ist dabei besonders klar: Europäische Anbieter sind nicht deshalb interessant, weil sie europäisch klingen, sondern weil sie sich in eine souveräne Zielarchitektur integrieren lassen müssen. Hetzner ist in diesem Zusammenhang für viele Workloads ein besonders relevanter Baustein, weil hier Kostenkontrolle, deutsche Infrastruktur, technische Klarheit und eine vergleichsweise gute Anschlussfähigkeit an offene Betriebsmodelle zusammenkommen. Aber auch hier gilt: Ein europäischer Anbieter allein schafft noch keine Souveränität. Erst die Art, wie man auf ihm baut und betreibt, entscheidet.

Der eigentliche Test: Kann ich wirklich wechseln?

Ob eine Cloud-Strategie souverän ist, zeigt sich nicht in der Beschaffungsakte, sondern im Exit-Test. Kann eine Anwendung mit realistischem Aufwand auf eine andere Infrastruktur verlagert werden? Sind Konfigurationen, Deployments und Betriebsprozesse so dokumentiert, dass der Wechsel nicht zum Neuaufbau wird? Sind Daten in portablen Formaten organisiert? Ist das Identitätsmodell entkoppelt genug? Sind Observability und Security so aufgebaut, dass sie nicht an einem einzelnen Anbieter kleben?

Viele Unternehmen würden diesen Test heute nicht bestehen. Nicht, weil ihnen Technologie fehlt, sondern weil ihre Architekturentscheidungen auf Bequemlichkeit, Tempo oder kurzfristige Verfügbarkeit optimiert wurden. Genau das war im vergangenen Jahrzehnt oft wirtschaftlich plausibel. In einer Zeit wachsender regulatorischer Anforderungen, zunehmender geopolitischer Spannungen und tiefer KI-Integration wird diese Bequemlichkeit jedoch teuer.

Denn je stärker sich Plattformen in Entwicklungsprozesse, Betriebsabläufe und Geschäftsmodelle hineinfressen, desto schmerzhafter wird der spätere Ausstieg. Souveränität ist deshalb keine Frage für irgendwann. Sie ist eine Designentscheidung in der Gegenwart.

Multi-Cloud ist kein Zielbild

Die strategische Schlussfolgerung ist unbequem, aber notwendig: Multi-Cloud darf nicht zum Ersatzbegriff für Souveränität werden. Wer beides verwechselt, investiert möglicherweise in die falsche Form von Vielfalt. Nicht jede zusätzliche Cloud macht unabhängiger. Nicht jede Verteilung reduziert Risiko. Und nicht jede moderne Plattformarchitektur ist automatisch kontrollierbar.

Das eigentliche Zielbild ist nicht Multi-Cloud. Das eigentliche Zielbild ist eine Infrastruktur, die Wechsel nicht verhindert, Governance nicht unterläuft und regulatorische Anforderungen nicht zur nachträglichen Reparaturaufgabe macht. Dafür braucht es weniger Plattformromantik und mehr architektonische Nüchternheit.

Souverän ist nicht, wer auf zwei Clouds verteilt ist.
Souverän ist, wer seine digitalen Grundlagen so aufgebaut hat, dass kein Anbieter zum goldenen Käfig wird.

Und genau deshalb ist die wichtigere Frage nicht: Wie viele Clouds nutzen wir