What is the AWS us-east-1 outage history over the last 5 years?

AWS us-east-1 has had at least four major publicly documented outages since December 2021: a network-device congestion event (Dec 7, 2021), a Lambda scaling defect (June 13, 2023), a Kinesis contention event (July 30, 2024), and a DynamoDB DNS race condition (Oct 19–20, 2025). Each cascaded into global services because their control planes live in us-east-1.

AWS us-east-1 Outage History: A 5-Year Timeline

Q: How many major us-east-1 outages has AWS documented since 2021?

AWS's public Post-Event Summary archive lists four major us-east-1 events since December 2021: December 7, 2021; June 13, 2023; July 30, 2024; and October 19–20, 2025. A fifth, the November 25, 2020 Kinesis event, falls just outside the strict five-year window from this article's publish date but is commonly included in five-year retrospectives.

Q: Why does an outage in one AWS region affect services worldwide?

Because several AWS services that appear global host their control plane in a single region — us-east-1 for IAM, AWS Organizations, Route 53 public DNS, and CloudFront, among others. A control-plane event in that region can block create/read/update/delete operations for those services everywhere, even though each region's data plane keeps running independently.

Q: Is AWS's Secure Token Service (STS) still global-only?

No. STS defaults to a global endpoint hosted in us-east-1 for backward compatibility, but AWS has offered regional STS endpoints for years and explicitly recommends configuring your SDK/CLI to use them, particularly if you use SigV4A signing, which requires a regional STS endpoint.

Q: What was the root cause of the October 2025 AWS outage?

A latent race condition in DynamoDB's automated DNS management system caused the automation to apply an outdated DNS plan and then delete it during cleanup, leaving the regional DynamoDB endpoint with zero IP addresses. Automation could not self-repair, requiring manual intervention.

Q: Did the December 2021 outage affect AWS's own status page?

Yes. AWS's own postmortem states that network congestion impaired the Service Health Dashboard tooling from appropriately failing over to a standby region, and that the same congestion delayed AWS's own understanding of the event and its ability to open new customer support cases.

Q: Where can I verify these outages beyond this article?

Go directly to AWS's Post-Event Summary archive and to each event's individual PES page — these are the primary source AWS itself publishes and keeps live for a minimum of five years.

Why this matters right now

Every CAB that approves changes touching AWS-hosted workloads is implicitly betting on the availability of one region: US East (N. Virginia), known internally as us-east-1. That is not a metaphor — AWS’s own fault-isolation documentation lists us-east-1 as the control-plane home for IAM, AWS Organizations, Account Management, Route 53 public DNS, CloudFront, WAF for CloudFront, ACM for CloudFront, and Shield Advanced, plus the default global endpoint for the Security Token Service (AWS Fault Isolation Boundaries whitepaper). The October 2025 outage alone took down Snapchat, Coinbase, Fortnite, Ring, Venmo, and Amazon’s own retail site for hours, with public damage estimates running into the billions once you count lost transactions, SLA credits, and incident-response labor across thousands of downstream businesses (AWSDown incident writeup; CNBC). For a CAB chair, the risk isn’t abstract: a routine change window that assumes STS, IAM, or Route 53 will respond normally is a change window built on a single point of failure AWS itself tells customers not to design around.

Why us-east-1 specifically keeps breaking things

us-east-1 is AWS’s oldest and largest region, and its age and scale are exactly why it concentrates risk rather than diluting it. Two structural facts explain the pattern:

It hosts control planes that the rest of the world depends on. AWS’s fault-isolation guidance splits “global” services into three categories, and every one of them anchors back to us-east-1 for control-plane operations: partitional services (IAM, AWS Organizations, Account Management, Route 53 Private DNS), edge-network services (Route 53 Public DNS, CloudFront, WAF for CloudFront, ACM for CloudFront, Shield Advanced), and default global endpoints (STS defaults to us-east-1 unless you explicitly configure a regional endpoint) (AWS Fault Isolation Boundaries whitepaper). AWS is explicit that “a failure impacting the Region hosting the control planes for these services, or a failure impacting the control plane itself” can break create/read/update/delete/list operations everywhere, even for resources that physically live in other regions.

