Am Morgen des 20. Oktobers 2025 brach für viele von uns ein Stück Alltag weg: Webseiten und Apps, auf die wir uns verlassen hatten, gingen nicht mehr – Streaming, Gaming, Banking, selbst Smart-Home-Geräte meldeten sich ab. Verantwortlich: der Cloud-Riese AWS (Amazon) als einer der global Player im Hostingsegment/Internetdienstanbieter. Aber was genau ist hier Stückweise technisch schief gelaufen und wie hat Amazon dann dieses riesige Technische Konstrukt wieder aufgebaut?
Der Vorfall gilt als die schwerste Internetstörung seit dem massiven CrowdStrike-Ausfall im vergangenen Jahr, bei dem weltweit IT-Systeme in Krankenhäusern, Banken und Flughäfen ausfielen. Er zeigt einmal mehr, wie empfindlich und eng verzahnt unsere digitale Infrastruktur mittlerweile ist.
Bemerkenswert ist auch, dass der AWS-Standort „US-EAST-1“ in Nord-Virginia bereits zum dritten Mal innerhalb von fünf Jahren Auslöser einer großflächigen Internet(-dienst)störung war – ein deutliches Zeichen dafür, wie zentral und gleichzeitig kritisch dieser Standort für das globale Netz geworden ist. Zu erwähnen ist hierbei auch nochmals, dass es sich hierbei ja um keine Störung des Internets per se handelte, da jegliche Internetanbieter natürlich weiterhin deren Netzwerk auslieferten und verfügbar waren. Dennoch kann man von einer Störung des „Internets“ sprechen, da bei einem Ausfall eines Anbieters dieser größe einfach so viele markante Dienste betroffen sind, wodurch dann ein Teil des gewohnten Internet-Nutzens nicht möglich war.
Durch verschiedenste Berichte von Amazon, Techblogs und Analysten aus diesem Bereich versuchte Ich genau herauszufinden, was ablief – vor allem im Rechenzentrum US-EAST-1 (Northern Virginia).
Denn dort in diesem Rechenzentrum startete der Ausfall – einem der wichtigsten Knotenpunkte von AWS.
Der erste große Fehler: Probleme bei der DNS-Auflösung für den Service Amazon DynamoDB (eine zentrale NoSQL-Datenbank von Amazon für deren Dienste) in dieser Region – sprich: Dienste konnten nicht mehr zuverlässig die richtigen IP-Adressen finden, weil der DNS nicht korrekt arbeitete.
Doch es ging weiter als parallel eine Fehlfunktion eines internen Subsystems bei AWS auftrat, das die Health-Monitoring-Funktionen von Network Load Balancers (NLBs) überwacht – sprich: der Mechanismus, der sicherstellt, dass Traffic gleichmäßig verteilt wird und Systeme gesund bleiben.
Diese beiden Probleme zusammen erzeugten eine Kaskade: DNS-Fehler → Services erreichen ihre Ziele nicht → Launches/Instanzen stocken → Health-Checks fallen → weitere Dienste stürzen ein.
Somit waren dann zahlreiche Dienste von AWS selbst (in der Spitze hatte Ich Meldungen von über 100 gestörten Diensten gesehen) und viele Kunden-Apps und Strukturen von Dienstanbietern, die AWS für die eigene Infrastruktur nutzen betroffen: u. a. Spiele, soziale Netzwerke, FinTech-Apps, Smart-Home.
Technisch betroffen waren insbesondere:
- DynamoDB (DNS-Endpoint Probleme)
- EC2 (neue Instanzen konnten nicht zuverlässig starten)
- Lambda, SQS (wegen gestörter Event-Source-Mappings / verzögerter Queue-Verarbeitung)
- NLBs / Health-Checks → Traffic wurde fehlerhaft verteilt
→ Viele Apps sahen Fehler wie Timeouts, 5xx-Antworten, abruptes Abschalten.
Wie hat AWS das Problem schrittweise behoben
- DNS-Probleme bei DynamoDB wurden identifiziert und behoben (wenn auch nicht sofort für alle Pfade).
- Temporäres Throttling: AWS drosselte bestimmte Operationen (z. B. neue EC2-Instanz-Launches, asynchrone Lambda-Invocations, SQS-Verarbeitung), um einen „System-Überlauf“ zu vermeiden.
- Schrittweise Wiederherstellung der internen Health-Monitoring-Subsysteme (insbesondere NLB).
- Reduktion der Throttles und Rückkehr zu normalen Betriebswerten, nachdem Stabilität nachgewiesen war.
- Backlogs in Diensten wie AWS Config, Redshift, Connect wurden noch nach Abschluss des Hauptvorfalls abgearbeitet.
Trotz allem hat das sicherlich riesige Technik-Team bei AWS eine herausragende Arbeit geleistet und dieses komplizierte Konstrukt derer Services strukturiert und wirklich schnell wieder in einen Stabilen Betrieb verschafft – bei einem nahezu Totalausfall.
Auf der AWS-Status-Seite (https://health.aws.amazon.com/health/status) kann man mittlerweile dem Status „resolved“ bei diesem Ticket entnehmen, dass alles wieder dem Normalbetrieb zurückgekehrt ist.
Hier noch der letzte Eintrag und eine Zusammenfassung Amazons in deren Fehlerlog:
Oct 20 3:53 PM PDT Between 11:49 PM PDT on October 19 and 2:24 AM PDT on October 20, we experienced increased error rates and latencies for AWS Services in the US-EAST-1 Region. Additionally, services or features that rely on US-EAST-1 endpoints such as IAM and DynamoDB Global Tables also experienced issues during this time. At 12:26 AM on October 20, we identified the trigger of the event as DNS resolution issues for the regional DynamoDB service endpoints. After resolving the DynamoDB DNS issue at 2:24 AM, services began recovering but we had a subsequent impairment in the internal subsystem of EC2 that is responsible for launching EC2 instances due to its dependency on DynamoDB. As we continued to work through EC2 instance launch impairments, Network Load Balancer health checks also became impaired, resulting in network connectivity issues in multiple services such as Lambda, DynamoDB, and CloudWatch. We recovered the Network Load Balancer health checks at 9:38 AM. As part of the recovery effort, we temporarily throttled some operations such as EC2 instance launches, processing of SQS queues via Lambda Event Source Mappings, and asynchronous Lambda invocations. Over time we reduced throttling of operations and worked in parallel to resolve network connectivity issues until the services fully recovered. By 3:01 PM, all AWS services returned to normal operations. Some services such as AWS Config, Redshift, and Connect continue to have a backlog of messages that they will finish processing over the next few hours. We will share a detailed AWS post-event summary.
Übersetzt:
20. Oktober, 00:53 MEZ
Zwischen 06:49 MEZ am 20. Oktober (das entspricht 11:49 PM PDT am 19. Oktober) und 11:24 MEZ am 20. Oktober (2:24 AM PDT am 20. Oktober) haben wir erhöhte Fehlerraten und Latenzen bei AWS-Services in der Region US-EAST-1 festgestellt. Zusätzlich hatten Services oder Funktionen, die auf US-EAST-1 Endpoints angewiesen sind, wie IAM und DynamoDB Global Tables, in diesem Zeitraum ebenfalls Probleme.Um 09:26 MEZ am 20. Oktober (12:26 AM PDT am 20. Oktober) identifizierten wir die Ursache des Vorfalls als DNS-Auflösungsprobleme der regionalen DynamoDB-Serviceendpoints. Nach Behebung des DynamoDB-DNS-Problems um 11:24 MEZ (2:24 AM PDT) begannen die Services sich zu erholen, aber wir hatten anschließend eine Beeinträchtigung im internen Subsystem von EC2, das für das Starten von EC2-Instanzen verantwortlich ist, da es von DynamoDB abhängig ist.
Während wir weiterhin die Beeinträchtigungen beim Start von EC2-Instanzen behoben, wurden auch die Health Checks des Network Load Balancers beeinträchtigt, was zu Netzwerkverbindungsproblemen in mehreren Services wie Lambda, DynamoDB und CloudWatch führte. Wir stellten die Health Checks des Network Load Balancers um 18:38 MEZ (9:38 AM PDT) wieder her.
Im Rahmen der Wiederherstellungsmaßnahmen drosselten wir vorübergehend einige Operationen, wie das Starten von EC2-Instanzen, die Verarbeitung von SQS-Warteschlangen über Lambda Event Source Mappings und asynchrone Lambda-Aufrufe. Nach und nach reduzierten wir die Drosselung und arbeiteten parallel daran, die Netzwerkverbindungsprobleme zu beheben, bis die Services vollständig wiederhergestellt waren.
Bis 23:01 MEZ (3:01 PM PDT) waren alle AWS-Services wieder im Normalbetrieb. Einige Services wie AWS Config, Redshift und Connect haben weiterhin einen Rückstau an Nachrichten, die in den nächsten Stunden verarbeitet werden. Wir werden eine detaillierte AWS-Nachberichtszusammenfassung teilen.
Fazit
Der Ausfall von AWS am 20. Oktober war für viele ein Weckruf: Die digitale Infrastruktur ist stark vernetzt und damit auch stark verwundbar wenn an den „richtigen“ Stellen Probleme auftreten. Doch er bietet auch eine Chance: Für jede Organisation, ihre Architektur-Annahmen zu prüfen, resilienter zu werden und sich nicht auf das „immer funktioniert schon“ zu verlassen.
Am Ende zeigte sich: Nicht die große Cyberattacke, sondern technische Abhängigkeiten und Infrastruktur-Feinheiten können einen ganzen Tag online lahmlegen. Und wenn selbst US-EAST-1 inzwischen zum dritten Mal in fünf Jahren einen Teil des Internets mitreißt, ist klar: Redundanz ist kein Luxus, sondern überlebenswichtig.
Manchmal merkt man dann erst, wie entspannt es sein kann, wenn die eigenen Systeme nicht von den ganz großen Playern am anderen Ende der Welt abhängen. 🙂
Hier nachträglich noch der von Amazon veröffentlichte „Abschlussbericht“: https://aws.amazon.com/de/message/101925/
