AWS-Großausfall in us-east-1: Eine DNS-Race-Condition legt das Internet lahm
Ein leerer DNS-Eintrag für DynamoDB hat am 20. Oktober die AWS-Region us-east-1 über Stunden lahmgelegt. Was genau passiert ist, warum auch Unternehmen ohne eigene AWS-Workloads betroffen waren und wie Sie Ihre Cloud-Architektur jetzt prüfen sollten.
Was ist passiert?
Am späten Abend des 19. Oktober (pazifische Zeit, nach deutscher Zeit am Morgen des 20. Oktober gegen 8:48 Uhr) begannen in der Region US-EAST-1 (Nord-Virginia) die Probleme. Laut der inzwischen veröffentlichten Analyse von AWS lag die Ursache in einer latenten Race Condition im automatisierten DNS-Management von DynamoDB. Das System besteht aus einem Planer, der DNS-Pläne erzeugt, und mehreren unabhängigen „Enactors“, die diese Pläne über Route 53 ausrollen. Ein verzögerter Enactor überschrieb einen neueren Plan mit einem veralteten, ein anderer räumte den alten Plan anschließend auf. Das Ergebnis: Der regionale Endpunkt dynamodb.us-east-1.amazonaws.com hatte plötzlich keine IP-Adressen mehr. Die Automatik konnte diesen Zustand nicht selbst reparieren, Ingenieure mussten manuell eingreifen.
DynamoDB selbst war nach rund drei Stunden wieder erreichbar. Weil aber zahlreiche interne AWS-Systeme von DynamoDB abhängen, folgten Folgefehler: Neue EC2-Instanzen ließen sich stundenlang nicht starten, Health Checks der Network Load Balancer schlugen fehl, und Dienste wie Lambda, ECS, EKS und Fargate waren bis zum Nachmittag beeinträchtigt. AWS gibt das Ende der Störung mit 14:20 Uhr PDT an, die Statusseite meldete gegen 15:01 Uhr PDT den vollständigen Normalbetrieb. Nach deutscher Zeit war das kurz nach Mitternacht.
Die Auswirkungen waren weltweit spürbar. Medienberichten zufolge fielen unter anderem Snapchat, Fortnite, Bezahldienste wie Venmo sowie Onlinebanking-Angebote britischer Banken zeitweise aus. Auch Amazons eigene Dienste waren betroffen.
AWS hat die betroffene DNS-Automatisierung weltweit deaktiviert, bis die Race Condition behoben und zusätzliche Schutzmechanismen eingebaut sind. Für Load Balancer und EC2 kündigte der Anbieter weitere Drosselungs- und Testmaßnahmen an.
Die Fehlerkette im Überblick:
Warum betrifft Sie das?
Viele Unternehmen in Deutschland betreiben ihre Workloads in Frankfurt (eu-central-1) und fühlen sich deshalb nicht betroffen. Das greift zu kurz. Einige globale AWS-Funktionen hängen an us-east-1, etwa Teile von IAM oder DynamoDB Global Tables, die laut AWS ebenfalls Replikationsverzögerungen hatten. Hinzu kommt die indirekte Abhängigkeit: Ihr Ticketsystem, Ihr Zahlungsanbieter, Ihr CRM oder Ihre Monitoring-Lösung laufen möglicherweise genau dort. Fällt der SaaS-Anbieter aus, steht Ihr Prozess still, auch wenn Ihre eigene Infrastruktur fehlerfrei läuft.
Der Vorfall zeigt außerdem: Multi-AZ schützt vor dem Ausfall eines Rechenzentrums, nicht vor einem Fehler in der Steuerungsebene einer ganzen Region.
Was Sie jetzt tun sollten
- Abhängigkeiten inventarisieren: Welche Ihrer Systeme, auch SaaS-Dienste, laufen in us-east-1 oder nutzen globale Dienste mit Sitz dort? Fragen Sie kritische Anbieter aktiv nach ihrer Regionsstrategie.
- Kritikalität bewerten: Legen Sie für jede Anwendung fest, welche Ausfallzeit (RTO) und welcher Datenverlust (RPO) tragbar sind. Nicht jede Anwendung braucht Multi-Region.
- Multi-Region gezielt einsetzen: Für wirklich kritische Dienste lohnt sich eine zweite Region mit Datenreplikation und vorbereitetem Failover, idealerweise per Infrastructure as Code, damit die Umgebung reproduzierbar ist.
- Statische Stabilität prüfen: Laufen bestehende Instanzen und Container weiter, wenn sich keine neuen starten lassen? Autoscaling, das im Fehlerfall neue Kapazität braucht, kann genau dann versagen.
- DR-Tests durchführen: Ein Notfallplan, der nie geübt wurde, ist ein Wunsch. Planen Sie regelmäßige Failover-Übungen ein.
- Kommunikation vorbereiten: Halten Sie Statusseite, Ansprechpartner und Kundeninformation für den Ernstfall bereit.
Fazit
Der Ausfall war kein exotischer Hardwaredefekt, sondern ein Softwarefehler in einer Automatisierung, die eigentlich für Stabilität sorgen sollte. Solche Fehler lassen sich nie ganz ausschließen. Entscheidend ist, ob Ihre Architektur und Ihre Prozesse damit umgehen können. Wenn Sie Ihre Abhängigkeiten und Ihr Notfallkonzept auf den Prüfstand stellen möchten, sprechen Sie uns an.