Mehrere Ausfälle bei AWS-Diensten in der Region us-east-1

• In der us-east-1-Region von AWS kam es zu Ausfällen bei diversen Diensten
• Aufgrund dieser Störung erlebten Cloud-Infrastruktur-Nutzer Dienstunterbrechungen
• Verfügbarkeitsprobleme bei wichtigen Diensten wie API Gateway und Lambda wurden gemeldet
• Die Notwendigkeit, Ausweichpfade bereitzustellen und Notfallmaßnahmen zu prüfen, wurde deutlich
• Über das AWS Health Dashboard wurden Echtzeit-Statusinformationen und Updates bereitgestellt

---

AWS-Ausfallübersicht in der Region us-east-1

• Am 21. Oktober 2025 wurden im AWS Health Dashboard mehrere Ausfälle bei Diensten in der Region us-east-1 gemeldet
• Besonders wichtige Dienste wie API Gateway, Lambda und S3 waren betroffen, sodass zahlreiche Kunden zu Ausfällen ihrer Dienste kamen
• Ab dem Auftreten der Störung begann AWS sofort mit der Ursachenanalyse und Wiederherstellungsarbeit
• Bei SaaS-Anbietern, Start-ups und IT-Unternehmen, die von dieser Region abhängen, wurden Serviceverzögerungen und Ausfallzeiten gemeldet
• Ingenieure und IT-Verantwortliche betonten die Notwendigkeit, Notfall-Workarounds einzurichten und eine Multi-Region-Strategie für kritische Dienste zu planen

Auswirkungen und Reaktion

• Die Region us-east-1 gehört zu den Regionen mit dem höchsten Datenverkehr in der globalen Cloud-Infrastruktur, daher sind die Auswirkungen bei einem Ausfall besonders groß
• Bei vielen Kunden traten gleichzeitig Probleme wie Unterbrechungen der Servicebereitstellung, API-Antwortverzögerungen und Datenverarbeitungsstörungen auf
• AWS informierte über das Health Dashboard in Echtzeit und stellte Hilfedokumente sowie Aktualisierungen bereit
• Die IT-Teams der Kunden betrieben Störfall-Monitoring, temporäre Umleitung und Nutzerbenachrichtigungen, um die Auswirkungen zu minimieren

Implikationen für Ingenieure

• Es wurde erneut betont, wie wichtig eine robuste Monitoring-Architektur und ein gutes Störfall-Benachrichtigungssystem sind
• Der Wert einer ausfallsicheren Architektur wurde hervorgehoben, etwa durch Multi-Region-Bereitstellung, automatisierte Notfallreaktionen und Backup-Strategien
• Das AWS Health Dashboard wurde als Werkzeug genutzt, um in Ausfallsituationen schnell Informationen zu erhalten und Entscheidungen zu treffen

Fazit

• Betreiber großer Cloud-Services müssen zwingend Vorkehrungen für mögliche Dienstunterbrechungen treffen
• Bei einem Ausfall rücken eine schnelle Wiederherstellung, transparente Kommunikation und eine effiziente Fähigkeit zur Reaktion auf Infrastrukturprobleme erneut in den Fokus

[GN⁺]

Hacker News-Kommentar

• Heute war wirklich ein interessanter Tag. Seit 3 Uhr morgens war ich in der Incident-Bridge. Das System ist größtenteils wiederhergestellt, aber im Backoffice kämpft noch ein Bereich mit Ressourcenknappheit. Unser größter Fehler war, dass wir trotz Auslegung auf Multi-Region-Betrieb den Failover-Prozess nicht ausführen konnten. Der Grund war, dass das Security-Team uns zu Identity Center migriert hat, das nur in us-east-1 bereitgestellt wurde, wodurch das gesamte Unternehmen vollständig von der AWS-Control-Plane abgeschnitten war. Als wir die Root-Credentials aus dem Vault holten, war das System bereits weitgehend wiederhergestellt. Dieser Vorfall macht noch einmal deutlich, dass ein schwaches Glied die Gesamtrobustheit bestimmt.
  • Es erinnert mich an eine frühere Zeit, als das Google-Rechenzentrum in Paris nach einer Überschwemmung und anschließendem Brand chaotisch war. Wir hatten dort keine Compute-Ressourcen direkt, aber wir liefen in AWS-EU-Rechenzentren; der DNS-Resolver für Google-Services war in Paris gehostet, sodass der Traffic vorrangig dorthin geroutet wurde. Der Workaround war ziemlich interessant. Damals habe ich zuerst gelernt, wie einfach man die auf Kubernetes bereitgestellte /etc/hosts-Datei global ändern kann, und es war dringend erforderlich, das wirklich zu tun. Normalerweise würde man /etc/hosts für so einen Zweck nicht einsetzen, aber als temporärer Patch war es genau die richtige Abstraktion.
  • Mir fällt ein ähnlicher Fall bei Facebook ein, bei dem ein falsches BGP-Update den Zugriff auf den Vault vollständig unmöglich machte. Wenn der Authentifizierungsfluss kreisförmig ist, führt ein DNS-Ausfall dazu, dass man gar nichts mehr machen kann.
  • Am Ende kommt dann der Moment, in dem jemand mit einem Hardware-Token in ein anderes Rechenzentrum fliegt, um ein zentrales Gerät zurückzusetzen, das die globalen Systeme wieder in Gang bringt.
  • Es wurde gesagt, dass Identity Center nur in us-east-1 liegt. Ich frage mich, ob man es in mehreren Regionen betreiben kann. Bei meiner letzten Prüfung war es nur in einer Region nutzbar, und für eine Verlagerung musste es zunächst gelöscht werden.
  • Zu starke Sicherheitsbarrieren sorgen eher dafür, dass man nicht handeln kann. Ich frage mich, ob das Security-Team für diesen Vorfall zur Verantwortung gezogen wird. Dieser Vorfall wird voraussichtlich alle kommenden Projekte verlangsamen. Das Security-Team ist diesen Bereich zu vorschnell angegangen. Die Frage ist: Wer überwacht eigentlich den Überwacher?
