Innenansicht des AWS-Oktober-Ausfalls: Was schiefging
Über 14 Stunden lang brach das kritischste Rückgrat des Internets still unter dem Gewicht eines DNS-Bugs zusammen. Am 19. und 20. Oktober erlebte Amazon Web Services (AWS) eine Kaskadenstörung in seiner Region Northern Virginia (us-east-1) — einem seiner größten und wichtigsten Datenknoten. Die Störung begann spätabends, aber ihre Wellen trafen alles von EC2-Starts über Lambda-Aufrufe und Container-Dienste bis hin zum Call-Routing von Amazon Connect.
Den offiziellen Post-Mortem von AWS können Sie hier nachlesen.
Was also ist passiert?
Es begann mit einer DNS-Panne
Um 23:48 Uhr PDT am 19. Oktober begann DynamoDB von AWS — die NoSQL-Datenbank, die unzählige Apps und interne AWS-Dienste antreibt — Fehlerraten zu werfen. Das ist Techniker-Sprech für „alles fing an, kaputtzugehen“.
Der Übeltäter? Eine subtile Race Condition tief im automatisierten DNS-Management-System von DynamoDB. Stellen Sie sich zwei Ingenieure vor, die gleichzeitig dieselbe Tabelle bearbeiten. Einer wird fertig und speichert. Der andere, der an einer alten Version arbeitet, überschreibt das Ergebnis. Das Resultat? Ein leerer DNS-Eintrag, der DynamoDB für alle offline nahm, die über den öffentlichen Endpunkt verbinden wollten.
Das klingt nach einer überschaubaren Panne, aber die Auswirkungen waren alles andere als das. DynamoDB ist ein Eckpfeiler-Dienst — hustet er, fängt alles drumherum an zu keuchen.
Wenn Automatisierung nach hinten losgeht
Um zu verstehen, warum ein DNS-Bug alles zum Einsturz brachte, muss man einen Blick darauf werfen, wie AWS Service-Endpunkte verwaltet. DynamoDB betreibt Tausende Load Balancer. Um diesen ganzen Traffic zu jonglieren, verlässt sich AWS auf einen hochautomatisierten DNS-Planer (der Pläne erstellt) und DNS-Enactors (die sie auf Route53 anwenden).
Diese Systeme sollen im Einklang arbeiten, aber in dieser Nacht geriet ein Enactor in Verzug. Während er langsam einen älteren DNS-Plan anwendete, raste ein anderer Enactor mit einem neueren durch. Timing-Pannen führten dazu, dass der ältere den neueren Plan überschrieb — und derselbe Plan wurde dann beim Aufräumen gelöscht. Ergebnis? Der öffentliche Endpunkt verschwand, das DNS-Routing brach zusammen, und Tausende Apps liefen ins Leere.
Und weil das nicht nur ein einzelner Fall von DNS-Fehlkonfiguration war, sondern einer, der vom Automatisierungssystem festgeschrieben wurde, mussten Menschen eingreifen, um ihn zu entwirren.
EC2 gerät unter Druck
Als DynamoDB ausfiel, fielen auch Teile von EC2 aus, aber nicht aus den Gründen, die man erwarten würde. Bestehende Instanzen waren in Ordnung. Neue? Nicht so sehr.
Der Startprozess für neue EC2-Instanzen hängt von einem Subsystem namens DWFM (Droplet Workflow Manager) ab. DWFM nutzt DynamoDB, um Leases für physische Server (Droplets) zu verwalten. Sobald das DNS-Chaos DynamoDB lahmlegte, konnte DWFM diese Leases nicht mehr aufrechterhalten. Es verlor langsam den Griff auf die Infrastruktur.
Als AWS DynamoDB wieder online brachte, versuchte DWFM hektisch, die Leases neu aufzubauen — aber der Rückstau war zu groß, und die Wiederholungsversuche liefen immer wieder in Timeouts. Es eskalierte zu dem, was AWS-Ingenieure einen „congestive collapse“ nannten. Die Lösung? Traffic drosseln, Komponenten neu starten und etwas altmodische manuelle Intervention.
Am frühen Nachmittag des 20. Oktober liefen EC2-Starts größtenteils wieder. Aber das war noch nicht das Ende.
Load Balancer gerieten ins Wanken
Als Nächstes stolperte der Network-Load-Balancer-Dienst (NLB) über die Dominosteine. NLB nutzt Health-Checks, um festzustellen, ob Backend-Ziele (typischerweise EC2-Instanzen) gesund genug sind, um Traffic zu bedienen. Der Haken? Diese Health-Checks liefen, bevor der Netzwerkstatus von EC2 vollständig wiederhergestellt war, sodass NLB völlig gesunde Ziele fälschlicherweise als tot markierte.
Das führte zu einer Hin-und-her-Schleife — Health-Checks schlugen fehl, Instanzen wurden entfernt, dann bestanden sie den Check wieder und wurden zurückgeholt. Dieses Ping-Pong überlastete das Health-Check-System und löste DNS-Failovers aus, was ironischerweise noch mehr Kapazität entfernte. Manche Nutzer sahen, wie ihr Traffic umgeleitet wurde, nur um auf demselben instabilen Pfad zu landen.
Die Lösung kam gegen 9:36 Uhr, als AWS das Auto-Failover vorübergehend deaktivierte und die Lage stabilisierte.
Lambda, ECS und Redshift: Kollateralschäden
Auch die Dienste, die auf DynamoDB und EC2 aufbauen, begannen zu bröckeln.
Lambda-Funktionen ließen sich nicht mehr auslösen. Interne Systeme konnten SQS-Warteschlangen nicht mehr abfragen. Event-Quellen wurden gedrosselt.
ECS, EKS und Fargate konnten keine neuen Container hochfahren — weil EC2 die darunterliegende Compute-Leistung nicht starten konnte.
Amazon Connect, die Cloud-Callcenter-Lösung, verlor die Fähigkeit, Chats, Anrufe oder Aufgaben zu bearbeiten. Manche Nutzer bekamen ein Besetztzeichen, andere einfach Stille.
Redshift kämpfte damit, Queries auszuführen und Cluster-Nodes zu aktualisieren. IAM-Integrationen schlugen fehl, und die Abhängigkeit von EC2 bedeutete, dass manche Cluster im Nichts hängen blieben.
Selbst die AWS Management Console entkam dem Chaos nicht. IAM-Nutzer, die sich anmelden wollten, stießen auf Authentifizierungsfehler. In manchen Fällen fielen ganze föderierte Login-Workflows komplett aus.
Was unternimmt AWS also dagegen?
Zu ihrer Ehre muss man sagen: AWS hat nicht um den heißen Brei geredet. Man räumte den Ausfall ein, legte die Grundursachen dar und skizzierte die Roadmap, um eine Wiederholung zu verhindern.
Das ändert sich:
Die DNS-Automatisierung von DynamoDB ist weltweit deaktiviert, bis die Race Condition gepatcht ist und neue Schutzmechanismen vorhanden sind.
Der DNS-Enactor erhält besseren Schutz, um zu verhindern, dass gültige Pläne durch alte überschrieben werden.
NLB wird eine „Velocity Control“ einführen — im Grunde eine Möglichkeit, zu begrenzen, wie schnell bei Health-Check-Fehlern Kapazität entzogen wird.
Das DWFM von EC2 wird intensiveren Stresstests und einer verbesserten Logik zur Warteschlangen-Drosselung unterzogen.
Allerdings ist das Beheben von Automatisierungsproblemen wie das Flicken eines Schiffs, während man auf hoher See segelt. AWS spielt ein heikles Spiel: Es geht nicht nur darum, Löcher zu stopfen, sondern zu verändern, wie diese fundamentalen Dienste im großen Maßstab miteinander kommunizieren.
Das große Ganze
Wenn uns dieser Ausfall etwas gelehrt hat, dann, dass die Cloud keine abstrakte, unbesiegbare Kraft ist. Sie ist ein komplexes Orchester automatisierter Systeme, und selbst die kleinste Missklang-Note — eine Race Condition in einem DNS-Enactor — kann das Ganze ins Chaos stürzen.
Für Entwickler und Unternehmen ist dieser Vorfall eine deutliche Mahnung: Entwerfen Sie nicht nur für Uptime, entwerfen Sie für den Ausfall. Redundanz über Regionen hinweg. Elegante Fallbacks. Und, wo möglich, Human-in-the-Loop-Mechanismen, die Automatisierung außer Kraft setzen können, wenn etwas schiefläuft.
Der N.-Virginia-Ausfall von AWS war nicht der größte Cloud-Vorfall der Geschichte — aber ein aufschlussreicher. Er zeigte, wie eng alles in moderner Cloud-Infrastruktur inzwischen gekoppelt ist. Er legte die Kompromisse der Automatisierung offen. Und er machte klar, dass selbst die widerstandsfähigsten Systeme blinde Flecken haben können.
Was AWS angeht: Die Arbeit liegt noch vor ihnen. Die Zukunft der Cloud ruht weiterhin auf ihren Schultern — aber für ein paar Stunden im Oktober wurden diese Schultern etwas wacklig.