Zusammenfassung

  • ThousandEyes setzt die Wiederherstellung der DNS-Informationen auf den 20. Oktober 2025 um 09:25 UTC. Fehler beim Start neuer EC2-Instanzen oder Probleme mit deren Konnektivität meldet die Analyse dagegen bis 20:50 UTC. Das sind verschiedene Wiederherstellungsmarken, keine einheitliche Ausfalldauer für sämtliche Kunden. Quelle: ThousandEyes
  • Dipak Kr das beschreibt zwei nachgelagerte Hindernisse: überlastete Verwaltungsprozesse beim Wiederaufbau interner EC2-Leases und einen gesonderten Rückstau bei Netzwerkaktualisierungen. Seine Erklärung ist eine auf Medium veröffentlichte Sekundärdarstellung, kein eigenständiger AWS-Untersuchungsbericht. Quelle: Dipak Kr das

Der erste wieder erreichbare Dienst war nicht das letzte Wiederherstellungsziel

Die Störung vom 19. und 20. Oktober 2025 betraf nach den hier herangezogenen Darstellungen die AWS-Region Northern Virginia, us-east-1. Dipak Kr das führt den auslösenden Fehler bei der Auflösung des DynamoDB-Endpunkts auf eine zuvor verborgene Race Condition in der automatisierten DNS-Verwaltung zurück. Damit beschreibt er einen Fehler im Zusammenspiel automatisierter Abläufe, nicht den gleichzeitigen Ausfall jeder AWS-Region. Seine Darstellung des Ereignisses bildet den Ausgangspunkt dieses Rückblicks auf Amazon Web Services.

Die entscheidende technische Frage beginnt jedoch nach der Reparatur: Welche abhängigen Systeme konnten anschließend tatsächlich wieder vorankommen? Bei einem einfachen Erreichbarkeitsfehler könnte die Antwort lauten, dass neue Anfragen nach dessen Behebung wieder funktionieren. Die ausgewerteten Berichte beschreiben für EC2 einen komplizierteren Verlauf. Während eine notwendige Abhängigkeit fehlte, entstand zusätzliche Verwaltungsarbeit. Ihre anschließende Abarbeitung wurde selbst zum Wiederherstellungsproblem.

Die Zeitmarken von ThousandEyes machen sichtbar, warum eine einzige Meldung über die Rückkehr eines Dienstes nicht genügt:

Zeitpunkt am 20. Oktober 2025, jeweils UTC Von ThousandEyes beschriebener Zustand Was daraus nicht folgt
09:25 DNS-Informationen waren wiederhergestellt. Nicht jeder Client musste zu diesem Zeitpunkt bereits wieder eine funktionierende Verbindung haben.
09:25–09:40 Mit dem Ablauf zwischengespeicherter Einträge wurden Endpunkte wieder erfolgreich aufgelöst und Verbindungen hergestellt. Damit war die Bereitstellung nutzbarer neuer EC2-Kapazität noch nicht vollständig nachgewiesen.
Bis 20:50 Neue EC2-Starts scheiterten oder neue Instanzen hatten Konnektivitätsprobleme. Nicht jeder Startversuch muss während des gesamten Zeitraums gescheitert sein.

Quelle der ausgewählten Zeitmarken: ThousandEyes

Zwischen 09:25 und 20:50 liegen rechnerisch 11 Stunden und 25 Minuten. Diese Differenz verbindet eine DNS-Wiederherstellungsmarke mit dem berichteten Ende einer kombinierten Beeinträchtigung von Starts und Konnektivität. Sie misst weder eine durchgehend identische Fehlerquote noch die Ausfallzeit einer bestimmten Anwendung. Auch der Ablauf zwischengespeicherter DNS-Einträge zwischen 09:25 und 09:40 ist ein eigener Übergang, nicht bloß eine andere Schreibweise für vollständige Kundenerholung.

Weshalb die Reparatur weitere Arbeit freisetzte

ThousandEyes berichtet, dass der Droplet Workflow Manager von EC2 während der DynamoDB-Nichtverfügbarkeit notwendige Zustandsprüfungen nicht abschließen konnte. Dadurch wurde die Lease-Verwaltung gestört. Diese Verbindung zwischen Zustandsprüfung und EC2-Steuerung erklärt, warum ein Datenbankproblem über die unmittelbar auf DynamoDB zugreifenden Anwendungen hinauswirken konnte.

Eine Lease bezeichnet in diesem Zusammenhang eine interne, zeitlich begrenzte Verwaltungsbeziehung. Gemeint ist nicht der kommerzielle Mietvertrag eines Kunden für eine virtuelle Maschine. Nach der Erklärung von Dipak Kr das nutzt der Droplet Workflow Manager DynamoDB für Zustandsprüfungen im Zusammenhang mit den physischen Servern, auf denen EC2-Instanzen laufen. Nach der Rückkehr von DynamoDB habe sich so viel Arbeit zur Wiederherstellung dieser Leases angesammelt, dass der Manager überlastet wurde und nicht mehr vorankam. Ingenieure hätten eingehende Arbeit gedrosselt und ausgewählte DWFM-Hosts neu gestartet. Quelle für Mechanismus und Eingriffe: Dipak Kr das