It has the largest customer footprint of any AWS region, which means any regional degradation touches more workloads, more dependency chains, and more downstream retries than the same failure would in a smaller region. AWS’s own account of the December 2021 event describes exactly this dynamic: an automated capacity-scaling action “triggered an unexpected behavior from a large number of clients,” causing a connection surge that congested the shared network devices between AWS’s internal and main networks (Summary of the AWS Service Event in the Northern Virginia Region, Dec 7, 2021). More clients means bigger surges when something goes wrong.

The five confirmed us-east-1 events, 2021–2025

The table below covers every us-east-1 event for which AWS has published a formal Post-Event Summary (PES) in the period. AWS commits to publishing a PES “when an issue has broad and significant customer impact that results in the failure of a significant percentage of control plane API calls, impacts a significant percentage of a service’s infrastructure, resources or APIs, or is the result of total power failure or significant network failure,” and keeps each PES live for a minimum of five years (AWS Post-Event Summaries archive). Widely reported incidents from December 15 and December 22, 2021 do not appear on this archive page as separate PES entries, so they are omitted here — treat any timeline that lists them with a distinct AWS postmortem URL with skepticism.

Date	Duration	Root cause (per AWS)	Blast radius	What AWS changed
Nov 25, 2020	~9 hours (5:15 AM–after 6 PM PST, full recovery 10:23 PM PST)	Front-end Kinesis servers exceeded an OS thread-count limit after a capacity addition, corrupting shard-map caches	Kinesis; Cognito; CloudWatch; Lambda (metric buffering caused memory contention)	Moved to larger front-end servers, added thread-consumption alarms, accelerated “cellularization” of the front-end fleet (Summary of the Amazon Kinesis Event, Nov 25, 2020)
Dec 7, 2021	~7 hours (7:30 AM–2:22 PM PST for network devices; some services until ~4:41 PM PST)	Automated capacity-scaling activity on the internal AWS network triggered a connection surge that overwhelmed devices bridging the internal and main networks	EC2 APIs, Route 53 API (not DNS resolution itself), STS, CloudWatch, API Gateway, Fargate/ECS/EKS, Amazon Connect, the AWS Console and Service Health Dashboard itself	Disabled the triggering scaling activity, fixed a latent client back-off defect, deployed new network device protections, committed to a rebuilt Service Health Dashboard and multi-region support architecture (Summary of the AWS Service Event, Dec 7, 2021)
June 13, 2023	~3.75 hours (11:49 AM–3:37 PM PDT)	A Lambda Frontend capacity-scaling action crossed a never-before-reached threshold in one cell, triggering a latent software defect that stranded execution environments	Lambda invocations, STS, AWS Console, AWS Sign-in (SAML), EKS cluster provisioning, Amazon Connect, EventBridge, Support Center	Fixed and deployed the latent bug across all regions, closed a gap in Lambda’s cellular-scaling architecture, committed to bounding all cells to a tested size (Summary of the AWS Lambda Service Event, June 13, 2023)
July 30, 2024	~6.75 hours (2:45 PM–9:37 PM PDT)	A subsystem within a Kinesis Data Streams cell hit increased contention processing incoming data	CloudWatch Logs, Amazon Data Firehose, S3 event notifications, ECS, Lambda (missing/delayed function logs), Redshift, AWS Glue	Recovered the affected cell; AWS’s summary does not detail additional structural remediations beyond cell recovery (Summary of the Amazon Kinesis Data Streams Service Event, July 30, 2024)
Oct 19–20, 2025	~15 hours across three overlapping phases (11:48 PM Oct 19–3:01 PM Oct 20 PDT)	Latent race condition in DynamoDB’s automated DNS management system deleted all IP addresses from the regional endpoint record; recovery was then complicated by EC2 internal network state loss and NLB health-check flapping	DynamoDB, EC2 instance launches, Lambda, ECS, EKS, Fargate, Network Load Balancer, Amazon Connect, and Amazon.com/subsidiaries	Disabled the DynamoDB DNS Planner/Enactor automation worldwide pending a fix, added an NLB velocity control to limit capacity removed per health-check failure, improved EC2 data-propagation throttling (Summary of the Amazon DynamoDB Service Disruption, Oct 19, 2025)

Two additional facts worth flagging for CAB records: the June 2023 event’s own AWS summary confirms STS, not just Lambda, degraded for federated sign-ins — a detail easy to miss if you only track “Lambda outages” (Summary of the AWS Lambda Service Event, June 13, 2023). And the October 2025 event is now the largest us-east-1 disruption by breadth and duration since December 2021, based on AWS’s own published timelines for both events.

What patterns actually repeat

Reading five AWS-authored postmortems back to back surfaces the same three failure shapes every time, not five unrelated incidents.

Automated scaling is the recurring trigger, not external attack. The 2020 Kinesis event, the 2021 network event, and the 2023 Lambda event were all triggered by AWS’s own capacity-scaling automation crossing an untested threshold or limit (Kinesis, Nov 2020; network event, Dec 2021; Lambda, June 2023). October 2025 was a DNS-automation race condition rather than a scaling action, but the shape is the same: automation that behaves correctly in normal conditions and destructively at a rare timing edge case.

Global services domiciled in us-east-1 amplify the blast radius past the region itself. STS, the AWS Console, Route 53’s control plane, and Amazon Connect show up across nearly every event above, even when the proximate cause (Kinesis contention, a Lambda cell defect, a DynamoDB DNS bug) has nothing to do with those services on paper. That’s a direct consequence of AWS’s architecture: IAM’s and Route 53’s control planes exist only in us-east-1 for the aws partition (AWS Fault Isolation Boundaries whitepaper).

Monitoring and status-page tooling fails alongside the primary system. In December 2021, AWS’s own Service Health Dashboard and Support Contact Center were degraded by the same congestion that took down customer-facing services, delaying both AWS’s understanding of the event and its communication to customers (Summary of the AWS Service Event, Dec 7, 2021). Never treat “the status page is green” as sufficient confirmation during a live incident — see monitoring external risk sources beyond vendor dashboards.

Recovery amplifies its own failure through retry storms. AWS’s October 2025 postmortem describes a recovery phase messier than the initial fault: once DynamoDB’s DNS record was restored, EC2’s internal capacity-management system had to work through a backlog of lease timeouts, and Network Load Balancer health checks began flapping healthy targets out of service, extending impact well past the original DNS fix (Summary of the Amazon DynamoDB Service Disruption, Oct 2025). A change window scheduled for “right after AWS says it’s resolved” often lands during the riskiest part of the recovery curve — see how teams solve change window scheduling.

Architectural takeaways for CAB chairs

None of this means “leave AWS.” It means treating us-east-1 dependency as a named risk in your change and resilience register rather than an assumption.

Multi-region posture should target static stability, not automated failover. AWS’s guidance for global services favors architecture that doesn’t need to call a control plane to survive a regional event — cache control-plane data (IAM role ARNs, DNS records, S3 bucket configuration) in a store your workload can read without a live control-plane call, and pre-provision load balancers and API Gateway endpoints rather than creating them during a failover (AWS Fault Isolation Boundaries whitepaper).
STS is not “just global” by default anymore — pin it to a region. AWS’s SDK and CLI default to the global STS endpoint hosted in us-east-1, but AWS offers regional STS endpoints and recommends updating your configuration so an STS event in one region doesn’t take down authentication everywhere (AWS Fault Isolation Boundaries whitepaper). If your CAB has never asked “which STS endpoint does this service use,” add it to the change template.
Route 53 health checks are data-plane, but changing them is control-plane. Health checks execute from eight AWS regions and keep running during a us-east-1 control-plane event, but creating or updating one depends on the Route 53 control plane in us-east-1 — so failover logic that needs to create a new health check mid-incident stalls exactly when you need it (AWS Fault Isolation Boundaries whitepaper). Pre-provision every health check you might need.
SAML and federated sign-in need a break-glass path. The June 2023 event degraded SAML federation through STS for over an hour; AWS recommends configuring IAM role trust policies to accept SAML from multiple regions and pre-creating break-glass IAM users for this scenario (Summary of the AWS Lambda Service Event, June 13, 2023; AWS Fault Isolation Boundaries whitepaper).
Treat AWS Health Dashboard as necessary but not sufficient. Cross-reference it against independent status aggregation as a standing part of your CAB’s risk-monitoring routine — see how to run a CAB meeting and our live cloud status heatmap for a cross-vendor view during an active incident.