• Es scheint, als hielte der große Ausfall weiter an. Der Zustand ist schlechter als vor vier Stunden. Ich bin Dateningenieur, und Redshift sowie Airflow (AWS verwalteter Service) sind komplett im Eimer.
  • Der Ausfall zieht sich schon recht lange hin. Ich frage mich, wie viele Neunen dabei schon weg sind. 365 Tage * 24 Stunden * 0,0001 ergibt ungefähr 8 Stunden; damit sind bereits 99,99 % Verfügbarkeit verloren.
  • Ich verstehe nicht, warum so viele Unternehmen noch immer us-east-1 verwenden. Bei der Häufigkeit von Ausfällen ist es bei weitem das Schlechteste. Unsere Firma hat vor Jahren entschieden, us-east-1 zu meiden und nur andere Regionen zu nutzen. Natürlich hilft das nicht immer, wenn ein Dienst als „global“ bezeichnet wird und in der Praxis oft praktisch us-east-1 bedeutet.
  • Der Control-Plane-Call create-function von Lambda scheitert weiterhin mit InternalError. Andere Services (Lambda, SNS, SQS, EFS, EBS, CloudFront) sind wiederhergestellt. Ich forsche im Rahmen meiner Masterarbeit zur Cloud-Verfügbarkeit und dokumentiere gerade die Ausfallzeitlinie und die Auswirkungen in mehreren AWS-Testkonten. Analysebeitrag
  • Down Detector zeigt weiterhin gravierende AWS-Ausfälle. Amazon selbst sagt, man stelle die Services wieder her, aber in Wirklichkeit funktioniert die Produktsuche bei Amazon.com nicht. AWS-Health-Seite
  • Laut Down Detector waren um 12:52 AM PT (3:53 ET) 5.755 AWS-Fehlerberichte, um 4:22 AM PT (7:22 ET) sank die Zahl auf 1.190 und um 9:32 AM PT (12:32 ET) stieg sie wieder auf 9.230. Dass die Berichte zunehmen, wenn die Westküste der USA wieder „wach“ wird, wäre denkbar; es wirkt aber so, als hätte AWS die Situation noch nicht wirklich unter Kontrolle.
• Diese Störung trifft mich sogar im Alltag direkt. Ich wollte in der Hudson Yards Whole Foods in New York eine Schokoriegel-Tafel kaufen, aber der Prime-Rabatt wurde nicht angewendet. Also habe ich nichts gekauft und mein Schokoladenbestand ist jetzt ziemlich niedrig.
  • Heute Morgen hat auch der Befehl „alexa, koche Kaffee“ nicht funktioniert. Das hat mich ganz aus der Bahn geworfen.
  • Zum Mittagessen habe ich bei Hot Bar Lebensmittel aufgenommen und versucht, mit der Selbstbedienung auszuchecken, aber ich habe lange überlegt, warum der Whole Foods-Barcode nicht funktionierte. Erst nach etwa 20 Sekunden wurde mir klar, dass es an der Störung lag.
  • Schön, dass dieser interessante Fall geteilt wurde. Gleichzeitig interessiert es mich, wie es den Leuten im Amazon-Go-Laden ging, als der AWS-Ausfall passierte.
