Der Ausfall von Google Cloud zeigt: Resilienz ist eine Geschäftsentscheidung

Ein Cloud-Ausfall ist längst nicht mehr nur ein schlechter Morgen für ein Technikteam. Wenn ein Fehler bei einem Anbieter den Bankbetrieb, Gerichtsverhandlungen per Video und öffentliche Dienste unterbricht, wird sichtbar, wie viel digitale Infrastruktur eine Gesellschaft stillschweigend an einem Ort konzentriert hat.

Am 20. Oktober kam es bei Google Cloud in der Region europe-west2 zu einer Störung, von der insbesondere die Zone europe-west2-b betroffen war. Reuters berichtet, dass Nutzer Probleme bei Lloyds, HSBC und Rightmove meldeten; andere Berichte nannten außerdem Revolut, ING Germany und Halifax als Dienste mit Beeinträchtigungen. Auf der Google-Statusseite hieß es, Dienste in der betroffenen Zone seien nicht verfügbar gewesen und bei einigen Diensten in der gesamten Region könne es zu einer erhöhten Fehlerquote kommen. Der Ausfall hat sich inzwischen abgeschwächt. Die entscheidende Frage lautet jedoch nicht, ob Google den Betrieb schließlich wiederhergestellt hat. Sie lautet: Warum waren überhaupt so viele Unternehmen demselben Fehler ausgesetzt?

„Die Cloud“ ist keine Strategie, wenn alle denselben Anbieter nutzen

Cloud Computing wird häufig als Ausweg aus anfälliger interner Infrastruktur verkauft. Dieses Versprechen ist durchaus real: Ein großer Anbieter kann eine geografische Verteilung, automatische Wiederherstellung und Betriebskompetenz bieten, die viele Unternehmen wirtschaftlich nicht selbst aufbauen könnten. Googles eigene Leitlinien zur Notfallwiederherstellung basieren ausdrücklich auf dem Grundsatz, Workloads so zu entwerfen, dass sie Ausfälle der Cloud-Infrastruktur verkraften.

Resilienz ist jedoch nicht dasselbe wie Verfügbarkeit. Ein Kunde kann in einer modernen Cloud-Region arbeiten und trotzdem von einem einzigen Anbieter, einer einzigen Region, einer einzigen Zone oder einer kleinen Gruppe gemeinsam genutzter Dienste abhängig sein. Das Ergebnis ist ein System, das auf dem Architekturdiagramm verteilt aussieht, in der Praxis aber konzentriert bleibt.

Das ist die zentrale Lehre aus diesem Vorfall. Der Fehler musste nicht sämtliche Google-Cloud-Dienste weltweit lahmlegen, um weitreichende Störungen auszulösen. Es genügte, ausreichend viele Kunden zu erreichen, deren Anwendungen, Zahlungsabläufe oder öffentlich zugängliche Systeme an dieselbe regionale Infrastruktur gebunden waren. Eine Cloud-Plattform kann riesig sein und für die darauf aufbauenden Unternehmen trotzdem einen engen Ausfallpunkt schaffen.

Deshalb ist die Formulierung „in die Cloud wechseln“ inzwischen zu ungenau, um noch nützlich zu sein. Die relevante Frage lautet nicht, ob ein Unternehmen Cloud-Infrastruktur nutzt. Es geht darum, wie viele unabhängige Wege noch offenstehen, wenn diese Infrastruktur nicht verfügbar ist.

Redundanz ist teuer – und so zu tun, als wäre sie es nicht, ist noch schlimmer

Der unangenehme Teil ist, dass die Lösung nicht einfach aus einem weiteren Häkchen in einem Deployment-Tool besteht. Echte Resilienz kann einen zweiten Cloud-Anbieter, doppelt vorgehaltene Daten, unabhängige Identitätssysteme, alternative Zahlungswege, getestete Umschaltverfahren und Teams erfordern, die auch unter eingeschränkten Bedingungen arbeitsfähig bleiben. All das kostet Geld und erhöht die Komplexität.

Zudem können Systeme dadurch schwieriger zu verwalten sein. Ein Multi-Cloud-Design kann die Abhängigkeit von einem einzelnen Anbieter verringern, aber inkompatible Dienste, aufwendigeres Monitoring und zusätzlichen Sicherheitsaufwand mit sich bringen. Eine Datenbank über mehrere Anbieter zu replizieren, ist nicht automatisch sicherer, wenn der Replikationsprozess, die Zugangsdaten oder der Wiederherstellungsplan weiterhin von einer gemeinsamen Abhängigkeit abhängen.

