AWS-Störung vom 20. Oktober 2025: Was passiert ist, warum es alle traf – und wie Sie sich gegen Ausfälle und Cyberangriffe wappnen

Estimated reading time: 6 Minuten

Am Montagmorgen, 20.10.2025, legte eine großflächige Störung bei Amazon Web Services (AWS) Teile des Internets lahm. Betroffen waren u. a. Signal, Snapchat, Fortnite/Epic, Atlassian-Dienste, Docker sowie Amazons eigene Angebote wie Alexa/Prime Video. Laut AWS und übereinstimmenden Medienberichten war US-EAST-1 (N. Virginia) der Ausgangspunkt; als Ursache wurden DNS-/Netzwerkprobleme mit Folgestörungen u. a. bei DynamoDB und EC2-Netzwerkpfaden genannt. Gegen Mittag meldete AWS deutliche Erholung, später vollständige Entstörung – Restarbeiten liefen noch an. (heise online)

Auch Drittquellen dokumentierten die Breite des Impact: Live-Ticker und Statusseiten sammelten Ausfälle (z. B. Docker Build Cloud „Full Service Disruption“), und Signal bestätigte öffentlich die Abhängigkeit vom AWS-Ereignis. (Der Guardian)

Was genau geschah – die Kurzchronik

• Ab ca. 09:10 Uhr MESZ (03:11 ET) traten massive Störungen in US-EAST-1 auf; AWS nannte interne Probleme im EC2-Netz (inkl. Komponenten rund um Load Balancer) und DNS-Resolution, mit Kettenreaktionen bei Diensten wie DynamoDB. (The Verge)
• 11:20–12:30 Uhr MESZ: AWS meldete Gegenmaßnahmen, Erholungstendenzen und später die Behebung des DNS-Problems; einzelne Services arbeiteten Backlogs ab (z. B. CloudTrail, Lambda). Heise dokumentierte fortlaufend. (heise online)
• Nachmittag/Abend: Anbieter wie Docker/Atlassian wiesen weiterhin auf Auswirkungen hin; diverse Plattformen berichteten graduelle Normalisierung. (Docker Status)

War es ein Cyberangriff?

Derzeit gibt es keine belastbaren Hinweise auf einen externen Angriff. AWS und seriöse Medien verweisen auf ein internes DNS/Netzwerk-Problem mit nachgelagerten Effekten. Spekulative Zuschreibungen (DDoS, Ransomware, Supply-Chain) lassen sich anhand der vorliegenden Quellen nicht belegen. Wichtig ist: Der Impact kann von außen wie ein Angriff wirken, weil dieselben sichtbaren Symptome auftreten (z. B. Timeouts, API-Errors, Auth-Fehler). (heise online)

Indikatoren, die (hier) gegen einen Angriff sprechen

• Schnelle, gestufte Erholung nach netzwerknahen Fixes spricht für einen internen Fehler statt persistenter, adaptiver Angriffsvektoren. (heise online)
• Konzentration auf Region/Subsysteme (US-EAST-1, DNS/EC2/DynamoDB) statt breit verteilter Kompromittierung. (The Verge)

Fazit: Outage ≠ Angriff. Dennoch sollten Resilienz- und Security-Maßnahmen so ausgelegt sein, dass beideSzenarien (technische Störung und Angriff) abgefedert werden.

Lehren für Architektur & Betrieb: Resilienz gegen Ausfälle und Angriffe

1) Multi-Region vor Multi-Cloud – aber bewusst kombinieren

• Active-Active über mindestens zwei AWS-Regionen (z. B. EU-Central-1 + EU-West-1) mit Region-Failover via Route 53 Health Checks/Failover-Routing, doppelte NAT/Transit-GW-Pfade, regionale Artefakt-Spiegel.
• Service-Auswahl mit Regionalitäts-Bewusstsein: Vermeiden Sie harte Abhängigkeiten von historisch ausfallanfälligen „Hub-Regionen“ (US-EAST-1). Platzieren Sie Kontroll-/Meta-Services (CI/CD, Artefakt-Repos, IAM-Admin-Workloads) außerhalb der Primärregion. (heise online)
• Multi-Cloud selektiv (AWS + Azure/GCP/Cloudflare Workers/Fastly Compute@Edge) für kundenseitige Entry-Points (Edge, DNS, CDN) und kritische Minimalpfade (Auth, Checkout, Statuspage), um „Blast Radius“ zu begrenzen. (WIRED)

2) DNS als Achillesferse behandeln

• Dual-Provider-DNS (z. B. Route 53 + sekundärer DNS-Provider) mit asynchronem Zonen-Sync und separatemResolver-Pfad (on-prem/Edge).
• Client-seitige TTL-Strategie: Kürzere TTLs für kritische Endpunkte, längere für statische Zonen; Split-Horizonfür interne/Extranet-Namespaces.
• Fallback-Hints in Apps (Resolv-Retry, Caching, Happy-Eyeballs-ähnliche Strategien). (WIRED)

3) Datenpfade entkoppeln

• DynamoDB/RDS mit Cross-Region-Replikation bzw. Read-Replicas; PITR aktivieren, Backups außerhalb der Primär-Cloud speichern (objekt-speicherbasiert + WORM).
• Event-Driven Architektur (Queues/Streams) mit Idempotenz, Retry-Budgets und Dead-Letter-Queues, damit kurzzeitige API-Errors nicht zu Datenverlust führen. (Network World)

4) Graceful Degradation & Feature Toggles

