AWS: Störung bei US-EAST-1 Load Balancern löst Ausfälle im gesamten Internet aus

Unternehmen und Produkt

Amazon Web Services (AWS) ist der größte Public-Cloud-Anbieter (nach Marktanteil). 30 bis 31 % der weltweiten Ausgaben für Cloud-Infrastruktur gingen 2024 an AWS, noch vor Microsoft Azure und Google Cloud. Diese Größenordnung macht AWS zu einem unverzichtbaren Dienstleister für die Rechen-, Speicher- und Netzwerkressourcen des gesamten Internets.

‍

AWS berichtet von „über 1.000.000 aktiven Kunden pro Monat“ und beschreibt seine Community regelmäßig als „Millionen aktiver Kunden“, bestehend aus Startups, Großunternehmen und dem öffentlichen Sektor. Zu den bekannten Nutzern des Dienstes zählen Netflix, BMW, Pfizer und Canva; das AWS Partner Network umfasst zehntausende Partner, die Services erweitern und integrieren.

‍

Aus wirtschaftlicher Sicht ist AWS eines der weltweit größten IT-Unternehmen im Enterprise-Segment. Im zweiten Quartal 2025 erzielte AWS 30,9 Mrd. US-Dollar Umsatz und 10,2 Mrd. US-Dollar operatives Ergebnis – ein Beleg dafür, wie zentral die Plattform für moderne digitale Services geworden ist – von E-Commerce-Zahlungen und Banking-APIs bis hin zu Media-Streaming und KI-Workloads.

‍

Auf technischer Seite werden die Kernbausteine von AWS – Amazon EC2, S3, EBS, RDS/Aurora, DynamoDB, Lambda, SQS/SNS, API Gateway, Route 53 und Elastic Load Balancing – durch Edge-Networking und ein privates Backbone mit über 6 Mio. km Glasfaser ergänzt. Diese Kombination ermöglicht globale Low-Latency-Apps, resiliente Multi-AZ-Designs und schnelles Hochskalieren bei Traffic-Spitzen.

‍

Die Bedeutung von AWS ist für diesen Incident relevant, weil so viele digitale Services auf AWS konzentriert sind (oft in wenigen Regionen wie US-EAST-1). Störungen wirken sich daher gleichzeitig auf Finanzen, Gaming, Handel, Medien, Gesundheitswesen und Behörden aus. Die Größe der Plattform, die Anzahl der Kunden und ihr Ökosystem bedeuten, dass ein Ausfall kein auf einen Anbieter beschränktes Problem ist – sondern ein systemisches Internet-Ereignis.

Was war passiert?

Am 20. Oktober 2025 erlebte AWS einen bedeutenden, mehrere Services betreffenden Ausfall, hauptsächlich in US-EAST-1 (N. Virginia). Der Incident verursachte erhöhte Fehlerraten und Latenzen bei Load Balancern und abhängigen Diensten. Dies führte zu Fehlern bei der DNS-Auflösung und Servicefehlern bei Kunden. AWS führte den Incident später auf eine Fehlfunktion im Health-Monitoring-Subsystem für Network Load Balancer (NLB) innerhalb des internen EC2-Netzwerks zurück; mehrere Medien berichteten zudem über Nebeneffekte bei der DNS-Resolution.

Timeline (Europa/Berlin)

• Start (erste weitreichende Auswirkungen): 09:11 CEST, 20. Oktober – die Störung beginnt in US-EAST-1, äußert sich als DNS/ELB-Fehler und API-Fehlfunktionen.
• Erste AWS-Bestätigung: früher Morgen CEST über das AWS Health Dashboard mit dem Hinweis auf erhöhte Fehlerraten/Latenzen in US-EAST-1. (Public Health ist AWS’ autoritativer Kanal für Service-Incidents.) TTD ca. 0 – 10 min.
• Teilweise Behebung: 12:35 CEST, 20. Oktober – AWS meldet, dass das zugrunde liegende Problem behoben wurde; die Wiederherstellung der betroffenen Services erfolgt nach und nach. MTTM ca. 3 h 24 min.
• Nachwirkungen: In Teilen der Flotte kam es am Nachmittag/Abend weiterhin zu Verzögerungen bei der Nachrichtenverarbeitung, bzw. zu Rückständen.
• Vollständige Wiederherstellung: 00:01 CEST, 21. Oktober – AWS teilt mit, dass alle Systeme betriebsbereit sind und sich die Services stetig normalisieren. TTR (bis „full green“) ca. 14 h 50 min.

Wer war betroffen?

Tausende Organisationen und beliebte Apps, darunter Snapchat, Reddit, Fortnite/Epic Games, Zoom, Venmo/Coinbase/Robinhood, Amazon-Produkte Alexa und Ring sowie Teile des Amazon-Einzelhandelsgeschäfts waren von den Störungen betroffen.

‍

Britische Regierungsseiten (z. B. HMRC) und Banken (Lloyds/Halifax) verzeichneten ebenfalls Störungen. Die Auswirkungen umfassten Consumer-Apps, Finanzwesen, Bildung und E-Commerce.

So reagierte AWS 

AWS dämmte den Incident ein, indem die Teams eine fehlerhafte Komponente des Load-Balancer-Health-Monitorings in US-EAST-1 isolierten und korrigierten, während DNS- und Workload-Routing-Mitigations angewendet wurden, um Service-Discovery und API-Calls zu stabilisieren. Für die Wiederherstellung priorisierten die Teams die Reparatur zentraler Control-Plane-Pfade (Instanzstarts, Lambda-Aufrufe, SQS-Polling) und bauten Backlogs ab, um verzögerte Verarbeitung zu beseitigen. Nach dem Incident bestätigte AWS die Rückkehr zum Normalbetrieb und verwies auf einige verbleibende Lags bei der Nachrichtenverarbeitung während der Endphase der Erholung.

