Eine Region fällt, die halbe Lieferkette steht
Ein Cloud-Konzentrationsrisiko ist ein Lieferkettenrisiko. Was der us-east-1-Ausfall lehrt und warum ein getestetes Multi-Region-Setup meist besser ist.
Am 20. Oktober 2025 stand ein Teil des Internets still. Slack, Snapchat und Atlassian waren stundenlang nicht erreichbar, Onlineshops verloren Bestellungen, Logistikdienste konnten Sendungen nicht verarbeiten. Der Auslöser saß in einer einzigen AWS-Region an der US-Ostküste. Der Ausfall zeigt eine unbequeme Wahrheit: Cloud-Konzentration ist kein reines IT-Thema, sondern ein Lieferkettenrisiko.
Das Wichtigste in Kürze
- Eine Region genügt. Der AWS-Ausfall vom Oktober 2025 startete mit einem leeren DNS-Eintrag in us-east-1 und legte über 15 Stunden Slack, Snapchat und tausende Onlineshops lahm.
- Konzentration ist ein Lieferkettenrisiko. Lagerverwaltung, Sendungsverfolgung und Zahlungsabwicklung laufen über die Cloud. Steht die Cloud, steht die physische Lieferkette mit.
- Multi-Cloud ist selten die Antwort. Ein zweiter Anbieter verdoppelt Komplexität und Kosten, nicht die Sicherheit. Für die meisten Mittelständler ist ein getestetes Multi-Region-Setup der bessere erste Schritt.
Verwandt:NIS2 und DORA sauber trennen: Compliance-Cluster in Kubernetes / Cloud-Backup mit IaC: Resilienz statt Restore-Risiko
Was in us-east-1 passiert ist
Der Ausfall begann mit einem winzigen Fehler in der DNS-Verwaltung des Datenbankdienstes DynamoDB. Eine Race Condition erzeugte einen leeren DNS-Eintrag für den regionalen Endpunkt. Die Automatik reparierte ihn nicht. DNS ist das Telefonbuch des Internets. War der Eintrag leer, fanden Anwendungen die Datenbank schlicht nicht mehr.
Aus dem anfänglichen DynamoDB-Problem wurde eine Kaskade. EC2-Instanzen ließen sich nicht mehr starten, Lambda-Funktionen und Fargate-Tasks scheiterten, Load Balancer und Container-Dienste fielen mit. Was als dreistündige Datenbankstörung begann, zog sich über mehr als 15 Stunden, bis alle abhängigen Dienste wieder liefen.
Warum eine Region die halbe Welt lahmlegt
us-east-1 ist nicht irgendeine Region. Sie ist die älteste und größte AWS-Region und beherbergt Steuerungsfunktionen, von denen andere Regionen abhängen. Bestimmte globale Dienste wie IAM-Updates oder DynamoDB Global Tables laufen zentral über us-east-1. Fällt sie aus, spüren das auch Kunden, die glauben, ganz woanders zu hosten.
Genau hier liegt der Denkfehler vieler Notfallpläne. Ein Unternehmen kann seine Anwendung sauber über mehrere Regionen verteilen und trotzdem hängen bleiben, weil die Steuerungsebene in einer Region konzentriert ist. Ausfallsicherheit auf dem Papier ist nicht dasselbe wie Ausfallsicherheit im Ernstfall.
Das Lieferketten-Problem hinter dem IT-Ausfall
Für Logistik und Handel ist ein solcher Ausfall kein abstraktes Technikproblem. Lagerverwaltung, Sendungsverfolgung, Auftragsannahme und Zahlungsabwicklung laufen zunehmend über Cloud-Dienste. Steht die Cloud, steht die physische Lieferkette gleich mit. Eine Stunde Stillstand kann bei einem mittelgroßen Händler einen fünfstelligen Eurobetrag kosten, bei größeren deutlich mehr.
Regulatoren haben das erkannt. Mit DORA für den Finanzsektor und NIS2 breiter rückt das Konzentrationsrisiko in den Fokus. Unternehmen müssen künftig belegen, dass sie die Abhängigkeit von einzelnen Anbietern und Regionen kennen und beherrschen. Ein pauschaler Verweis auf die Cloud reicht nicht mehr.
Warum Multi-Cloud oft kein echter Schutz ist
Der Reflex nach so einem Ausfall lautet Multi-Cloud. Doch zwei Anbieter parallel zu betreiben, verdoppelt zunächst die Komplexität und die Kosten, nicht automatisch die Sicherheit. Wenn die eigentliche Abhängigkeit in einer geteilten Steuerungsebene oder einem zentralen Dienst steckt, hilft ein zweiter Anbieter wenig.
Sinnvoller ist die ehrliche Frage, welche Dienste wirklich kritisch sind und welche echten Abhängigkeiten sie haben. Für die meisten Mittelständler ist ein sauberes Multi-Region-Setup beim vorhandenen Anbieter der bessere erste Schritt als ein teures Zweit-Cloud-Projekt, das niemand im Ernstfall geübt hat.
Was Logistik-IT jetzt prüfen sollte
Drei Fragen gehören auf den Tisch. Erstens: Welche unserer Prozesse stehen still, wenn eine einzelne Cloud-Region ausfällt? Zweitens: Haben wir versteckte Abhängigkeiten von zentralen Diensten wie IAM oder DNS, die regional konzentriert sind? Drittens: Haben wir das Failover jemals unter realen Bedingungen getestet, nicht nur in der Präsentation?
Wer diese Fragen nicht beantworten kann, hat kein Resilienzkonzept, sondern eine Hoffnung. Der Ausfall vom Oktober 2025 war eine teure Erinnerung daran, dass die Cloud die Verantwortung für Ausfallsicherheit nicht abnimmt, sondern nur verschiebt.
Häufige Fragen
Was ist ein Cloud-Konzentrationsrisiko?
Ein Konzentrationsrisiko entsteht, wenn zu viele kritische Prozesse von einem einzelnen Anbieter, einer Region oder einem zentralen Dienst abhängen. Fällt dieser eine Punkt aus, bricht überproportional viel zusammen. Der AWS-Ausfall vom Oktober 2025 ist ein Lehrbeispiel dafür.
Warum war ausgerechnet us-east-1 so folgenreich?
us-east-1 ist die älteste und größte AWS-Region und beherbergt globale Steuerungsfunktionen, von denen andere Regionen abhängen, etwa IAM-Updates und DynamoDB Global Tables. Ein Ausfall dort wirkt deshalb weit über die Region hinaus.
Schützt Multi-Cloud vor solchen Ausfällen?
Nicht automatisch. Multi-Cloud verdoppelt Komplexität und Kosten, beseitigt aber keine Abhängigkeit, die in einem geteilten zentralen Dienst steckt. Für viele Unternehmen ist ein getestetes Multi-Region-Setup beim vorhandenen Anbieter der bessere erste Schritt.
Was fordert die Regulierung dazu?
DORA im Finanzsektor und NIS2 breiter verlangen, dass Unternehmen ihre Abhängigkeiten von einzelnen Anbietern und Regionen kennen und steuern. Ein pauschaler Verweis auf die Cloud genügt nicht mehr, das Konzentrationsrisiko muss dokumentiert und beherrscht sein.
Wie teste ich meine Cloud-Resilienz richtig?
Nur ein Failover, das unter realen Bedingungen geübt wurde, ist ein echter Failover. Simulieren Sie den Ausfall einer ganzen Region und prüfen Sie, welche Prozesse stehen bleiben und welche versteckten Abhängigkeiten auftauchen. Eine Failover-Dokumentation ohne Test ist nur ein Wunschzettel.
Lesetipps der Redaktion
cloudmagazinKRITIS in die Cloud: Was die Migration absichertcloudmagazinAWS und Azure unter EU-Aufsicht: Der Lock-in wackeltcloudmagazinCloud-Broker: 30 Prozent weniger Multi-Cloud-KostenMehr aus dem MBF Media Netzwerk
MyBusinessFutureInvestitionsstau: Wie KI verborgene Budgets freilegtDigital ChiefsDie Milliardenwette der Hyperscaler und Ihre Cloud-RechnungSecurityTodayWenn ein Anruf die Autoproduktion stopptQuelle Titelbild: KI-generiert (Juli 2026)