Der Unterschied ist wichtig: Eine behobene Ursache beseitigt nicht automatisch die Arbeit, die während ihrer Wirkung liegen geblieben ist. Im beschriebenen Fall musste das System nicht nur wieder auf eine Datenbank zugreifen können. Es musste einen angesammelten Bestand an Verwaltungsaufgaben bewältigen. Wenn dieser Wiederanlauf das zuständige System überfordert, ist bloße Erreichbarkeit noch kein Beleg für wiederhergestellten Durchsatz.

Die Quellen liefern hier keine belastbaren Zahlen zur Größe dieses Rückstaus, zur Zahl der betroffenen Hosts oder zur Wiederholungsrate von Anfragen. Solche Größen lassen sich aus der berichteten Dauer nicht zurückrechnen. Der nachvollziehbare Befund ist enger: In der Darstellung von Dipak Kr das waren zusätzliche Eingriffe in die internen Verwaltungsprozesse nötig, obwohl die ursprüngliche Abhängigkeit wieder verfügbar war.

Eine gestartete Instanz ist noch keine nutzbare Instanz

Hinzu kam laut demselben Autor ein separates Problem im Network Manager. Netzwerkzustände für neu gestartete Instanzen hätten sich angestaut und seien nicht rechtzeitig verteilt worden. Einige neue Instanzen blieben dadurch ohne Konnektivität oder bestanden Gesundheitsprüfungen nicht. Quelle: Darstellung des Netzwerk-Rückstaus

Das ist eine andere Fertigstellungsbedingung als der erfolgreiche Start einer virtuellen Maschine. Eine Startbestätigung besagt nicht von selbst, dass der erforderliche Netzwerkzustand angekommen ist. Eine erreichbare Instanz wiederum beweist noch nicht, dass die Anwendung ihre Daten lesen, sich authentifizieren und einen repräsentativen Geschäftsvorgang abschließen kann. Aus dem beschriebenen Rückstau folgt auch kein Internet-weiter Routingausfall; die Darstellung betrifft die Bereitstellung des Netzwerkzustands für neue Instanzen.

Gremlin zieht eine weitere Grenze: Die Zuverlässigkeitsanalyse beschreibt bereits vor dem Ereignis gestartete EC2-Instanzen als weiterhin gesund, während Kunden nach der Behebung des DynamoDB-Problems Schwierigkeiten beim Start neuer Instanzen hatten. Fortgesetzter Instanzbetrieb belegt jedoch keine durchgängige Anwendungsverfügbarkeit. Eine laufende Maschine kann Teil einer Anwendung sein, deren andere Abhängigkeiten gestört sind. Quelle und Reichweite der Unterscheidung: Gremlin

Damit ergibt sich kein Widerspruch zwischen überlebender Rechenleistung und beeinträchtigter Wiederherstellung. Beides kann gleichzeitig zutreffen. Vorhandene Instanzen können weiterlaufen, während das System, das Ersatz oder zusätzliche Kapazität bereitstellen soll, noch nicht zuverlässig arbeitet. Für einen Wiederanlaufplan ist diese Unterscheidung entscheidender als die pauschale Frage, ob EC2 insgesamt bereits wieder verfügbar sei.

Was die Quellen tragen — und was offenbleibt

Dieser Rückblick beruht auf drei technischen Sekundärdarstellungen. ThousandEyes liefert die ausgewählten UTC-Zeitmarken und die Verbindung zwischen DynamoDB-Zustandsprüfungen und Lease-Verwaltung. Die auf Medium veröffentlichte Erklärung von Dipak Kr das liefert den detaillierteren Ablauf des Wiederanlaufs und des Netzwerk-Rückstaus. Gremlin liefert die Unterscheidung zwischen bestehenden Instanzen und neuer Bereitstellung. Die hier ausgewerteten Angaben ersetzen weder einen vollständig geprüften AWS-Primärbericht noch eine unabhängige forensische Untersuchung.

Nicht belegt sind damit die Auswirkungen auf jeden Kunden, eine finanzielle Schadenssumme, Aussagen über Datenverlust oder die heutige Wirksamkeit späterer Abhilfen. Ebenso wenig zeigen diese Quellen, dass jede Architektur mit mehreren Verfügbarkeitszonen oder Regionen versagt hätte. Der Artikel beschreibt ein historisches Ereignis und behauptet nicht, dass die damaligen Fehler weiterhin bestehen.

Die begrenzte, aber praktische Konsequenz lautet: Die Reparatur einer Abhängigkeit, der Fortschritt interner Wiederherstellungsarbeit und die erfolgreiche Nutzung neuer Kapazität brauchen unterschiedliche Nachweise. Erst diese Trennung verhindert, dass der erste positive Status zum vorzeitigen Ende einer Störungserklärung wird.