• Heute habe ich ein Meeting mit meinem AWS-Kontoverantwortlichen. Ich werde darlegen, dass wir künftig von einem „All in on AWS“ wegkommen und Workloads verteilen wollen. Der Hauptgrund ist, dass die Innovationsgeschwindigkeit der Kernservices nachlässt und AWS im AI-Bereich gegenüber der Konkurrenz zu weit zurückfällt. Das AWS-Team argumentiert immer wieder gegen Workload-Verteilung mit dem Verweis auf angebliche AWS-Superstabilität. Auf dieses Meeting bin ich gespannt.
  • Egal ob AWS, Cloudflare, Google Cloud, Akismet oder wer auch immer: Irgendwann hat jeder einen Ausfall. Bei jedem solchen Fall denkt man über In-House-Hosting nach. Am Ende betreiben wir es wieder selbst. Die Ergebnisse sind ähnlich, also ist der zusätzliche Aufwand oft nicht sinnvoll.
  • Als Andy Jassy zuletzt darauf hingewiesen wurde, dass AWS in Sachen Innovation hinterherhinkt, wurde als Gegenargument Stabilität, Zuverlässigkeit und Beständigkeit angeführt. Angesichts der aktuellen Lage wirkt diese Ausrede jedoch nicht mehr.
  • Abgesehen von us-east-1 laufen die übrigen Regionen ziemlich stabil. Unsere Firma hat fast alles ebenfalls in eu-west-1, und es läuft ohne Zwischenfälle.
  • AWS ist langfristig im Rückzug. Der Eindruck ist, dass man im Wesentlichen nur noch den Status quo der bestehenden Services hält. Innovativ denkende Mitarbeiter sind durch interne Bürokratie und Leistungsdruck erstickt, weshalb AWS auch im KI-Bereich hinterherhinkt.
  • Die Behauptung, dass AWS besonders stabil sei, war nie die Wahrheit. Ich hatte schon einmal Multi-Cloud-Monitoring mit mehreren Clouds und dedizierten Servern eingerichtet, damit ich klar sehen konnte, wo ein Problem zuerst auftritt. Die Ergebnisse zeigten dabei, dass AWS nicht immer auf Platz eins lag; sie stimmten fast exakt mit den Daten von netcraft.com überein.
  • Auch heute wird die Premier League die VAR- und Auto-Offside-Entscheidungen nur eingeschränkt über AWS betreiben. Wirklich seltsame Zeiten. BBC-Link
  • Man hat ein winziges positives Element in einem Cloud-Ausfall gespürt.
• Wenn us-east-1 eure Hauptregion ist, ist bei einem Ausfall alles gleichzeitig betroffen, niemand leidet allein. In anderen US-Regionen kann man sich dieses Privileg nicht aneignen.
  • Als wir von einem klassischen Rechenzentrum auf AWS gewechselt haben, war ein unerwarteter Vorteil, dass die Kunden bei einem Komplettausfall einer ganzen Region deutlich verständnisvoller werden. Wenn alle gleichzeitig Probleme haben, wird es eher hingenommen.
  • Manchmal muss jeder einmal technische Downtime erleben.
  • Okay, dann stellen wir alle unsere Infrastruktur auf US-East-1.
  • In Unternehmensumgebungen dauert es überraschend lange, zu verstehen, was wirklich wichtig ist. In Wahrheit ist nicht die Verfügbarkeit entscheidend, sondern eine Architektur, die eine Schuldzuweisung ermöglicht. Wenn durch einen Mitarbeiterfehler 5 Minuten im Jahr ausfallen, ist das eine CTO-Verantwortung; wenn AWS fünf Stunden ausfällt, ist es für alle „unvermeidbar“. Bei AWS, Crowdstrike usw. geht es letztlich nicht um harte Systeme, Kosten-Nutzen oder Risikomanagement, sondern darum, dass alle zur gleichen Zeit betroffen sind. Es ist unangenehm, aber real. Für jemanden, der gerne gut funktionierende Technik sieht, ist das frustrierend.
  • Die Tokyo-Region läuft gerade gut; allerdings funktionieren einige Funktionen, wie die Konsolenanmeldung, noch nicht.
• „Unsere Untersuchungen deuten darauf hin, dass ein DNS-Auflösungsproblem am DynamoDB API-Endpunkt in US-EAST-1 beteiligt ist. Wir haben parallel gearbeitet, um die Wiederherstellung zu beschleunigen.“ wiederholt sich das Muster: wieder DNS.
  • Ob der Ausfall diesmal wirklich ein DNS-Lookup-Problem war oder ein internes Konfigurations-/Datenspeicherproblem des DNS-Servers, wäre interessant zu wissen. Letzteres ist wahrscheinlicher.
  • In späteren Ausfallberichten wurde als Ursache ein Fehler im Network Load Balancer genannt. DNS wäre dann eher ein Symptom der Wurzelursache. DNS hat möglicherweise die Health Checks beschädigt, aber ich denke, die eigentliche Ursache liegt im Netzwerk.
  • Es ist möglich, dass BGP ein DNS-Problem maskiert hat.
  • Die Ursache liegt immer in us-east-1.
  • Auch wenn es kein DNS-Problem ist, endet alles trotzdem bei DNS.
• Es funktioniert, wie für Widerstandsfähigkeit geplant. Wir haben mit CloudFront Multi-Region Static Origins für statische Sites eingerichtet, dadurch hatte dieser Ausfall keinen Einfluss. Die Control Plane ist auch nativ multi-region und hängt zwar von mehreren Services ab, hält aber die Verfügbarkeit. Jede Region läuft unabhängig; Daten werden repliziert, und selbst wenn die Replikation nach us-east-1 ausfällt, gibt es keine Auswirkungen. Der Service ist als Multi-Region-Architektur angelegt und führt Failover auf mehreren Ebenen (DNS, Routing, Zielauswahl) durch. Natürlich ist dieser Ansatz nicht perfekt und hat viele mögliche Ausfallpunkte, aber diesmal hat er funktioniert, und das ist ein gutes Gefühl. Meine Lösung ist selbstverständlich keine Raketenforschung und nicht teuer, sondern bloß ein anderer, weniger standardmäßiger Ansatz. Wenn Fragen bestehen, könnt ihr sie jederzeit stellen.
  • Dass man mit CloudFront Multi-Region Static Origins für statische Sites absichert, sollte in 2025 Standard sein, trotzdem bleibt es hierzulande noch lobenswert.
  • Ich würde gerne wissen, ob ihr ein active/active-Setup nutzt und wie euer Daten-Stack aufgebaut ist. Gerade dieser Teil erscheint mir besonders anspruchsvoll.
  • Wie habt ihr Fehlertoleranz für Schlüssel und Zertifikate implementiert?
• Ein großes Problem ist, dass IAM/Authentifizierungssysteme aufgrund von Überlastung oder Ausfall zu Kaskadeneffekten führen. Es wird gesagt, DynamoDB sei Ursache; ich frage mich, ob IAM intern ebenfalls auf Dynamo aufsetzt. In großen, komplexen Systemen sind Abhängigkeiten schnell verwickelt, und Auth/IAM hat das Potenzial eines globalen Single-Point-of-Failure zu werden, daher möchte man solche Abhängigkeiten minimieren. Aber Skalierbarkeit, Konsistenz und mehr sind ebenfalls wichtig, deshalb nutzt man erprobte DBs. Das führt am Ende wieder zu komplexeren Abhängigkeiten und zu einem komplexen Bootstrapping-Prozess bei Ausfällen. Ich frage mich, wie ihr das handhabt.
  • Vor etwa 2017 gab es einen Großausfall bei DynamoDB. EC2 speicherte die Serverliste in DynamoDB, und als DynamoDB ausfiel, fiel auch EC2 aus. Da DynamoDB auf EC2 lief, war es unmöglich, neue EC2-Instanzen hochzufahren, um die Wiederherstellung zu starten. Daher mussten wir mehrere Tage lang manuell Instanzen hochziehen. Danach habe ich mich bemüht, Abhängigkeiten zwischen Tier-1-Systemen wie S3, DynamoDB und EC2 so gut wie möglich zu entkoppeln. Vollständige Unverwundbarkeit ist natürlich schwer.
  • Viele AWS-Kunden nutzen falsche Retry-Strategien und überlasten dadurch zusätzliche Systeme, wenn eine Komponente ausfällt. Ein DynamoDB-Ausfall kann also zu Überlastung bei IAM führen.
  • Bei Amazon gibt es intern offenbar eine eigene KV-Store-Plattform namens Dynamo, die nicht mit DynamoDB identisch ist. Daher könnte die Ursache im DNS-Routing oder bei der Node-Bereitstellung liegen. Diese Themen tauchen in Post-Mortems großer Ausfälle regelmäßig auf.
  • Als ich bei AWS gearbeitet habe, war IAM nicht abhängig von Dynamo. Ob sich das inzwischen geändert hat, weiß ich nicht. Der Einfluss eines großflächigen Netzwerkproblems erscheint wahrscheinlicher. Weil Auth/IAM kein globales Single-Point-of-Entry werden darf, versucht man, Abhängigkeiten zu minimieren. IAM besitzt regionenspezifische Read-Only-Caches, und AWS SigV4 ist ebenfalls darauf ausgelegt. (Referenzdokument)
  • Interessanterweise hat die jüngste GCP-Störung eine ähnliche Ursache.
• AWS meldete um 3:03 AM PT die Wiederherstellung, aber die Lage wurde tatsächlich schlechter. Um 9:13 AM PT hieß es erneut, man sei noch in der Ursachenanalyse. Es wirkt beunruhigend, dass AWS die genaue Ursache offenbar nicht kennt.
  • Diese Woche ist Diwali, das größte indische Fest, sodass viele indische Ingenieure im Urlaub sind und das vermutlich den Verlauf verlängert hat. Wirklich unglücklich.