• Notfall-Modi: Nur Kerngeschäft (Lesen statt Schreiben, statische Seiten statt SSR, „Offline Basket“, „Read-only Mode“).
• Circuit Breaker/Bulkheads je Downstream, Backpressure und Rate Limits zum Selbstschutz.

5) Observability & „Third-Party Awareness“

• Vendor-unabhängiges Monitoring (Metriken/Logs/Traces) plus externer Blick (RUM, synthetische Checks von anderer Cloud).
• Status-Page-Ingestion (z. B. AWS Health, Drittanbieter), um automatisch Playbooks zu triggern; halten Sie eigene Status-Seite außerhalb des Primär-Stacks. (AWS Health)

6) Security-Härtung gegen echte Angriffe (die sich ähnlich äußern)

• DDoS-Resilienz: Anycast-CDN/Edge-Scrubbing, Multi-Upstream, automatisierte Baseline-Anomalieerkennung, isolierte „Bastion Front Doors“.
• Identity-Blast-Radius begrenzen: Cross-Account-Isolation, Permission Boundaries, kurzlebige STS-Tokens, Break-Glass-Accounts außerhalb der betroffenen Region.
• Supply-Chain: Spiegel-Registries (Container/Packages), Sigstore/Attestierungen, Repro-Builds, „Air-gapped“ Secrets-Backups.
• IR-Playbooks für beide Fälle (Ausfall oder Angriff): GameDays/Chaos inkl. DNS-/Region-Failover-Drills, Recovery-RTO/RPO-Tests.

Konkrete Schutz-Checkliste (kurz & praxisnah)

1. Zwei Regionen aktiv betreiben, Notfall-DNS-Failover testen.
2. Externe Status- und RUM-Checks in anderer Cloud. (AWS Health)
3. Minimal-Plattform für „Read-only / Wartungsmodus“ bereitstellen (statisches Mirror-Site-Bucket + CDN bei Fremd-Provider).
4. Daten: Replikation + Offsite-Backups + Restore-Drills.
5. Edge-Frontdoor (CDN/WAF) cloud-unabhängig aufsetzen; Rate-Limits.
6. Deployment-Pfad (CI/CD, Artefakte) nicht single-homed; alternative Runner/Builder (Docker-Ausfall bedenken). (Docker Status)
7. Runbooks für: DNS kaputt, Region weg, Auth down, Payments down – mit klaren Kontaktketten & Entscheidungsbäumen.
8. Kommunikation: Eigene Status-Seite + Social-Fallback (z. B. Mastodon/X/Bluesky) außerhalb Primär-Cloud. (bsky)

Alternativen & Ergänzungen zur Abhängigkeit von AWS

• Weitere Hyperscaler (Azure, Google Cloud): Eignen sich für kontrollierte Multi-Cloud-Mindestpfade(DNS/Edge/Auth/Status), nicht zwingend „alles doppelt“.
• Edge-Plattformen (Cloudflare/Fastly): Bieten globale Anycast-Edge, Workflows/Workers, KV/Queues – gut für User-Facing Fallbacks und „Static Core“. (WIRED)
• Europäische Provider (OVHcloud, IONOS, Hetzner): Für Souveränitäts-/Compliance-Anforderungen und Warm-Standby von Kernfunktionen.
• Hybrid/On-Prem/Kubernetes: Kritische Systeme (z. B. Identity, Feature-Flags, Artefakt-Repos) außerhalb des Hyperscalers spiegeln, um Vendor-Lock-in-Risiken und gemeinsame Fehlerdomänen zu reduzieren.

Kommunikation & Kundenvertrauen

• Transparenz in Minuten, nicht Stunden: Schnell „Was wir wissen / Was wir tun / Nächste Aktualisierung“ veröffentlichen – auch wenn Ursache noch unklar ist.
• Proaktive Workarounds (DNS Cache flush, alternative Logins, Offline-Funktionen) bereitstellen. AWS empfahl selbst DNS-Cache-Flush bei Restproblemen. (Al Jazeera)

Bottom Line

Diese Störung war – den Quellen nach – kein bestätigter Cyberangriff, sondern ein netzwerknahes/DNS-Problem mit großem „Blast Radius“. Genau deshalb sollten Architekturen so entworfen werden, dass technische Fehler und Angriffegleichermaßen isoliert und überbrückt werden können: mehrere Regionen, DNS-Diversität, entkoppelte Datenpfade, Edge-Fallbacks, unabhängige Observability und geübte Playbooks. Wer das beherzigt, bleibt im Ernstfall online – selbst wenn eine ganze Cloud ins Stolpern gerät. (heise online)

Quellen (Auswahl): Heise-Bericht mit Zeitverlauf; The Verge/Guardian mit Technikdetails und Timeline; Docker/Atlassian Status; Bluesky/X-Posts von Signal-Präsidentin; AWS-Health/-Update; Al Jazeera/NetworkWorld/Wired zu DNS-/DynamoDB-Kausalität und strukturellen Lehren. (heise online)

• Auf der Suche nach Alternativen zu Azure? So finden Sie die richtige Cloud-Plattform für Ihr Unternehmen
• 40 Jahre Amiga – Die „Wow‑Maschine“ im Rückblick
• Digitale Unabhängigkeit: Warum technologische Souveränität jetzt über die Zukunft entscheidet
• Sonnenstürme: Die unsichtbare Gefahr aus dem All für unser digitales Leben
• Der Weg von Exchange zu Microsoft 365 : Eine Zeitlinie