Warum Multicloud zu einer Governance-Entscheidung geworden ist

Für die meisten IT-Führungskräfte war Multicloud keine bewusste Entscheidung. Es war einfach eine vollendete Tatsache. Ein Team entschied sich für AWS für eine bestimmte Workload. Azure kam über einen Microsoft-Unternehmensvertrag ins Spiel. Eine SaaS-Akquisition brachte ihre eigenen cloud-Abhängigkeiten mit sich. Eine DR-Anforderung führte zu einer zweiten Region bei einem anderen Anbieter. Niemand hat eine Multicloud-Strategie verkündet; das Unternehmen ist einfach zu einem Multicloud-Unternehmen geworden.

Heute verfolgen 87 % der Unternehmen eine Multicloud-Strategie und balancieren dabei durchschnittlich 2,6 Public-Cloud-Anbieter gleichzeitig aus. Doch die Einführung und eine zentralisierte Governance sind zwei völlig verschiedene Dinge. In der Lücke zwischen dem Stand der Infrastruktur und dem Stand der Governance sammeln sich die meisten Multicloud-Risiken unbemerkt an.

Wie Multicloud zum Standard wurde

Das Wichtigste auf einen Blick: Die meisten Unternehmen haben sich nicht bewusst für Multicloud entschieden. Sie haben sie durch Übernahmen, Entscheidungen auf Teamebene, die Ausbreitung von SaaS und DR-Anforderungen nach und nach aufgebaut. Governance-Rahmenwerke, die für eine Welt mit einem einzigen Anbieter konzipiert waren, hielten damit nicht Schritt.

Die Single-Cloud-Ära zeichnete sich durch eine gewisse operative Einfachheit aus. Ein Anbieter bedeutete einen Vertrag, eine Support-Beziehung, einen Satz einzuhaltender Compliance-Kontrollen und eine Konsole zur Steuerung. Es bedeutete aber auch einen Single Point of Failure, einen einzigen Preishebel und Ausstiegskosten, die mit jedem neu eingeführten Dienst immer unerschwinglicher wurden.

Der Markt hat sich entschieden von diesem Modell entfernt. Gartner prognostiziert, dass 90 % der Unternehmen bis 2027 einen Hybrid-Cloud-Ansatz einführen werden, und weist darauf hin, dass die dringlichste Herausforderung im nächsten Jahr darin besteht, die Datensynchronisation über fragmentierte Hybridumgebungen hinweg zu verwalten. 

Der Druck entsteht nicht aus einer strategischen Vorliebe für Komplexität; er ist struktureller Natur und verstärkt sich zunehmend. Regulatorische Anforderungen schreiben die Datenresidenz in bestimmten Rechtsräumen vor. KI-Workloads konzentrieren sich auf andere Anbieter als herkömmliche Rechenaufgaben. Übernahmen bringen ihre eigenen cloud-Landschaften mit. Teams wählen das beste Tool für die jeweilige Aufgabe, und die Aufgabe bestimmt den Anbieter.

Das Ergebnis ist, dass die meisten cloud-basierten Landschaften von Unternehmen mittlerweile echte Multicloud-Umgebungen sind. Die meisten Governance-Rahmenwerke sind es jedoch nicht.

Die operativen Herausforderungen, die dies dringend erforderlich machen

Das Wichtigste auf einen Blick: Drei zusammenwirkende Faktoren (Resilienzrisiko, regulatorische Komplexität und Anbieterabhängigkeit) machen Multicloud-Governance von einer Best Practice zu einer Anforderung für die Geschäftskontinuität.

Das Ausfallrisiko ist nicht mehr nur theoretisch 

Die Konzentration auf einen einzigen Anbieter schafft Risiken, die in Standardverträgen mit Anbietern einfach nicht abgedeckt sind. Laut dem „Cost of a Data Breach Report“ von IBM sind Datenpannen, die mehrere Umgebungen betreffen, am teuersten zu beheben und kosten durchschnittlich 5,05 Millionen Dollar pro Vorfall. Schlimmer noch: Es dauert durchschnittlich 276 Tage, bis sie erkannt und eingedämmt sind – fast einen Monat länger als bei typischen Vorfällen in einer einzelnen öffentlichen cloud. Das operative und finanzielle Risiko liegt vollständig beim Unternehmen, nicht beim Anbieter.

Die regulatorische Komplexität hat sich vervielfacht 

Anforderungen an die Datenhoheit, die DSGVO, branchenspezifische Compliance-Rahmenwerke und neue Vorschriften zur KI-Governance haben alle geografische und anbieterbezogene Dimensionen. Ein Unternehmen, das Workloads über AWS, Azure und GCP in mehreren Regionen betreibt, hat es nicht mit einer einzigen Compliance-Situation zu tun, sondern muss mehrere gleichzeitig verwalten. Ohne anbieterübergreifende Governance wird Compliance zu einer manuellen, umgebungsspezifischen Aufgabe, die mit der Anzahl der Anbieter und Regionen skaliert, anstatt zentral durchgesetzt zu werden.

