AWS Outage History: 12 of 18 Major Outages Hit us-east-1, and the Longest of All Has No Post-Event Summary

AWS outage history, from AWS’s own records: Amazon has published 18 Post-Event Summaries for major outages since April 2011, and 12 of them were in us-east-1 (Northern Virginia). The median event lasted 6.2 hours. 13 of the 18 were software, configuration, or capacity failures rather than power. In 2026, drone strikes damaged two Middle East regions that AWS has not summarized.

We read every summary on AWS’s Post-Event Summaries index and extracted the region, the start and end times AWS gives, the services named, and the root cause. AWS writes a PES only when an issue has “broad and significant customer impact”, so this is a log of the largest events, not every blip on the status page. Below it, we compare Google Cloud’s public incident feed and Azure’s post incident reviews.

The AWS outage timeline, 2011 to 2026

Latent software bug (6)Operator error in a change (4)Capacity or limit exceeded (3)Facility power or cooling (5)Physical damage, Health Dashboard only (2)

1. Mar 022026

   me-south-1 Bahrain · one AZ, then a second in April · 225 days and still listed as disrupted

   AWS says a drone strike near one facility caused physical damage, a second AZ was disrupted in April, and on September 15, 2026 it said it cannot restore resources and data hosted only in the Region.

   Services: 149 listed as impacted on the public dashboard

   Cause: Physical damage (drone strikes) · no PES published · AWS Health Dashboard

2. Mar 012026

   me-central-1 UAE · two of three AZs impaired · 226 days and still listed as disrupted

   AWS says two of its UAE facilities were directly struck by drones, and by April 30 the Region was "unable to reliably support customer applications". On September 15, 2026 it said it cannot restore resources and data hosted only in the mec1-az2 zone.

   Services: 140 listed as impacted on the public dashboard

   Cause: Physical damage (drone strikes) · no PES published · AWS Health Dashboard

3. Oct 192025

   us-east-1 N. Virginia · regional service · 14 h 32 min (last service back after 1 d 4 h 17 min)

   A latent race condition in DynamoDB’s automated DNS management left the regional endpoint with an empty DNS record that the automation could not repair.

   Services: DynamoDB, EC2, Network Load Balancer, Lambda, ECS/EKS/Fargate, Connect, STS, IAM sign-in, Redshift, Support

   Cause: Latent software bug · AWS Post-Event Summary

4. Jul 302024

   us-east-1 N. Virginia · regional service · 6 h 52 min (last service back after 1 d 11 h 53 min)

   A routine deployment exposed how Kinesis’s new cell management system mishandled a workload with very many low-throughput shards.

   Services: Kinesis (internal cell), CloudWatch Logs, Data Firehose, S3 events, ECS, Lambda, Redshift, Glue

   Cause: Latent software bug · began with: routine deployment · AWS Post-Event Summary

5. Jun 132023

   us-east-1 N. Virginia · regional service · 3 h 48 min

   Scaling the Lambda Frontend fleet past a never-before-reached cell size triggered a latent software defect.

   Services: Lambda, STS, Console, EKS, Connect, EventBridge, Sign-in

   Cause: Latent software bug · began with: fleet scaling · AWS Post-Event Summary

6. Dec 072021

   us-east-1 N. Virginia · regional service · 6 h 52 min (last service back after 11 h 10 min)

   An automated scaling activity exposed a latent client back-off bug, flooding the devices between AWS’s internal and main networks.

   Services: EC2 APIs, Route 53 APIs, Console, STS, EventBridge, API Gateway, Fargate, Connect

   Cause: Latent software bug · began with: automated scaling activity · AWS Post-Event Summary

7. Sep 022021

   ap-northeast-1 Tokyo · regional service · 6 h 12 min

   A latent defect in a network device operating system, set off by a specific customer packet pattern, made Direct Connect devices fail.

   Services: Direct Connect

   Cause: Latent software bug · AWS Post-Event Summary

8. Nov 252020

   us-east-1 N. Virginia · regional service · 17 h 8 min

   A small capacity addition pushed every Kinesis front-end server past an operating-system thread limit.

   Services: Kinesis, Cognito, CloudWatch, EventBridge, Lambda, Auto Scaling

   Cause: Capacity or limit exceeded · began with: capacity addition · AWS Post-Event Summary

9. Aug 232019

   ap-northeast-1 Tokyo · single AZ · 5 h 54 min

   A bug in third-party cooling control software, plus unresponsive PLCs, shut down cooling in part of one AZ and servers overheated.

   Services: EC2, EBS, EC2 RunInstances API

   Cause: Facility power or cooling · AWS Post-Event Summary

10. Nov 222018

    ap-northeast-2 Seoul · regional service · 1 h 24 min

    A configuration update removed the minimum-healthy-hosts setting for the EC2 DNS resolver fleet, which then scaled down too far.

    Services: EC2 DNS resolution

    Cause: Operator error in a change · began with: configuration update · AWS Post-Event Summary