Die richtige Reaktion ist daher nicht die reflexhafte Forderung, jedes Unternehmen müsse Google Cloud verlassen. Das wäre ebenso vereinfachend wie die Annahme, ein einziger Anbieter sei immer ausreichend. Die vernünftige Frage lautet nach der Verhältnismäßigkeit: Was passiert, wenn dieser Dienst mehrere Stunden lang nicht verfügbar ist, und welche finanziellen oder gesellschaftlichen Kosten hat diese Unterbrechung?

Bei einem internen Tool mit geringem Risiko kann es durchaus rational sein, eine Konzentration zu akzeptieren. Beim Zugang zu Bankkonten oder bei einem öffentlichen Dienst sollte die Antwort anders ausfallen. Nicht nur der Cloud-Anbieter, sondern auch der Kunde muss entscheiden, ob Einsparungen und Bequemlichkeit das Risiko rechtfertigen.

Ein regionaler Ausfall kann zum Problem der öffentlichen Infrastruktur werden

Die Beeinträchtigungen bei Banken machen das Problem besonders sichtbar, weil Kunden Cloud-Architektur nicht als abstrakte technische Entscheidung erleben. Sie erleben eine Karte, die nicht funktioniert, ein Konto, auf das sie nicht zugreifen können, oder einen Dienst, der nicht mehr reagiert. Die BBC berichtete, dass der Ausfall Gerichte, Banken und andere Online-Unternehmen betraf – eine Kombination, die aus einem Vorfall bei einem Anbieter eine Frage der institutionellen Resilienz macht.

Das bedeutet nicht, dass Google allein für jeden nachgelagerten Ausfall verantwortlich ist. Unternehmen entscheiden selbst, wie sie ihre Systeme entwerfen, und aus der verfügbaren Dokumentation geht nicht hervor, dass jede europäische Bank auf demselben Design beruhte. Die belastbarere und zugleich ernstere Schlussfolgerung ist enger gefasst: Eine regionale Störung bei Google Cloud konnte mehrere essenzielle Dienste beeinträchtigen, weil viele Organisationen eine gemeinsame Abhängigkeit akzeptiert hatten.

Zugleich warnt der Vorfall davor, vergangene Verfügbarkeitswerte als Ersatz für Wiederherstellungsplanung zu behandeln. Bei Google Cloud gab es bereits andere Vorfälle, darunter eine Störung von Cloud Storage in us-central1 am 8. Oktober 2026. Damals waren Uploads und Schreibvorgänge 12 Stunden und 30 Minuten lang mit erhöhter Latenz und einer erhöhten Fehlerquote konfrontiert. Der Bericht von IncidentHub zufolge verwies Googles vorläufige Erklärung auf eine Erschöpfung von Ressourcen nach einer Optimierung zur Sortierung des Datenverkehrs sowie auf ein separates Datenbankproblem. Unterschiedliche Regionen und Ursachen beweisen nicht, dass jeder Workload auf dieselbe Weise gefährdet ist. Sie widerlegen aber die bequeme Vorstellung, eine große Plattform könne wie ein unsichtbarer Versorgungsdienst behandelt werden.

Wo Ausfälle wichtig sind, sollten Kunden für Unabhängigkeit bezahlen

Die größte Bequemlichkeit der Cloud-Branche ist zugleich ihre politische und wirtschaftliche Schwäche: Tausende Organisationen können schwierige Infrastrukturentscheidungen an einige wenige Anbieter auslagern. Das ist effizient – bis die ausgelagerte Entscheidung zu einem gemeinsamen Ausfallmodus wird.

Unserer Ansicht nach sollten Regulierungsbehörden und Aufsichtsräte nicht mehr nur fragen, ob ein Anbieter beeindruckende Verfügbarkeitswerte vorweisen kann. Sie sollten wissen wollen, ob ein kritischer Dienst weiterarbeiten kann, wenn seine primäre Region, sein Anbieter oder eine gemeinsam genutzte Steuerungsebene nicht verfügbar ist. Die Antwort muss dokumentiert, getestet und finanziert sein – sie darf nicht in einer Folie zum Disaster-Recovery-Konzept stecken bleiben.

Google Cloud bleibt eine leistungsfähige Plattform, und dieser Ausfall macht den Anbieter nicht in besonderer Weise unverantwortlich. Er zeigt jedoch, dass Resilienz ihren Preis hat und dass sich dieser Preis nicht dadurch wegreden lässt, dass man Infrastruktur „Cloud“ nennt. Bei nicht kritischen Workloads kann Konzentration weiterhin der vernünftige Kompromiss sein. Bei Banken und öffentlichen Diensten ist Unabhängigkeit dagegen keine verschwenderische Doppelung. Sie gehört zum Dienst selbst.