Eine Region fällt, die halbe Lieferkette steht

Ein DNS-Fehler in der AWS-Region us-east-1 löste am 20. Oktober 2025 eine Kette von Dienststörungen aus. Auch Funktionen mit Abhängigkeiten zu dieser Region waren betroffen. Für Unternehmen mit cloudgestützten Lieferketten zählt deshalb, welche Prozesse und Dienste einen gemeinsamen Ausfallpunkt teilen. Ein getesteter Wiederherstellungsplan macht diese Abhängigkeiten sichtbar.

Das Wichtigste in Kürze

Ein DNS-Fehler löste eine Dienstkaskade aus

Ausgangspunkt war laut AWS-Vorfallbericht eine Race Condition in der DNS-Verwaltung von DynamoDB. Sie hinterließ einen leeren DNS-Eintrag für den regionalen Endpunkt. Die Automatik konnte den Fehler nicht selbst beheben. Neue Verbindungen zum betroffenen Endpunkt schlugen dadurch fehl.

Nach der Behebung des DNS-Problems blieben abhängige Systeme beeinträchtigt. Unter anderem war das Starten neuer EC2-Instanzen gestört. Später verursachten fehlerhafte Zustandsprüfungen von Network Load Balancern weitere Verbindungsprobleme. Die anfängliche DNS-Störung dauerte knapp drei Stunden, die Wiederherstellung weiterer Dienste zog sich über den Tag.

Regionale Ausfälle können über die Region hinausreichen

Auch einzelne Funktionen mit Abhängigkeit zu us-east-1 waren betroffen, darunter Funktionen von IAM und DynamoDB Global Tables. Eine Anwendung in einer anderen Region ist deshalb nur dann vom konkreten Ausfallpfad unabhängig, wenn auch ihre benötigten Dienste und Betriebsabläufe dort verfügbar sind.

Für die Analyse reicht eine Liste der eigenen Server nicht aus. Dazu gehören Datenbanken, Identitätsdienste, DNS, Schnittstellen und die Dienste von Zulieferern. Bei jedem kritischen Prozess sollte erkennbar sein, welche dieser Komponenten für den Betrieb und welche für die Wiederherstellung gebraucht werden.

Lieferketten brauchen klare Wiederherstellungsziele

Ein Ausfall kann beispielsweise die Auftragsannahme oder den Zugriff auf Lagerdaten unterbrechen, wenn die jeweiligen Anwendungen von einer betroffenen Cloud-Komponente abhängen. Wie weit sich eine Störung auswirkt, hängt vom konkreten Prozess und den vorhandenen Ausweichmöglichkeiten ab.

IT und Fachbereich sollten für jeden kritischen Prozess festlegen, wie lange er ausfallen darf und wie viel Datenverlust tragbar ist. Das AWS Well-Architected Framework bezeichnet diese Ziele als Recovery Time Objective und Recovery Point Objective. Regelmäßige Wiederherstellungs- und Failover-Tests zeigen, ob die gewählte Architektur sie erreicht.

Multi-Region und Multi-Cloud gezielt abwägen

Eine zweite Region beim vorhandenen Anbieter kann ein sinnvoller Schritt sein. Dafür müssen Daten und Anwendung dort verfügbar sein und die Umschaltung darf keine ausgefallene Komponente voraussetzen. Ein Test sollte auch prüfen, ob Berechtigungen, Schnittstellen und Betriebswerkzeuge in der Zielregion funktionieren.

Ein zweiter Anbieter kann zusätzliche Abhängigkeiten vom ersten Anbieter verringern. Er bringt zugleich Integrations- und Betriebsaufwand mit sich. Welche Lösung passt, hängt von den Wiederherstellungszielen, den tatsächlichen gemeinsamen Abhängigkeiten und den verfügbaren Ressourcen ab.

Für Finanzunternehmen im Geltungsbereich von DORA kommt eine rechtliche Dimension hinzu: Bei vorgesehenen Verträgen für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen, müssen sie unter anderem Konzentrationsrisiken bewerten. Artikel 29 nennt dabei schwer ersetzbare Anbieter und mehrere entsprechende Verträge mit demselben oder eng verbundenen Anbietern.

Häufige Fragen

Quelle Titelbild: KI-generiert (Juli 2026)