So kommunizierte AWS 

Während des Ausfalls nutzte AWS das AWS Service Health Dashboard als primären Kommunikationskanal und veröffentlichte regionsspezifische Updates, die den Fokus auf US-EAST-1 und die serviceübergreifenden Auswirkungen betonten. Parallel dazu veröffentlichten große Medienunternehmen – insbesondere Reuters und The Guardian – wichtige Details zu Ursache, Auswirkungen und Fortschritten bei der Wiederherstellung, wodurch Kunden und Stakeholder, die keinen Zugang zur Plattform hatten, besser über die Situation auf dem Laufenden waren.

Wichtigste Learnings für andere Unternehmen

• Auf regionalen Blast-Radius auslegen. US-EAST-1 als eigenständige Failure Domain verwenden. Multi-Region Active/Active für kundenseitige Endpunkte verwenden; Failover über DNS und zustandsbehaftete Speicher mit Replikation der Datenebene und konfliktsensitivem Design.
• Von den DNS/ELB-Annahmen des Anbieters entkoppeln. Bedingtes DNS-Failover, unabhängige Zustandsprüfungen und clientseitige Timeouts und Retries hinzufügen, um eine enge Kopplung an die Steuerungsebene einer Region zu vermeiden.
• Backpressure + graceful Degradation. Circuit Breaker, Queue-Backpressure sowie Read-Only/Lite-Modi implementieren, damit Kernfunktionen verfügbar bleiben, während nicht-kritische Features Last abgeben. (Verzögerte Nachrichten waren ein großes Problem.)
• Status-Ingestion & Automatisierung. Programmgesteuerte Erfassung von AWS Health-Ereignissen über EventBridge; automatisches Umschalten von Feature-Flags, Skalierung der Failover-Kapazität und Vorwärmen alternativer Regionen, wenn das AWS Service Health Dashboard ELB-/DNS-Vorfälle meldet.
• Runbooks, die einen teilweisen Verlust der Steuerungsebene voraussetzen. Drills für EC2/Lambda-Startfehler, SQS-Lags und DNS-Resolution-Fehler üben; DNS-Einträge und Datenverkehrsrichtlinien für Failover im Voraus berechnen.
• Kommunikation. Eine eigenständige Multi-Cloud-Statusseite und Kunden-Kommunikations-Makros für Cloud-Provider-Incidents pflegen; während großer Events alle 20 bis 30 Minuten aussagekräftige Updates veröffentlichen.

Kurzfassung

Ein bedeutender Incident bei AWS in der Region US-EAST-1 löste vom 20. bis 21. Oktober globale Störungen aus. Er störte bzw. legte Tausende von Apps und Websites aus den Bereichen Social, Finance, Gaming, Behörden, Retail und mehr lahm. Die Störung begann um ca. 09:11 CEST und wurde erst um 00:01 CEST als vollständig „grün“ erklärt (mit teilweiser Entlastung um 12:35 CEST). Der Ausfall beruhte auf einem Fehler im Load-Balancer-Health-Monitoring von EC2, der in DNS- und Service-Discovery-Instabilität mündete. AWS setzte Mitigations um, stellte zentrale Control-Plane-Pfade wieder her und baute Backlogs ab, um Services wiederherzustellen.

‍

Die Bedeutung des Vorfalls kann kaum überschätzt werden: Da sich so viele kritische digitale Services auf AWS – oft verankert in US-EAST-1 – konzentrieren, wurde ein regionaler Ausfall zu einem internetweiten Problem. Das legt ein systemisches Konzentrationsrisiko offen und zeigt die operative Notwendigkeit von Multi-Region- und Provider-agnostischer Resilienz.

Wie ilert helfen kann

Damit kritische Alarmierungen auch dann zugestellt werden, wenn ein Anbieter Probleme hat, ist ilert von Haus aus multi-sourced. Wir arbeiten mit mehreren Telekom-Providern – Twilio, Vonage und MessageBird – zusammen, sodass SMS und Sprachanrufe über alternative Routen weiterlaufen, falls ein einzelner Anbieter eine Störung erlebt. Diese Redundanz hilft sicherzustellen, dass Bereitschaftsteams Benachrichtigungen zum richtigen Zeitpunkt erhalten. Hier sind weitere Punkte, wie ilert Ihnen in Zeiten solcher Major Incidents helfen kann:

‍

• Automatisierte Cloud-Signale: Importieren Sie AWS Health-Ereignisse in ilert, um Alarmierungen mit Kontext anzureichern und automatisch Incidents zu öffnen.
• Multi-Region-Readiness: Nutzen Sie ilerts Routing-Regeln und Dienstpläne, um die richtigen Teams (SRE, Networking, App-Owner) zu alarmieren, sobald eine ELB- oder DNS-Degradation erkannt wird.
• Kommunikation: Veröffentlichen Sie regelmäßig Status-Updates und versenden Sie Benachrichtigungen an Kunden direkt aus ilert – automatisiert und schnell dank KI-Unterstützung, während Ihre Engineers die Backlogs abarbeiten.
• Postmortems und Analytics: Erstellen Sie strukturierte Reviews, verfolgen Sie MTTR und identifizieren Sie wiederkehrende Schwachstellen (z. B. Service Discovery, Control-Plane-Abhängigkeiten), um konkrete Verbesserungen voranzutreiben.