What to do about it

Inventory every service that defaults to a global endpoint. STS is the highest-priority item; also check any SDK client still using default configuration rather than an explicit region.
Pre-provision Route 53 health checks, ELBs, and API Gateway endpoints you would need during a regional failover instead of planning to create them live.
Add “us-east-1 control-plane dependency” as a standing risk line in your CAB’s risk register, scored the same way you’d score any single-point-of-failure vendor dependency — our change risk score tool gives you a starting rubric.
Configure break-glass IAM users and multi-region SAML trust policies before you need them, not during an incident.
Freeze non-critical changes during any active us-east-1 event, and extend the freeze through the recovery window — retry storms and health-check flapping have repeatedly outlasted the headline fix.
Subscribe to the AWS Health Dashboard and at least one independent aggregator, and cross-check both before declaring a change window safe to resume.
Review your last three change postmortems for “AWS dependency” as a contributing factor, even if the change itself wasn’t AWS-related — a concurrent regional event can mask or worsen unrelated change failures.
Map your DORA operational-resilience obligations against this exposure if you operate in the EU financial sector — see our DORA operational resilience checklist for change managers.

Frequently asked questions

How many major us-east-1 outages has AWS documented since 2021?

Four: December 7, 2021; June 13, 2023; July 30, 2024; and October 19–20, 2025 (AWS Post-Event Summaries). The November 25, 2020 Kinesis event falls just outside a strict five-year window but is commonly included in retrospectives.

Why does an outage in one AWS region affect services worldwide?

Because several “global” AWS services host their control plane in one region — us-east-1 for IAM, AWS Organizations, Route 53 public DNS, and CloudFront, among others. A control-plane event there can block create/read/update/delete operations everywhere, even though each region’s data plane keeps running independently (AWS Fault Isolation Boundaries whitepaper).

Is AWS’s Secure Token Service (STS) still global-only?

No. STS defaults to a global endpoint in us-east-1 for backward compatibility, but AWS offers regional endpoints and recommends using them — SigV4A signing requires one (AWS Fault Isolation Boundaries whitepaper).

What was the root cause of the October 2025 AWS outage?

A latent race condition in DynamoDB’s DNS management system applied an outdated DNS plan and then deleted it during cleanup, leaving the regional endpoint with zero IP addresses — a state automation could not self-repair (Summary of the Amazon DynamoDB Service Disruption, Oct 19, 2025).

Did the December 2021 outage affect AWS’s own status page?

Yes. AWS’s postmortem says the congestion “impaired our Service Health Dashboard tooling from appropriately failing over to our standby region,” which delayed both AWS’s understanding of the event and support-case creation (Summary of the AWS Service Event, Dec 7, 2021).

Should CAB chairs treat AWS outages as “force majeure” and skip a postmortem?

No. AWS publishes a detailed root-cause postmortem for qualifying events; your own incident review should map which services depend on the control planes named in it and track remediation like any internal change failure.

How long did the longest event in this timeline last?

The October 2025 DynamoDB event spanned roughly 15 hours across three overlapping phases — DynamoDB, then EC2, then Network Load Balancer — from 11:48 PM PDT on October 19 to full recovery around 3:01 PM PDT on October 20 (Summary of the Amazon DynamoDB Service Disruption, Oct 19, 2025).

Where can I verify these outages beyond this article?

Go directly to AWS’s Post-Event Summary archive and each event’s PES page linked below — the primary source AWS publishes and keeps live for a minimum of five years (AWS Post-Event Summaries).

Sources

#aws #us-east-1 #cloud-outages #postmortem #reliability

Published July 21, 2026.