Globaler Ausfall von AWS: Technische Nachbetrachtung, Branchenstandards und Schlussfolgerungen für die IT-Architektur

AWS-Ausfall vom 20. Oktober 2025 – Analyse der größten Cloud-Infrastruktur-Katastrophe dieses Jahres und Schlussfolgerungen für die IT-Architektur

Am 20. Oktober 2025 wurde die Welt daran erinnert, wie großen Teil des Internets eine einzige Säule trägt: Region US‑EAST‑1 der Amazon Web Services-Plattform. Seit den frühen Morgenstunden Ostküstenzeit (ca. 03:11 ET) meldete AWS erhöhte Fehler und Verzögerungen in vielen Services, und als Quelle des Problems stellten sich DNS-Auflösungsfehler für DynamoDB-Service-API-Endpunkte in der Region N. Virginia heraus. Nach einigen Stunden verkündete AWS eine „vollständige Milderung" des DNS-Problems, jedoch sekundäre Störungen (u.a. in EC2 zuständig für Instanz-Starts und Network Load Balancer Health Checks) - verlängerten die Auswirkungen des Vorfalls bis in die Nachmittagsstunden.

Das Ausmaß der Auswirkungen war total: nicht verfügbar oder stark eingeschränkt waren Services solcher Giganten wie u.a. Snapchat, Reddit, Zoom, Signal, Fortnite, Venmo, und zeitweise auch Amazon.com, Prime Video, Alexa und Ring. Im Höhepunkt wurden Millionen von Meldungen in DownDetector verzeichnet, und Analysten sprachen von Schäden in Milliardenhöhe.

Wie kam es zu einem der größten Ausfälle in der Geschichte des öffentlichen Internets? Im Folgenden präsentieren wir den technischen Ereignisverlauf, Ursache-Wirkungs-Analyse, Überblick über analogische Ausfälle in der Public Cloud und - was am wichtigsten ist - praktische architektonische Schlussfolgerungen aus der Perspektive von Infrastruktur- und Netzwerk-Ingenieuren.

AWS identifizierte „erhöhte Fehler" in DynamoDB resultierend aus DNS-Auflösungsproblemen zu API-Endpunkten in der Region N. Virginia. Wenn DNS einen Namen nicht in eine IP-Adresse übersetzen kann, behandeln Anwendungen den Service als nicht verfügbar, obwohl die Server selbst gesund sein können - das ist klassisches „Fail-Open auf DNS", das zu beobachtbarer Nichtverfügbarkeit der Abhängigkeitskette führt.

Die unterbrochene Konnektivität zu DynamoDB betraf eine Reihe abhängiger Services (IAM-Updates, Global Tables, Lambda-Elemente, CloudTrail), und parallel wurden EC2-Subsystem zuständig für Instanz-Starts sowie Network Load Balancer Health-Checks degradiert. Dies erschwerte reaktive Auto-Skalierung von Anwendungen und verlängerte die Wiederherstellung. AWS drosselte bewusst (Throttling) einige Operationen (z.B. EC2-Starts, SQS→Lambda-Mappings), um Überlastung während der „Entwirr"-Phase ausstehender Anfragen zu vermeiden.

AWS wendete erste Abhilfemaßnahmen nach ca. 2 Stunden an und meldete „signifikante Erholungsanzeichen", und um 02:24 PDT (11:24 CET) verkündete es vollständige Milderung des DNS-Fehlers. Die vollständige Rückkehr der Services zum normalen Betrieb bestätigte AWS um 15:01 PT (00:01 CET des nächsten Tages), wobei einige Services („Config", „Redshift", „Connect") noch ausstehende Nachrichten abarbeiteten.

Region US‑EAST‑1 ist historisch die größte und älteste AWS-Region, die die Rolle des „Nervs" für viele Control-Plane-Funktionen globaler Natur spielt. Ein Fehler in der Namensschicht (DNS) für eine kritische Komponente (DynamoDB API) trifft daher nicht nur lokale Workloads, sondern auch globale Verwaltungspfade, was den Einfluss auf Services in anderen Regionen erklärt.

• AWS, US‑EAST‑1 – 2017/2021/2023/2025: Region Virginia wird manchmal zur „Achillesferse" des globalen Ökosystems aufgrund der Konzentration von Services und Control-Plane-Abhängigkeiten; der diesjährige Ausfall bestätigte dies erneut.
• Akamai, 2021 – DNS/Edge: Fehler beim DNS/CDN-Anbieter verursachte globale Unterbrechungen der größten Services - verwandte Dynamik von Single Control Point, Massive Blast Radius.
  Microsoft Azure – DNS- und Konfigurationsvorfälle: In der Vergangenheit verzeichnete Azure Ausfälle im Zusammenhang mit DNS und BGP, was unterstreicht, dass kein Hyperscaler gegen Fehler in der Kontrollschicht immun ist.
• CrowdStrike, 2024 (anderer Charakter): Obwohl das keine IaaS-Cloud ist, zeigte das globale „Single-Update", wie Zentralisierung und Abhängigkeit von Lieferketten die Wirtschaft destabilisieren können.

Schlussfolgerung: Die heutige Public Cloud bietet hervorragende Verfügbarkeit, aber Vorfälle – wenn sie auftreten - haben enormen Wirkungsradius aufgrund der Verkehrskonzentration und Abhängigkeiten. Experten haben übrigens einen eigenen Begriff dafür geprägt und bezeichnen diese gefährliche Situation als Concentration Risk.