Die Abhängigkeit von Anbietern ist ein strategisches Risiko, nicht nur ein technisches. 

Die Bindung an die proprietären Dienste, Preismodelle und Roadmap-Entscheidungen eines einzelnen Anbieters verlagert im Laufe der Zeit die Verhandlungsmacht vom Käufer zum Anbieter. Ausgangsgebühren, die Einstellung von Diensten und Preisänderungen gewinnen an Bedeutung, wenn eine Migration kostspielig ist. Ein Unternehmen, das Workloads verlagern kann, hat eine grundlegend andere Verhandlungsposition als eines, das dazu nicht in der Lage ist – und dieser Unterschied zeigt sich bei Vertragsverlängerungen, SLA-Verhandlungen und den Gesamtkosten der Infrastruktur. Zu erkennen, wo deine Governance-Lücken liegen, ist der erste Schritt, um sie zu schließen.

Lies den Leitfaden zur Standardisierung der Anwendungsbereitstellung über AWS, Azure und GCP hinweg.

Warum Governance die Lücke ist

Kernaussage: Multicloud-Umgebungen scheitern nicht, weil Unternehmen die falschen Anbieter gewählt haben. Sie scheitern, weil die Governance-Rahmenbedingungen nicht dafür ausgelegt waren, mehr als eine Umgebung abzudecken.

Bei der Governance-Lücke in Multicloud-Umgebungen geht es nicht um Sicherheitstools oder Überwachungs-Dashboards. Es geht darum, ob sich die Richtlinien, Kontrollen und die Transparenz, auf die sich IT-Verantwortliche verlassen, tatsächlich über die gesamte Infrastruktur erstrecken oder an den Grenzen der jeweiligen Anbieter-Konsolen enden.

Wenn sie an der Grenze enden, sind die Folgen vorhersehbar. Die Kostentransparenz zerfällt in verschiedene Abrechnungssysteme, die keine gemeinsame Sprache sprechen. Sicherheitsrichtlinien, die in einer Umgebung streng durchgesetzt werden, werden in einer anderen uneinheitlich angewendet. Nachweise zur Compliance müssen vor jedem Audit-Zyklus manuell aus mehreren Quellen zusammengetragen werden. Zugriffskontrollen, die in einer Umgebung sorgfältig definiert wurden, breiten sich in einer anderen unbemerkt aus. Konfigurationsabweichungen häufen sich über cloud-Umgebungen hinweg an, statt nur zwischen Entwicklung und Produktivumgebung.

Laut der „Thales Global Cloud Security Study“ haben 44 % der Unternehmen bereits eine Datenpanne in der cloud erlebt, wobei menschliches Versagen, Fehlkonfigurationen und unzureichende Änderungskontrollen über unterschiedliche Umgebungen hinweg als Hauptursachen genannt wurden. Die Unternehmen, die Multicloud gut verwalten, sind nicht diejenigen mit den ausgefeiltesten cloud-Architekturen. Es sind diejenigen, die Governance von Anfang an als anbieterübergreifende Designanforderung betrachtet haben und nicht als nachträglichen Einfall pro Anbieter.

Was anbieterübergreifende Governance tatsächlich erfordert

Das Wichtigste auf einen Blick: Eine anbieterübergreifende Governance muss auf der Bereitstellungsebene stattfinden – also auf der einheitlichen Ebene über der individuellen cloud-Infrastruktur – und nicht auf der Anbieterebene, wo jede Umgebung per Definition anders ist.

Der erste Reflex angesichts komplexer Governance-Anforderungen ist, zu jedem Anbieter zu gehen und die Governance dort zu konfigurieren. Dieser Ansatz skaliert mit der Anzahl der Anbieter, was bedeutet, dass es mit wachsender Infrastruktur eher schwieriger als einfacher wird. Ein Team, das AWS, Azure und GCP verwaltet, führt die Governance nicht nur einmal durch. Es macht das dreimal, in drei verschiedenen Oberflächen, mit drei verschiedenen Richtliniensprachen, und erzeugt so Audit-Nachweise, die manuell abgeglichen werden müssen.

Anbieterübergreifende Governance funktioniert anders. Sie findet auf der Bereitstellungsebene statt: der einheitlichen Abstraktionsebene über der individuellen cloud-Infrastruktur, auf der Richtlinien, Umgebungsdefinitionen, Zugriffskontrollen und Bereitstellungsprozesse einmalig definiert und überall durchgesetzt werden. Das ist dasselbe Prinzip, das die Plattformstandardisierung bei der Anwendungsbereitstellung funktionieren lässt. Verlege die Governance-Logik weiter nach oben im Stack auf eine Ebene, die sich nicht von Anbieter zu Anbieter ändert.