11. Feb 282017

    us-east-1 N. Virginia · regional service · 4 h 17 min

    A mistyped input to an established playbook command removed far more S3 servers than intended, forcing full restarts of two S3 subsystems.

    Services: S3, EC2 launches, EBS (from snapshots), Lambda, S3 console

    Cause: Operator error in a change · began with: capacity-removal command · AWS Post-Event Summary

12. Jun 042016

    ap-southeast-2 Sydney · single AZ · 9 h 35 min

    Severe weather caused a utility voltage sag; breakers did not isolate the diesel rotary UPS units fast enough, so they drained and shut down.

    Services: EC2, EBS

    Cause: Facility power or cooling · AWS Post-Event Summary

13. Sep 202015

    us-east-1 N. Virginia · regional service · 4 h 51 min (last service back after 8 h 33 min)

    A brief network disruption hit a DynamoDB metadata service that lacked capacity for membership lists that had grown with Global Secondary Index adoption.

    Services: DynamoDB, SQS, EC2 Auto Scaling, CloudWatch, Console

    Cause: Capacity or limit exceeded · AWS Post-Event Summary

14. Jun 132014

    us-east-1 N. Virginia · regional service · 2 h (last service back after 4 h 14 min)

    Power loss to storage nodes in one data center overloaded a lock service whose handshake timeout was set too low, and nodes removed themselves from the cluster.

    Services: SimpleDB

    Cause: Capacity or limit exceeded · AWS Post-Event Summary

15. Dec 172013

    sa-east-1 Sao Paulo · single AZ · not stated

    A utility substation fault, a generator breaker that opened and a second generator’s mechanical failure left one AZ without enough power.

    Services: EC2 (plus 20 minutes of degraded network in both AZs)

    Cause: Facility power or cooling · AWS Post-Event Summary

16. Dec 242012

    us-east-1 N. Virginia · regional service · 22 h 6 min (last service back after 23 h 41 min)

    A maintenance process was run against production by mistake and deleted part of the ELB control plane’s state data.

    Services: Elastic Load Balancing

    Cause: Operator error in a change · began with: maintenance process run against production · AWS Post-Event Summary

17. Oct 222012

    us-east-1 N. Virginia · single AZ · 6 h 15 min (last service back after 11 h 50 min)

    A DNS change after a server replacement did not fully propagate, which set off a latent memory leak in the EBS data-collection agent.

    Services: EBS, EC2 APIs, RDS, ELB

    Cause: Latent software bug · began with: DNS update after a server replacement · AWS Post-Event Summary

18. Jun 292012

    us-east-1 N. Virginia · single AZ · 4 h 21 min (last service back after 6 h 41 min)

    An electrical storm cut utility power twice and one data center’s generators failed to provide stable voltage, so servers lost power when UPS units drained.

    Services: EC2, EBS, RDS, ELB (region-wide EC2 control plane for 66 minutes)

    Cause: Facility power or cooling · AWS Post-Event Summary

19. Aug 072011

    eu-west-1 Ireland · single AZ · 3 h 8 min (last service back after 3 d 9 h 44 min)

    A utility transformer failed and a PLC did not bring backup generators online, cutting power to most of one Availability Zone. AWS's index lists this summary under August 7, 2014; the text (a Friday, August 5 and a Sunday, August 7) and contemporary coverage place it in 2011.

    Services: EC2, EBS, RDS

    Cause: Facility power or cooling · AWS Post-Event Summary

20. Apr 212011

    us-east-1 N. Virginia · single AZ · 2 d 17 h 28 min (last service back after 3 d 11 h 43 min)

    A network upgrade’s traffic shift was executed incorrectly, cutting EBS nodes off from their replicas and setting off a re-mirroring storm.

    Services: EC2, EBS, RDS (EBS APIs region-wide for two periods)

    Cause: Operator error in a change · began with: network capacity upgrade · AWS Post-Event Summary

Duration is the headline window: first customer impact to the time AWS gives for recovery of the main affected services. The figure in brackets runs to the last recovery time AWS reports for any service, such as cleared backlogs. Dates are the day the event began in the time zone AWS used (Pacific for most US and global events).

Does us-east-1 dominate AWS outages?

Yes. 12 of the 18 summaries, or 67%, describe events in Northern Virginia, and every summary since 2022 is a us-east-1 event. Tokyo is the only other region with more than one. Events in us-east-1 were not shorter either: the median headline window there was 6.6 hours, against 5.9 hours for the other regions.

Count of AWS Post-Event Summaries by region, coloured by root-cause category. The two 2026 Middle East events are not included because AWS has not published summaries for them.

