Es besteht ein grundlegender Unterschied zwischen aktiven Konten bei zwei Cloud-Anbietern und dem Betrieb einer robusten Multi-Cloud-Architektur. Die erste ist eine Beschaffungshaltung. Bei der zweiten handelt es sich um eine technische Entscheidung mit echten Betriebskosten, anhaltender Komplexität und Vorteilen, die sich nur dann ergeben, wenn etwas Katastrophales passiert. Die Verwirrung zwischen den beiden hat dazu geführt, dass Unternehmen Geld für Redundanz ausgeben, die dann nicht funktioniert, wenn sie sie brauchen – und dies auf die harte Tour, während eines Produktionsvorfalls, feststellen müssen.
Warum Unternehmen aus den falschen Gründen auf Multi-Cloud umsteigen
Das Gespräch, das zur Multi-Cloud-Einführung führt, beginnt oft in der Einkaufsabteilung oder der Führungsebene. Die Logik ist offenbar solide: Wenn Sie Verträge mit AWS und Azure haben, kann Sie keiner von beiden an missbräuchliche Bedingungen binden. Der Wettbewerb zwischen den Anbietern hält die Preise unter Kontrolle und Sie haben einen Ausweg, wenn sich die Beziehung verschlechtert.
Diese Argumentation ist als Handelsstrategie nicht falsch. Das Problem besteht darin, kommerzielle Hebelwirkung mit technischer Belastbarkeit zu verwechseln. Ein Unternehmen, das 90 % seiner Auslastung auf AWS ausführt und ein Azure-Konto mit einigen peripheren Diensten unterhält, verfügt nicht über eine Multi-Cloud-Architektur, sondern über eine Diversifizierung der Anbieter. Wenn es bei AWS zu einem schwerwiegenden regionalen Ausfall kommt, wird die Azure-Umgebung die Last nicht automatisch absorbieren. Es erfordert stunden- oder tagelange manuelle Arbeit, Datenmigration, Netzwerkneukonfiguration und ein Team, das beide Umgebungen genau versteht. Dabei handelt es sich nicht um Resilienz, sondern um einen Notfallplan, der noch nie getestet wurde.
Was echte Multi-Cloud-Resilienz erfordert
Die Aktiv-Aktiv-Architektur über mehrere Anbieter hinweg – das einzige Modell, das echte Ausfallsicherheit bietet – geht davon aus, dass die Anwendung gleichzeitig in beiden Umgebungen ausgeführt wird und in beiden Umgebungen die volle Last aufnehmen kann. Dies erfordert eine Zustandssynchronisierung über Clouds hinweg, einen globalen Lastausgleich, ein umgebungsübergreifendes Latenzmanagement und Strategien zur Datenkonsistenz, die auch unter Druck funktionieren.
Datenbank ist fast immer der Engpass. Daten im Ruhezustand sind von Natur aus schwieriger zwischen Anbietern zu replizieren als Daten zu verarbeiten. Anbieter bieten verwaltete Replikationsdienste innerhalb ihrer eigenen Umgebung an, aber die cloudübergreifende Replikation für die nativen Dienste jedes Anbieters gibt es nicht als fertiges Produkt – sie muss erstellt werden. Das bedeutet, dass Sie sich für Datenbanken entscheiden müssen, die die Cloud-übergreifende Replikation unterstützen (PostgreSQL mit richtiger Konfiguration, CockroachDB, YugabyteDB) oder akzeptieren, dass die Daten einen einzigen Wahrheitsgeber haben und dass die Ausfallsicherheit nur für die Anwendungsschicht gilt.
Auch die Netzwerkschicht verändert sich erheblich. Um VPCs verschiedener Anbieter mit akzeptabler Latenz und angemessener Sicherheit zu verbinden, müssen VPNs oder private Verbindungen (AWS Direct Connect, Azure ExpressRoute) eingerichtet werden, die in vielen Fällen mehr kosten als die Recheninfrastruktur.
Die Betriebskosten, die niemand im Pitch erwähnt
Spezialisierte Infrastrukturteams bei einem Anbieter haben bereits viel zu tun, um über ständige Releases, Serviceänderungen und Best Practices auf dem Laufenden zu bleiben. Die Verdoppelung dieser Komplexität für zwei Anbieter mit unterschiedlichen Abstraktionen, unterschiedlicher Terminologie, unterschiedlichen Observability-Tools und unterschiedlichen Preismodellen führt zu einer Verdoppelung der kognitiven Belastung des Teams – oder zur Einstellung von Ingenieuren, die sich in beiden Umgebungen auskennen, was seltener und teurer ist.
Infrastructure-as-Code-Tools müssen geschrieben werden, um Unterschiede zwischen Anbietern zu abstrahieren, was häufig zusätzliche Abstraktionsebenen (Terraform mit anbieterunabhängigen Modulen) bedeutet, die die Komplexität erhöhen, ohne sichtbare Funktionalität hinzuzufügen. Eine einheitliche Beobachtbarkeit – von entscheidender Bedeutung für die Diagnose umgebungsübergreifender Vorfälle – erfordert eine neutrale Überwachungsplattform (Datadog, New Relic, Grafana Cloud), die Metriken beider Anbieter aggregiert, was einen höheren Kostenaufwand und eher eine aufrechtzuerhaltende Integration darstellt.
Das praktische Ergebnis ist, dass die tatsächlichen Kosten für den Betrieb einer Aktiv-Aktiv-Multi-Cloud unter Berücksichtigung der Rechen-, Netzwerk-, Speicher- und Teamkosten zwischen 30 und 50 % höher sind als für den Betrieb derselben Arbeitslast bei einem einzelnen Anbieter. Bevor Sie sich auf diese Architektur festlegen, lautet die richtige Frage: Wie hoch sind die Kosten einer vierstündigen Nichtverfügbarkeit für das Unternehmen? Wenn die Antwort geringer ist als die Kosten für die Aufrechterhaltung der Resilienz, spricht die Rechnung für eine andere Strategie.
Wenn Multi-Cloud die richtige Antwort ist
Es gibt Fälle, in denen der Mehraufwand eindeutig gerechtfertigt ist. Finanzdienstleistungen und kritische Infrastrukturen, deren Verfügbarkeits-SLAs über 99,99 % liegen und bei denen ein Ausfall unmittelbare regulatorische oder finanzielle Schäden verursacht. Plattformen mit globaler Abdeckung, bei denen es auf Latenz ankommt und verschiedene Anbieter in bestimmten Regionen besser vertreten sind. Organisationen, bei denen schwerwiegende Anbietervorfälle aufgetreten sind und die gegenüber Kunden und Aufsichtsbehörden nachweisen müssen, dass die Abhängigkeit behoben wurde.
Außerhalb dieser Kontexte ist die effizienteste Resilienzstrategie für die meisten Unternehmen ein multiregionaler, zentraler Anbieter mit gut dokumentierter und getesteter Notfallwiederherstellung. Der Ausfall von AWS us-east-1 mit zur Übernahme bereiten Workloads von us-west-2 liefert für die meisten Ausfallszenarien das gleiche praktische Ergebnis, bei einem Bruchteil der betrieblichen Komplexität.
Die für diese Entscheidung relevante Unterscheidung besteht zwischen Fehlerdomänen. Wenn das Problem darin besteht, dass eine bestimmte Region ausfällt, wird es durch Multi-Region gelöst. Wenn es darum geht, dass der gesamte Anbieter ausfällt oder eingestellt wird, ist Multi-Cloud erforderlich. Die zweite Hypothese ist technisch möglich, aber bei den drei größten Anbietern historisch selten. Die Kalibrierung der Resilienzstrategie auf der Grundlage realer und nicht eingebildeter Risiken unterscheidet eine fundierte Architekturentscheidung von einem teuren Projekt, das ein Problem löst, das nicht existiert.
So bewerten Sie vor dem Bau
Eine korrekte Bewertung beginnt mit einer ehrlichen Abhängigkeitszuordnung. Welche nativen Anbieterdienste nutzt die Anwendung derzeit? Wie viele davon haben ein funktionales Äquivalent beim zweiten Anbieter? Ist der Aufwand für die Portierung auf agnostische oder kompatible Dienste proportional zum angestrebten Nutzen?
Der nächste Schritt besteht darin, einen Providerausfall zu simulieren, bevor Redundanz eingebaut wird. Wie lange würde es dauern, den Betrieb bei einem zweiten Anbieter aus dem aktuellen Zustand wiederherzustellen? Welche Daten würden verloren gehen? Welche manuellen Prozesse wären erforderlich? Diese Simulation – die nicht in der Produktion durchgeführt werden muss, sondern eine Architekturübung auf Papier sein kann – zeigt häufig, dass der schnellste Weg zur Ausfallsicherheit nicht in einer Multi-Cloud liegt, sondern vielmehr in der Verbesserung der Wiederherstellungsprozesse beim aktuellen Anbieter. Erst wenn diese Option ausgeschöpft ist, ist die zusätzliche Komplexität einer Multi-Cloud gerechtfertigt.
Lesen Sie auch
- Cloud-Kosten optimieren: FinOps-Strategien für kleine Unternehmen
- Serverlos mit AWS Lambda: Praktischer Leitfaden für skalierbare Anwendungen
- Resiliente Lieferketten: mehr als nur Just-in-Time
- Autonomes Rechnen: wenn das System sich selbst korrigiert, bevor Sie den Fehler bemerken
- Datenresidenz: Was es in der Praxis bedeutet, sicherzustellen, dass Daten in Brasilien bleiben
- Skalierbarkeit der Anwendung: Strategien und eine Checkliste vor dem Wachstum