Für IT-Führungskräfte ist diese Umdeutung wichtig, weil sie verändert, wohin die Investitionen fließen. Governance-Tools, die in der Konsole jedes Anbieters angesiedelt sind, werden immer anbieterspezifisch sein. Governance, die in der Bereitstellungsebene angesiedelt ist – in versionskontrollierten Konfigurationen, automatisierten Pipelines und portablen Umgebungsdefinitionen –, wandert mit der Workload mit, unabhängig davon, wo sie ausgeführt wird.

Genau das bedeutet es, wenn Multicloud eher eine Governance-Entscheidung als eine Infrastrukturentscheidung ist. Die Infrastrukturfrage (welche Anbieter, welche Regionen, welche Dienste) bleibt wichtig. Aber die Governance-Frage (wie du Kontrolle, Transparenz und Portabilität über alle hinweg aufrechterhältst) entscheidet darüber, ob Multicloud ihr Versprechen einlöst oder nur Komplexität und Kosten verursacht.

Sieh dir die Referenzarchitektur für portable Umgebungen mit Richtlinien-Leitplanken an.

Häufig gestellte Fragen (FAQ)

Ist Multicloud tatsächlich sicherer als Single-Cloud? 

Das kann sie sein, aber nur, wenn eine Governance vorhanden ist, die einheitliche Kontrollen über alle Anbieter hinweg durchsetzt. Ohne diese Governance vergrößert Multicloud die Angriffsfläche, anstatt sie zu verringern. Der Vorteil der Ausfallsicherheit einer verteilten Infrastruktur erfordert die Disziplin der Governance, um sie einheitlich zu verwalten. Unternehmen, die in Multicloud-Umgebungen Datenlecks in der cloud erlebt haben, nennen in der Regel Fehlkonfigurationen und eine inkonsistente Durchsetzung von Richtlinien als Hauptursachen – nicht die Multicloud-Architektur selbst.

Wie unterscheidet sich Multicloud-Governance von Cloud-Sicherheit? 

Bei der cloud-basierten Sicherheit geht es darum, Workloads innerhalb einer bestimmten Umgebung zu schützen. Bei der Multicloud-Governance geht es darum, einheitliche Richtlinien, Transparenz und Kontrolle über alle Umgebungen hinweg gleichzeitig aufrechtzuerhalten: wie sich Workloads zwischen Anbietern bewegen, wie Compliance-Nachweise erstellt werden, wie der Zugriff abgegrenzt und geprüft wird und wie die Kosten nachverfolgt werden. Sicherheit ist eine Dimension der Governance; Portabilität, Compliance-Status und finanzielle Transparenz sind die anderen.

Was kostet eine Anbieterabhängigkeit eigentlich? 

Die direkten Kosten (Ausgangsgebühren, Migrationskosten, Abhängigkeiten von proprietären Diensten) sind messbar, werden aber zum Zeitpunkt der Beschaffung oft unterschätzt und lassen sich später nur schwer rückgängig machen. Die strategischen Kosten sind schwerer zu quantifizieren: verminderte Verhandlungsmacht, Anfälligkeit gegenüber einseitigen Preisänderungen und Abhängigkeit der Roadmap von den Entscheidungen eines einzelnen Anbieters. Laut dem „Cost of a Data Breach Report“ von IBM belaufen sich die Kosten für Vorfälle in mehreren Umgebungen auf durchschnittlich 5,05 Millionen US-Dollar, wobei die Identifizierung und Eindämmung durchschnittlich 276 Tage dauert – Kosten und Zeitaufwand, die das Unternehmen tragen muss, nicht der Anbieter.

Wo fängt Multicloud-Governance an? 

Mit Transparenz: zu wissen, was wo läuft, in welcher Konfiguration und mit welchen Zugriffskontrollen. Die meisten Governance-Lücken in Multi-Cloud-Umgebungen sind nicht das Ergebnis schlechter Richtlinienentscheidungen. Sie sind das Ergebnis von Richtlinien, die nie konsequent angewendet wurden, weil es keine einheitliche Ebene gab, von der aus sie angewendet werden konnten. Der Ausgangspunkt ist die Einrichtung dieser Ebene, um darauf aufbauend die Durchsetzung der Richtlinien zu gewährleisten.

Wie passt Datensouveränität in die Multicloud-Governance? 

Anforderungen an die Datenhoheit, die festlegen, wo Daten gespeichert werden müssen und wer darauf zugreifen darf, sind einer der stärksten Treiber für die Einführung von Multicloud und gleichzeitig eines der schwierigsten Themen, die ohne anbieterübergreifende Governance zu bewältigen sind. Verschiedene Anbieter, Regionen und Dienste haben jeweils unterschiedliche Auswirkungen auf die Datenhoheit. Eine anbieterübergreifende Governance ermöglicht es, Speicherortanforderungen einheitlich durchzusetzen, anstatt sie als Ausnahmen pro Umgebung zu verwalten.