AWS Outage History: Every Major Incident from 2011 to 2026

Six AWS incidents since 2011 have been large enough to be visible from outside AWS, in the sense that they took down recognisable consumer products and made general news. Sort the table by any column: duration exposes how long recovery actually took, region shows how concentrated these events are, and the trigger column is where the repeating pattern becomes obvious.

This is a list of internet-scale events, not a complete AWS incident log. Smaller regional and per-service degradations happen far more often, and they are the ones that actually break a given team's week. Those are on the live AWS status page, tracked per service and per region as they happen.

The years that appear in the table above are 2011, 2017, 2020, 2021, 2023 and 2025. What is more interesting is the years that do not: 2012 through 2016, 2018, 2019, 2022, 2024 and the first three quarters of 2026 produced no AWS incident that reached this bar. AWS is not getting steadily worse, and the popular framing of an annual december outage is not supported by the record.

Two years stand out for a reason that has nothing to do with frequency. 2020 and 2021 landed back-to-back, and both were failures of shared internal machinery rather than of the service that appeared to break. That pair is what moved multi-region architecture from a nice-to-have to a board-level question at a lot of companies.

For the current year, the table is the wrong instrument: it only lists events after they are large enough and old enough to be summarised. PulsAPI records AWS incidents as they open and close, so the AWS service page carries this year's history at full resolution, including the regional events that never make the news.

us-east-1, and it is not close: five of the six incidents above originated there, and the sixth spanned multiple regions. No other single region appears in the list at all.

That is not evidence that us-east-1 is operated worse than eu-west-1. It is the oldest and largest region, it carries the most traffic and the most customer workloads, and (the part that catches teams out) it hosts the global control planes for several AWS services. IAM, Route 53 health checks and billing anchor there regardless of where your workload runs, so a us-east-1 control-plane event can present as a global outage to an application that has no us-east-1 resources at all.

The practical reading: choosing a different default region genuinely reduces your exposure to the data-plane half of this, and does nothing about the control-plane half. Both halves need a plan, and they are different plans.

At the scale in the table, meaning an event that takes recognisable products offline and makes general news, roughly once every two and a half years across the 2011 to 2026 window. That is the number worth quoting when someone asks whether AWS is reliable, and the honest answer is that it is extremely reliable at that scale.

It is also the wrong number for capacity planning, because it is not the failure rate your service will actually experience. Single-service, single-region degradations, such as an elevated error rate on SQS in eu-west-1 for forty minutes, happen orders of magnitude more often, rarely get a headline, and are perfectly capable of breaking a checkout flow. Those are the events worth instrumenting for.

The gap between the two numbers is the whole argument for tracking AWS per component rather than as one entity. PulsAPI monitors AWS status separately for each service and region, so an alert fires for the dependency you actually use instead of for the letters A-W-S.

AWS runs an estimated 32% of the global public cloud market, which means a major AWS incident isn't just one company's problem, it's an internet-scale event. When us-east-1 has a bad day, so do Slack, Disney+, Coinbase, Robinhood, Reddit, and tens of thousands of SaaS businesses that silently depend on the region for control-plane operations.

The pattern repeats because us-east-1 is the default region in countless SDKs, Terraform modules, and tutorials. Global AWS services like IAM, Route 53 health checks, and billing also anchor in us-east-1, so a regional incident can look like a global one even for workloads running in other regions.

Understanding the history of AWS outages is not academic. It tells you which failure modes are likely to repeat, which dependencies are load-bearing for your own stack, and where to invest in redundancy before the next incident forces the decision.

Watching for the next one is a different problem from reading about the last one. That is what a status page aggregator does: it reads AWS's own health feed alongside every other vendor you depend on, so you find out from one place instead of remembering which tab to open. You can see the current AWS status the same way.

Across 15 years of incidents, a few patterns dominate. First, us-east-1 is disproportionately represented, not because the region is poorly operated, but because it carries more traffic, more global service dependencies, and more customer workloads than any other region. If you can run outside us-east-1, you should.

Second, the failure mode is almost always a control-plane or shared-infrastructure problem rather than a raw hardware failure. Capacity additions, configuration changes, and throttling subsystems are the usual triggers. This means engineering teams can't protect themselves purely by adding more AWS, they need to reduce coupling to AWS control planes during an incident.

Third, the AWS Service Health Dashboard is systematically late. Across the incidents above, customer-impacting degradation was detectable via synthetic probes and community chatter 15 to 90 minutes before AWS acknowledged the incident on its status page. PulsAPI users consistently see earlier signals because our monitoring combines real probe data, community reports, and vendor status feeds in parallel.

The durable lessons from AWS outage history translate into a small set of concrete practices. Avoid us-east-1 as your default region when you have a choice. Treat IAM, Route 53, and billing as us-east-1 dependencies regardless of where your workload runs, and assume they can fail together. Do not rely on the AWS Console to run an incident, your runbook must work via AWS CLI, Terraform, or a pre-configured break-glass path.

Subscribe to AWS components individually in PulsAPI rather than treating 'AWS' as a single entity. S3 us-east-1 being degraded has nothing to do with EC2 us-west-2 being healthy. PulsAPI tracks more than 200 individual AWS components across every region, so alerts you receive are scoped to dependencies you actually use.

Finally, pre-write your customer communication templates for AWS incidents specifically. When us-east-1 goes down, your customers will see outages across dozens of SaaS tools simultaneously, they don't need another vague 'we're investigating' post. They need a clear statement of which of your features are affected, which are not, and what they should do in the meantime. Teams that publish within 5 minutes of a major AWS incident consistently earn trust; teams that publish 40 minutes in consistently lose it.