Amazon nennt technische Ursache für Ausfall von AWS-Diensten

Amazon hat Details zu einer großflächigen Störung des DynamoDB-Dienstes in der AWS-Region Nord-Virginia (US-EAST-1) veröffentlicht. Das Ereignis ereignete sich am 19. und 20. Oktober 2025 und dauerte von 23:48 Uhr PDT am 19. Oktober bis 14:20 Uhr PDT am 20. Oktober. Die Störung gliederte sich in drei Hauptphasen:

1. Zwischen 23:48 Uhr am 19. Oktober und 2:40 Uhr am 20. Oktober kam es zu erhöhten API-Fehlern bei DynamoDB, wodurch Kunden und abhängige Dienste keine neuen Verbindungen herstellen konnten.

2. Von 5:30 Uhr bis 14:09 Uhr traten bei einigen Network Load Balancern (NLB) in der Region Verbindungsprobleme auf, verursacht durch Fehler bei der Zustandsprüfung der Load Balancer.

3. Zwischen 2:25 Uhr und 10:36 Uhr schlugen Starts neuer EC2-Instanzen fehl. Obwohl ab 10:37 Uhr neue Instanzen erfolgreich gestartet wurden, traten bei einigen Verbindungsprobleme auf, die bis 13:50 Uhr behoben waren.

Amazon erklärte, die Störung sei durch einen Fehler im automatisierten DNS-Verwaltungssystem von DynamoDB verursacht worden. Dieser latente Fehler führte zu einem leeren DNS-Eintrag für den regionalen Endpunkt (dynamodb.us-east-1.amazonaws.com), der von der Automatisierung nicht korrigiert werden konnte.

Die DNS-Verwaltung von DynamoDB ist in zwei Komponenten aufgeteilt: den DNS Planner, der regelmäßig DNS-Pläne für die Endpunkte erstellt, und den DNS Enactor, der diese Pläne in Amazon Route53 umsetzt. Normalerweise arbeiten mehrere Enactors unabhängig und redundant, um Konsistenz und Ausfallsicherheit zu gewährleisten. In diesem Fall kam es durch ungewöhnliche Verzögerungen eines Enactors in Kombination mit der laufenden Planerstellung zu einer Race Condition. Ein älterer Plan überschrieb dabei versehentlich den aktuellen DNS-Status, was die sofortige Entfernung aller IP-Adressen für den regionalen Endpunkt zur Folge hatte und das System in einen inkonsistenten Zustand versetzte.

Die AWS-Ingenieure erkannten die Ursache gegen 00:38 Uhr am 20. Oktober. Abhilfemaßnahmen ermöglichten ab 1:15 Uhr teilweise Verbindungen, bis um 2:25 Uhr alle DNS-Einträge wiederhergestellt waren. Bis 2:40 Uhr waren auch zwischengespeicherte DNS-Einträge abgelaufen, und die Kunden konnten wieder auf DynamoDB zugreifen.

Ausfall von Amazon EC2 in Nord-Virginia im Oktober 2025

Zwischen dem 19. Oktober um 23:48 Uhr PDT und dem 20. Oktober um 13:50 Uhr PDT kam es in der AWS-Region Nord-Virginia (us-east-1) zu erhöhten EC2-API-Fehlerraten, Verzögerungen und Problemen beim Start neuer Instanzen. Laufende EC2-Instanzen waren von der Störung nicht betroffen.

Nach der Behebung des DynamoDB-DNS-Problems um 2:25 Uhr PDT traten weiterhin Startfehler für neue Instanzen auf, die Meldungen wie „Anforderungslimit überschritten“ oder „unzureichende Kapazität“ auslösten. Die vollständige Wiederherstellung begann um 12:01 Uhr PDT und war um 13:50 Uhr abgeschlossen.

Die Störung hing mit den Subsystemen zusammen, die EC2-Instanzen verwalten. Der DropletWorkflow Manager (DWFM) steuert die physischen Server („Droplets“), auf denen EC2-Instanzen laufen, und überwacht deren Status über sogenannte Leases. Der Network Manager verteilt die Netzwerkkonfiguration an neue Instanzen, um deren Kommunikation innerhalb der VPC und mit dem Internet zu ermöglichen.

Durch die Abhängigkeit von DynamoDB scheiterten ab 23:48 Uhr PDT die DWFM-Zustandsprüfungen. Dies führte dazu, dass Leases zwischen DWFM und Droplets ausliefen, wodurch neue EC2-Starts blockiert wurden. Nach Wiederherstellung der DynamoDB-APIs begann DWFM mit der Erneuerung der Leases. Aufgrund der großen Anzahl von Droplets und Rückständen im System kam es zu Verzögerungen, die teilweise Fehlermeldungen und Anfragedrosselungen verursachten.

Um die Situation zu beheben, wurden DWFM-Hosts selektiv neu gestartet, wodurch die Leases wiederhergestellt und die Warteschlangen entlastet wurden. Ab 5:28 Uhr waren neue Starts wieder möglich, zunächst jedoch mit eingeschränkter Kapazität. Der Network Manager verteilte anschließend die Netzwerkkonfigurationen, wobei es aufgrund des Rückstaus bis 10:36 Uhr zu erhöhten Latenzen kam.

