On 7 December 2021, Amazon Web Services had a major outage in its us-east-1 region. It started at 7:30am Pacific and the network devices were not fully recovered until 2:22pm — just under seven hours, by AWS's own account, which says the event "impacted many customers in significant ways" without naming any of them.
The list of what broke is easier to grasp than the cause: EC2 APIs, RDS, Lambda and API Gateway, Route 53, EventBridge, the container services, Amazon Connect — and CloudWatch, which is what a great many teams were trying to use to find out what was happening.
This is the reality of cloud computing. When a dominant infrastructure provider has problems, the ripple effects are enormous.
Why so many services depend on AWS
Amazon Web Services is the largest cloud infrastructure provider by market share — the exact figure moves every quarter and depends on who is counting, but the ordering has been stable for years. It is the default choice for a huge proportion of technology companies, from early-stage startups to Fortune 500 enterprises. The convenience, breadth of services, and mature tooling make it the path of least resistance for most engineering teams.
This concentration creates systemic risk. When AWS has issues, the probability of your favourite services being affected is significant — not because those companies are negligent, but because the entire industry made the same rational choice about infrastructure.
How AWS outages propagate
AWS is divided into regions (like us-east-1, eu-west-1) and within each region, multiple availability zones. In theory, distributing your application across availability zones or regions protects against failures. In practice, many services do not implement multi-region redundancy, either because of cost, complexity, or the belief that AWS availability zones offer sufficient protection.
When a core service like EC2 (compute), S3 (storage), or Lambda (serverless functions) degrades in a region, every application that depends on it is affected. Because us-east-1 is the oldest and largest AWS region — and the default for many applications — its outages have disproportionate impact.
Detecting AWS-caused outages
When AWS has an incident, you will typically see a cluster of services going down simultaneously on WebsiteDown — streaming services, fintech apps, developer tools, and social platforms all degrading within the same 15-minute window. This pattern is almost always infrastructure, not coincidence.
AWS publishes its real-time status at health.aws.amazon.com. The Personal Health Dashboard (for AWS customers) shows issues specific to your account and resources.
What to expect during an AWS outage
AWS outages vary enormously in scope and duration. A failure affecting a single service (like SQS or DynamoDB) in one region might resolve in 30 minutes. A broader EC2 or networking failure can take several hours and affect multiple services simultaneously.
AWS provides post-incident reports for major outages, usually published within a week. These are worth reading if you run infrastructure — they explain root causes and inform architectural decisions about resilience.