AWS Outage on Oct 20: DNS issue in us‑east‑1 knocked major services offline — now resolved

A severe Amazon Web Services (AWS) incident on October 20 disrupted a long list of apps and sites, from Venmo, Snapchat and Canva to Fortnite and even Amazon’s own Alexa. AWS traced the trigger to a DNS resolution issue affecting DynamoDB service endpoints in the US‑EAST‑1 (N. Virginia) region. By the evening, AWS said all services had returned to normal operations.

What happened — key timeline

• 3:11 AM ET: AWS reports increased error rates and latencies across multiple services in US‑EAST‑1.
• 5:01 AM ET: Root cause identified as DNS resolution issues for DynamoDB API endpoints.
• 5:24 AM ET (2:24 AM PT): AWS says the underlying DNS issue was fully mitigated; recovery efforts continue.
• Morning–midday: Knock‑on effects hit other services, notably new EC2 instance launches; AWS rate‑limited launches to aid recovery.
• 3:01 PM PT: AWS states all services returned to normal; backlogs clear progressively.

Because so many companies rely on US‑EAST‑1, the blast radius was large. As one expert put it, “Amazon had the data safely stored, but nobody else could find it,” temporarily separating apps from their data.

Who was affected (selection)

• Amazon services (Alexa), Amazon.com operations
• Venmo, Lyft, DoorDash, Grubhub
• Snapchat, Reddit, Pinterest
• Disney+, Hulu, Apple Music, Apple TV
• Fortnite, Roblox, PlayStation services
• Some banks and airlines (varied reports)

Why it matters

Cloud concentration enables scale, but a regional DNS issue can cascade into widespread disruptions. US‑EAST‑1’s centrality means outages there feel like “half the internet” is down. The event underscores the importance of multi‑AZ and multi‑region architectures, robust DNS strategies and graceful‑degradation patterns.

Resilience takeaways

• Architect beyond one region: Consider active‑active multi‑region for critical workloads; avoid hard‑pinning to a single AZ.
• Harden DNS paths: Use resilient resolvers, right‑size TTLs, and validate fallback behavior if service endpoints fail.
• Graceful degradation: Provide read‑only modes, local caches and queueing to keep core experiences alive during partial outages.
• Recovery‑aware clients: Implement exponential backoff, idempotent writes and back‑pressure to handle throttling during recovery.
• Test DR plans: Run chaos and failover drills regularly to surface weak links before the next incident.

Status and references

• AWS Service Health Dashboard
• Incident coverage and timeline
• Downdetector (third‑party outage reports)

Bottom line: The outage is resolved, but it’s a fresh reminder to audit single‑region dependencies and validate failover plans before the next event.

Discussion: What’s your strategy for the next regional cloud outage — multi‑region, multi‑cloud, or smarter edge caching?