Die abschließende Aufhebung der Anfragedrosselung begann um 11:23 Uhr. Um 13:50 Uhr waren alle EC2-APIs wieder vollständig funktionsfähig, und neue Instanzen konnten wie gewohnt gestartet werden.

Netzwerk-Lastenausgleich (NLB) und weitere AWS-Dienste betroffen

Die Verzögerungen bei der Übertragung des Netzwerkstatus für neu gestartete EC2-Instanzen hatten auch Auswirkungen auf den Netzwerk-Lastenausgleich (NLB) in der AWS-Region Nord-Virginia (us-east-1). Zwischen 5:30 Uhr und 14:09 Uhr PDT am 20. Oktober traten bei einigen Kunden vermehrt Verbindungsfehler auf. Ursache waren fehlerhafte Zustandsprüfungen innerhalb des NLB-Subsystems, die auf die unvollständig übertragene Netzwerkkonfiguration neuer EC2-Instanzen zurückgingen. Dadurch wechselten Zustandsprüfungen zwischen „fehlgeschlagen“ und „in Ordnung“, was dazu führte, dass NLB-Knoten und Backend-Ziele temporär aus dem DNS entfernt wurden. Techniker deaktivierten um 9:36 Uhr die automatischen Failovers, wodurch die NLB-Kapazitäten wiederhergestellt wurden. Der automatische DNS-Integritätscheck-Failover wurde nach der vollständigen Wiederherstellung von EC2 um 14:09 Uhr wieder aktiviert.

Weitere AWS-Dienste

Zwischen dem 19. Oktober um 23:51 Uhr PDT und dem 20. Oktober um 14:15 Uhr PDT kam es zu API-Fehlern und Latenzen bei AWS Lambda in Nord-Virginia. Probleme mit dem DynamoDB-Endpunkt verhinderten zunächst die Erstellung und Aktualisierung von Funktionen, was zu Verzögerungen bei SQS- und Kinesis-Ereignisquellen führte. Die Wiederherstellung erfolgte schrittweise, unter anderem durch Drosselung von Event Source Mappings, und war bis 14:15 Uhr abgeschlossen.

Zwischen dem 19. Oktober um 23:45 Uhr PDT und dem 20. Oktober um 14:20 Uhr kam es zu Fehlern beim Start von Containern und Verzögerungen bei der Cluster-Skalierung bei ECS, EKS und Fargate, die bis 14:20 Uhr behoben waren.

Amazon Connect war zwischen dem 19. Oktober um 23:56 Uhr PDT und dem 20. Oktober um 13:20 Uhr PDT von Fehlern bei Anrufen, Chats, Aufgaben, E-Mails und Fällen betroffen. Nach der Wiederherstellung der DynamoDB-Endpunkte funktionierten die meisten Funktionen wieder, Verzögerungen bei Chats hielten jedoch bis 5:00 Uhr an. Spätere NLB- und Lambda-Probleme führten erneut zu Fehlern, die bis zur Wiederherstellung um 13:20 Uhr andauerten.

Beim AWS Security Token Service (STS) traten zwischen dem 19. Oktober um 23:51 Uhr und dem 20. Oktober um 9:59 Uhr PDT erhöhte API-Fehler und Latenzen auf. Nach der Wiederherstellung der DynamoDB-Endpunkte um 1:19 Uhr normalisierte sich der Betrieb, mit kurzfristigen Auswirkungen durch NLB-Zustandsprüfungsfehler bis 9:59 Uhr.

IAM-Anmeldungen bei der AWS Management Console waren zwischen dem 19. Oktober um 23:51 Uhr und dem 20. Oktober um 1:25 Uhr PDT aufgrund von DynamoDB-Problemen eingeschränkt. Mit der Wiederherstellung der DynamoDB-Endpunkte um 1:25 Uhr nahm der Dienst den normalen Betrieb wieder auf.

Bei Amazon Redshift kam es zwischen dem 19. Oktober um 23:47 Uhr PDT und dem 20. Oktober zu Fehlern beim Erstellen, Ändern und Abfragen von Clustern. Ursache waren die Abhängigkeit von DynamoDB-Endpunkten und blockierte EC2-Starts, wodurch Cluster in einen „Änderungszustand“ gerieten. Die Wiederherstellung der Redshift-Cluster erfolgte schrittweise bis zum 21. Oktober um 4:05 Uhr PDT.

Weitere von dem Vorfall betroffene Dienste in Nord-Virginia waren Managed Workflows für Apache Airflow, Outposts-Lebenszyklusoperationen und das AWS Support Center.

Maßnahmen und Ausblick

Amazon deaktivierte den DynamoDB DNS Planner und die DNS Enactor-Automatisierung weltweit, um die zugrunde liegende Race Condition zu beheben und zusätzliche Schutzmaßnahmen einzuführen. Für NLB wird ein Geschwindigkeitskontrollmechanismus implementiert, EC2 erhält erweiterte Tests und Drosselungsmechanismen. Ziel ist es, die Wiederherstellungszeit zu verkürzen und ähnliche Vorfälle künftig zu vermeiden.

Abschluss

Amazon entschuldigte sich für die Auswirkungen des Vorfalls auf Kunden und kündigte an, aus den Ereignissen zu lernen, um die Verfügbarkeit der Dienste weiter zu verbessern.

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon