Welche Lehren sind aus Störungen und Ausfällen zu ziehen? Die Cloud ist nicht unfehlbar

Anbieter zum Thema

Tata Communications

Flexera Software GmbH

STACKIT - Schwarz Digits Cloud GmbH & Co. KG

Yorizon GmbH & Co. KG

Jahrelang operierte die Technologiebranche unter der Annahme, die Cloud sei ein übernatürliches, unangreifbares Wesen. Begriffe wie „Verfügbarkeitszonen“ und „Regionen“ legten nahe, es handele sich hierbei um abstrakte logische Einheiten und nicht um reale Gebäude voller Servern, Kabeln und Kühlsystemen.

Doch Ereignisse wie Naturkatastrophen, großflächige Infrastrukturausfälle oder geopolitische Spannungen haben deutlich gemacht: Selbst die fortschrittlichsten digitalen Systeme sind letztlich an die physische Realität gebunden.

Fallen Rechenzentren aus, geht die Wirkung weit über eine bloße technische Störung hinaus. Es ist eine eindringliche Erinnerung daran, dass die Cloud in echten Gebäuden untergebracht ist, von realen Stromnetzen versorgt wird und an konkreten geografischen Standorten betrieben wird. Fallen diese Systeme aus, gerät auch die digitale Wirtschaft ins Wanken – von Banken über Krankenhäuser bis hin zu Mobilitäts-Apps und Zahlungsplattformen.

Akteure im Bereich Konnektivität müssen daher über einzelne Vorfälle hinausblicken und die grundlegende architektonische Schwachstelle adressieren, die dadurch offengelegt wird: Die „Single-Cloud-Falle“.

Der Mythos von der Isolation

Die gängige Architektur moderner digitaler Infrastrukturen basiert auf sogenannten „Availability Zones“ – separaten Einrichtungen innerhalb einer Region, die unabhängig voneinander ausfallen können. Wenn in einem Gebäude der Strom ausfällt, bleibt der Betrieb im anderen weiterhin aufrechterhalten. Für Softwarefehler oder lokale Störungen funktioniert dieses Modell gut – für großflächige Krisenszenarien wurde es jedoch nie konzipiert. Naturkatastrophen, regionale Stromausfälle oder geopolitische Instabilität können ganze Regionen gleichzeitig betreffen.

Kommt es in einer Region zum Ausfall der Infrastruktur eines einzelnen Anbieters, sind häufig auch dessen Management-Tools betroffen. Organisationen wird in solchen Fällen oft geraten, in eine andere Region zu migrieren. Doch gerade in regulierten Branchen wie dem Finanz- oder Gesundheitswesen ist das selten trivial. Vorgaben zur Datenresidenz schreiben häufig vor, dass Daten innerhalb nationaler Grenzen bleiben müssen. Wird die lokale Infrastruktur unbrauchbar, drohen nicht nur Verzögerungen, sondern unter Umständen auch ein vollständiger Betriebsstillstand – bei gleichzeitig begrenzten rechtlichen Ausweichmöglichkeiten.

Die Strategie des Abwartens hat einen hohen Preis

Die größte Herausforderung in einer Krise ist nicht allein die Technologie, sondern die Unsicherheit. Viele Disaster-Recovery-Konzepte existieren lediglich als statische Dokumente oder Runbooks in digitalen Ablagen. Kommt es zu einem großflächigen Ausfall, müssen Teams improvisieren: Neue Netzwerkpfade aufbauen, Sicherheitskonfigurationen anpassen, Datenverkehr umleiten – und das alles unter hohem Zeitdruck. Parallel dazu eskalieren die geschäftlichen Auswirkungen und verstärken den Druck zusätzlich: So können u.a. der Zahlungsverkehr zum Stillstand kommen, Produktions- und Lieferketten unterbrochen werden oder Mobilitäts- und Transportdienste ausfallen.

Aktuelle Störungen haben gezeigt, dass die Wiederherstellung in solchen Fällen oft mehrere Tage dauert, da die notwendige Konnektivität zwischen verschiedenen Cloud-Umgebungen im Vorfeld nicht konsequent aufgebaut wurde. Kritische Infrastruktur erst im Krisenfall zu errichten, ist zwangsläufig mit erheblichen Risiken verbunden.

Ein neuer Maßstab für Resilienz

Der Weg nach vorn erfordert ein Umdenken bei der Definition von Zuverlässigkeit. Echte Resilienz bemisst sich nicht mehr daran, wie gut ein einzelner Anbieter performt – sondern daran, wie reibungslos Unternehmen über mehrere Umgebungen hinweg agieren können. Netzwerke sind dabei nicht nur Infrastruktur, sondern eine eigene strategische Ebene für Autonomie und Risikomanagement.

Um sich in einer zunehmend unsicheren Welt zu behaupten, sollte sich die Enterprise-Architektur in drei zentralen Punkten weiterentwickeln:

• Den Notausgang einrichten, bevor es brennt: Verbindungen zwischen Cloud-Umgebungen müssen proaktiv aufgebaut werden. Sichere, sofort nutzbare Verbindungen ermöglichen im Ernstfall eine schnelle Umleitung von Datenverkehr. Wer erst im Störfall reagiert, kommt zu spät.

• Das Gehirn von der Schadensreichweite trennen: Monitoring- und Steuerungssysteme sollten nicht in derselben Region wie die zentralen Workloads betrieben werden. Unabhängige Observability gewährleistet Transparenz, auch wenn lokale Infrastruktur ausfällt.

• Von Dokumenten zum Code: Disaster-Recovery-Prozesse müssen automatisiert und ausführbar sein. Resilienz sollte fest in die Systeme integriert sein, sodass der Failover schnell, zuverlässig und ohne manuelle Eingriffe erfolgt.

Hier kommt das Multicloud-Networking ins Spiel. Durch ein einheitliches, verschlüsseltes Overlay, das über verschiedene Anbieter hinweg arbeitet, lassen sich resiliente Architekturen aufbauen – etwa indem eine Primärumgebung in der einen Cloud mit einer Standby-Umgebung in einer anderen gekoppelt wird. Kommt es bei einem Anbieter zu Störungen jeglicher Art, kann der Datenverkehr innerhalb von Sekunden in eine alternative Umgebung umgeleitet werden.

Für Unternehmen mit strengen Anforderungen an Datensouveränität ermöglicht dies hybride Strategien: Sensible Daten bleiben lokal, während Rechenlasten flexibel in andere Regionen verlagert werden. Was früher Wochen dauerte, lässt sich so auf Minuten reduzieren.

Cloud-Strategie als Chefsache: Resilienz statt reiner Betrieb

Bisher waren Cloud-Strategien innerhalb von Unternehmen eher operativer Natur. Globale Disruptionen in der jüngsten Vergangenheit verlangen jedoch danach, dass das Thema zur Chefsache gemacht wird. Wir steuern auf eine Ära zu, in der Infrastruktur grundlegend auf Resilienz und Anpassungsfähigkeit ausgelegt sein muss. Ziel ist es nicht mehr, die Cloud einfach nur zu nutzen – sondern dabei unabhängig von einzelnen Single Points of Failure zu operieren.

(ID:50880216)