The October 2025 summary shows why a Northern Virginia failure can reach customers who do not run there. AWS wrote that customers using root credentials, or identity federation through signin.aws.amazon.com, “experienced errors when trying to log into the AWS Management Console in regions outside of the N. Virginia (us-east-1) Region”, and that Redshift customers in all regions could not use IAM user credentials because of a dependency on an IAM API in us-east-1.

What causes AWS outages: changes and software, not power

We assigned each summary to one category, based on the failure that AWS says defeated its redundancy. 13 of 18 were software, configuration, or capacity problems: 6 latent software bugs, 4 operator errors during a change, and 3 cases where load exceeded a capacity or configured limit. The other 5 were facility power or cooling failures.

One dot per AWS Post-Event Summary, by year the event began. Open circles: the 2026 UAE and Bahrain disruptions, which appear only on the AWS Health Dashboard.

9 of the 18 began with something AWS itself did: a network upgrade, a configuration push, a capacity addition or removal, a fleet scaling step, or a routine deployment. In the October 2025 event the trigger sat inside automation that keeps DNS records updated frequently, and AWS disabled that automation worldwide afterwards. The last summarized facility failure was the Tokyo cooling event in August 2019; all 6 summaries from 2020 to 2025 were software or capacity events in regional services.

2026 broke that pattern in the worst way. On March 1, AWS reported that “objects” had struck a data center in the UAE Region, starting a fire. Two days later it said drone strikes had hit two of its UAE facilities and damaged infrastructure near one in Bahrain. Storms and grid faults caused earlier physical failures, which is why FEMA’s record on disaster declarations by state belongs in a continuity plan alongside cloud status data.

How long AWS outages last

The median headline window across the 17 events with a stated end time was 6.2 hours. Backlogs often stretch impact well beyond that: measured to the last recovery AWS reports, the median is 9.6 hours. The October 2025 DynamoDB event ran 14 h 32 min, the fourth-longest headline window in the record, and some Redshift clusters stayed impaired until the next morning.

Axis capped at 36 hours; arrows mark bars that run past it. Hover for exact values.

The 2026 Middle East events are on a different scale. Adding up every summarized event’s full duration, to the last recovery AWS reports, gives 344 hours, about 14 days. The UAE disruption alone had been open 226 days by October 13, 2026.

Every event in one table

n/s: not stated. The December 2013 Sao Paulo summary gives a start time but no end time.

How AWS compares with Google Cloud and Azure

The three providers do not publish on the same terms, so counts across them are not a reliability ranking. AWS posts a PES only for broad, significant events. Google’s public dashboard lists many smaller incidents, including informational ones. Azure’s history page holds post incident reviews (PIRs) and preliminary reviews for incidents that Microsoft chooses to document publicly.

Google’s incidents.json feed only holds about the last 12 months, so we rebuilt its history by combining 91 readable monthly Internet Archive captures of the feed with the live file, which yields 1,471 incidents since 2013. From 2018, when the captures run without gaps, the count peaked at 351 in 2023, fell to 164 in 2024, and then to just 22 in 2025. Google’s own product history pages show the same counts (351 for 2023, 164 for 2024, 22 for 2025), so the drop is in what Google publishes, not in our reconstruction. The page now points customers to Personalized Service Health for incidents affecting their own projects.

*2026 is January 1 to October 13. Year of incident start, UTC.

Google relabeled severity over time: “low” first appears for informational posts in 2022, so the share rated high is not comparable across all years. Azure’s history page lists 84 entries, the earliest dated July 2021; 2021 is partial.

What this means for MSPs

Multi-AZ covers the facility risk, not the software risk. All 5 power or cooling events in the summaries were confined to one Availability Zone, and after the 2011 Ireland and 2019 Tokyo facility failures (and a single-zone EBS failure in Virginia in October 2012) AWS wrote that customers running across zones kept working or saw limited impact. But 11 of the 13 software, configuration, and capacity events broke a regional service such as S3, DynamoDB, Kinesis, or Lambda, where a second zone does not help. For client workloads that cannot go down for a working day, the realistic design is a warm standby in a second region, with data replication tested on a schedule. In October 2025, AWS noted that customers with DynamoDB global tables could still read and write their replicas in other regions.

Keep backups outside the region. The 2026 Bahrain update is the clearest warning in AWS’s record: the damage “exceeded what our regional and multi-AZ services are designed to withstand”, and AWS said it cannot restore resources and data hosted only in that region. For managed clients, that means cross-region backup copies (or a second provider) are a requirement, and restore tests should include a different region.

Do not rely on the public status page alone. In 3 of the 18 summaries (2017, 2020, and 2021), AWS says its own Service Health Dashboard could not be updated normally during the event, and in March 2026 AWS moved Middle East updates to the account-level Personal Health Dashboard. Wire AWS Health events from each client account into your PSA or alerting tool, add synthetic checks from outside AWS, and treat the public page as a backup.