Das Tempo des Lastenwachstums (AI/LLM, intensiver Edge, Explosion neuer DCs in Data Center Alley) zusammen mit der Komplexität operationeller Änderungen vergrößert die Risiko-Oberfläche für Konfigurationsfehler und Staus in der Control-Plane. Das bedeutet nicht eine Lawine von Ausfällen jede Woche, aber das Risiko „seltener, aber großer" Ereignisse bleibt bestehen, und einige Analysten weisen darauf hin, dass es mit der raschen Skalierung von AI/Accelerators steigen könnte. Daher ist die richtige Antwort Resilienz-Engineering auf Kundenseite (nicht nur Vertrauen auf Provider-SLA).

1. Multi-Regionalität mit verteilter Unabhängigkeit
   Allein die Verteilung auf AZs in US‑EAST‑1 reicht nicht, wenn die Abhängigkeit die Control-Plane oder globale Services dieses Bereichs betrifft. Benötigt wird eine zweite primäre Region mit unabhängigem Daten-/Geheimnis-Set, separaten CI/CD-Pfaden und routbarer DNS/Traffic-Manager-Änderung auf Organisationsebene.
2. Warm Standby / Active-Active zwischen Clouds (Multi-Cloud) - wo gerechtfertigt
   In kritischen Flows (Autorisierung, Warenkorb, Zahlungen, Schlüssel-APIs) ist oft ein aktiver zweiter Pfad in einer anderen Cloud oder – am besten - On-Prem gerechtfertigt, um Concentration Risk zu eliminieren. Kosten und Komplexität steigen - aber ebenso steigt der Wert von RTO (Recovery Time Objective) und RPO (Recovery Point Objective).
3. Resiliente Muster im Client: Exponential Backoff, Circuit Breakers, DNS-Caching mit kurzem TTL und „Fail-Closed"
   Viele sekundäre Auswirkungen resultierten aus Retry-Kaskaden und Staus. Gut entworfene Limits, Error Budgets und Backpressure begrenzen die Welle sekundärer Ausfälle.

In unserer Analyse schlagen wir keine „Flucht aus der Cloud" vor. Wir schlagen einen bewussten Mix vor: kritische Komponenten und stabile, vorhersagbare Lasten können in eigener Infrastruktur gehalten werden - als zweiter Pfad oder erste Wahl - um Concentration Risk zu reduzieren und TCO im 3-5 Jahres-Horizont zu senken.

Skalierbarkeit nach oben und unten – zu Ihren Bedingungen
In der Cloud ist Skalierung „nach oben" trivial - „nach unten" wird oft durch Commitments, Reservierungen und operative Gebühren erschwert. On-Prem ermöglicht flexibles „Right-Sizing" von Clustern (z.B. Power-Save, Node-Hibernation, elastische GPU/CPU-Pools), ohne Strafkosten für De-Provisionierung. Das ist kritisch für Saisonalität (Retail, Media, Events) und für ML-Workloads nach Modelltraining. (Mechanismisch: HCI, vSphere/KVM, Power-Profile-Automatisierung, Bare-Metal-Pool).

Sicherheit und Datensouveränität
Für PII-, medizinische, Finanz- oder IP-Daten vereinfacht lokale Kontrolle der Trust-Domain (eigenes KMS/HSM, Netzwerksegmentierung, keine Management-Plane-Teilung) Compliance und Trust-Chain-Inspektion — ohne implizite Regions-/Control-Plane-Abhängigkeiten. Der AWS-Vorfall zeigte, dass globale Control-Plane eine gemeinsame Abhängigkeit vieler Services sein kann.

Niedrigere Gesamtkosten (TCO) für vorhersagbare Lasten
Bei stabiler, hoher und vorhersagbarer Nutzung (z.B. ERP, DWH mit Nachtzyklus, Render-Farmen, Edge-Inference), gewinnen oft Kapitalkosten + Abschreibung + Energie + Support gegen kontinuierliches Abonnement für verwaltete Services und Transfer. Zusätzlich eliminieren wir „Steuern" für Egress und einige verwaltete Komponenten.

Operationeller Komfort und Vorhersagbarkeit
„Eigentum" der Control-Plane eliminiert eine bestimmte Risikoklasse: zentrale Provider-Ausfälle stoppen nicht Logistik, CI/CD oder Auto-Skalierungsmechanismen - weil keine Cloud-übergreifenden Abhängigkeiten in kritischen Pfaden bestehen. Der Vorfall vom 20.10 zeigte deutlich, dass ein solcher Ansatz unempfindlich gegen solche Ausfälle ist und ein Unternehmen mit eigener Infrastruktur zu den wenigen wird, die ununterbrochen ihren Wert und ihre Services liefern, wenn andere damit Probleme haben. Und – ohne jegliche Möglichkeit, die entstandene Situation zu beeinflussen - warten sie auf die Reparatur des Ausfalls seitens des Providers.

Cloud-Integration zu Ihren Bedingungen
Nichts hindert daran zu hybridisieren: Burst in die Cloud bei Spitzen, S3-kompatible On-Prem-Objekte als Origin of Truth, Cloud als DR (oder umgekehrt). Der Schlüssel ist Traffic-Design (Anycast/DNS/GLB) und Datenasymmetrie (z.B. Read-Heavy-Offload zu CDN/Cloud, Write-Primary lokal).

Wichtig ist jedoch zu bedenken, dass On-Prem operative Disziplin (Monitoring, Capacity Planning, Hardware-Lifecycle) erfordert. Im Gegenzug bietet es jedoch Kostenpredictability und Concentration Risk-Reduktion, das sich gerade in AWS materialisiert hat.

Falls Sie die Einbeziehung eigener Infrastruktur in die Resilienz-Strategie (oder deren Modernisierung) erwägen, entwirft, liefert und startet das Hardware Direct-Team physische Server-Architektur. Gerne bereiten wir Referenzarchitektur und TCO-Modell für spezifische Lastprofile vor - so dass Cloud-Komfort mit Kontrolle und Resilienz der eigenen Umgebung verbunden wird.