Plan for us-east-1 specifically. It hosts most of the summarized events and some global sign-in and IAM paths. Keep break-glass access that does not depend on a single identity path, and avoid placing a client’s only copy of anything there by default. As cloud hosting keeps growing faster than the rest of the IT services industry, a single region failure reaches more of a typical MSP’s client base.

Frequently asked questions

When was the last major AWS outage?

The most recent AWS Post-Event Summary covers the DynamoDB DNS failure in us-east-1 on October 19 and 20, 2025, which lasted 14 h 32 min by AWS’s own start and end times. Separately, the AWS Health Dashboard has listed the UAE (me-central-1) and Bahrain (me-south-1) Regions as disrupted since March 1 and 2, 2026, after drone strikes. AWS had not published a summary for those events as of October 13, 2026.

How often does AWS have major outages?

AWS has published 18 Post-Event Summaries covering April 2011 to October 2025: 8 in 2011 to 2015, 5 in 2016 to 2020, and 5 in 2021 to 2025. That is about one qualifying event a year, with no upward trend. AWS writes a summary only for broad, significant events, so smaller incidents do not appear in this count.

What caused AWS to go down?

In 13 of the 18 summarized events the cause was software, configuration, or capacity rather than power or cooling. 9 began with a change, deployment, or scaling action. The October 2025 outage came from a latent race condition in DynamoDB’s automated DNS management, which left the regional endpoint with an empty DNS record.

Which AWS region has the most outages?

us-east-1 (Northern Virginia) accounts for 12 of the 18 Post-Event Summaries, including all 3 published since 2022. No other region has more than 2.

How long do AWS outages last?

Across the 17 summarized events with a stated end time, the median headline window was 6.2 hours. The shortest was 1 h 24 min (Seoul, 2018) and the longest 2 d 17 h 28 min (Northern Virginia, April 2011). Backlogs often ran longer: the median time to the last recovery AWS reports was 9.6 hours.

Does running in multiple Availability Zones protect against AWS outages?

Against facility failures, mostly yes: all 5 power or cooling events in the summaries hit a single Availability Zone, and AWS wrote in several summaries that customers spread across zones kept running. Against software failures, much less: 11 of the 13 software, configuration, or capacity events took down a regional service, where only a second region helps.

Methodology

References

1. AWS, Post-Event Summaries index. Accessed October 2026.
2. AWS, Post-Event Summary, us-east-1, April 21, 2011. Accessed October 2026.
3. AWS, Post-Event Summary, eu-west-1, August 7, 2011. Accessed October 2026.
4. AWS, Post-Event Summary, us-east-1, June 29, 2012. Accessed October 2026.
5. AWS, Post-Event Summary, us-east-1, October 22, 2012. Accessed October 2026.
6. AWS, Post-Event Summary, us-east-1, December 24, 2012. Accessed October 2026.
7. AWS, Post-Event Summary, sa-east-1, December 17, 2013. Accessed October 2026.
8. AWS, Post-Event Summary, us-east-1, June 13, 2014. Accessed October 2026.
9. AWS, Post-Event Summary, us-east-1, September 20, 2015. Accessed October 2026.
10. AWS, Post-Event Summary, ap-southeast-2, June 4, 2016. Accessed October 2026.
11. AWS, Post-Event Summary, us-east-1, February 28, 2017. Accessed October 2026.
12. AWS, Post-Event Summary, ap-northeast-2, November 22, 2018. Accessed October 2026.
13. AWS, Post-Event Summary, ap-northeast-1, August 23, 2019. Accessed October 2026.
14. AWS, Post-Event Summary, us-east-1, November 25, 2020. Accessed October 2026.
15. AWS, Post-Event Summary, ap-northeast-1, September 2, 2021. Accessed October 2026.
16. AWS, Post-Event Summary, us-east-1, December 7, 2021. Accessed October 2026.
17. AWS, Post-Event Summary, us-east-1, June 13, 2023. Accessed October 2026.
18. AWS, Post-Event Summary, us-east-1, July 30, 2024. Accessed October 2026.
19. AWS, Post-Event Summary, us-east-1, October 19, 2025. Accessed October 2026.
20. AWS Health Dashboard (public current-events feed, me-central-1 and me-south-1 events). Accessed October 2026.
21. Google Cloud Service Health, incidents.json. Accessed October 2026.
22. Internet Archive captures of status.cloud.google.com/incidents.json, 2015 to 2026. Accessed October 2026.
23. Google Cloud Service Health, incident history by product. Accessed October 2026.
24. Microsoft Azure, status history. Accessed October 2026.
25. InfoWorld, “Amazon promises to improve redundancy after Dublin outage,” August 15, 2011 (date check for the EU West summary). Accessed October 2026.