AWS us-east-1 May 2026: a data-center thermal event and a 28-hour single-AZ failure

Timeline

What happened, hour by hour

Times anchored to AWS Health Dashboard status updates (reported in PDT) and cross-checked with Network World and IT Pro. UTC conversions added for readability.

Affected Services

Who went down

Because the failure was confined to use1-az4, the worst-hit companies were disproportionately those with capacity concentrated in that single Availability Zone. The list below is illustrative, not exhaustive.

Root Cause

A building that got too hot

The October 2025 us-east-1 outage was a software race condition in DynamoDB's DNS automation. The May 2026 event was the opposite kind of failure: a physical one. Multiple cooling units failed in a single data-center hall serving Availability Zone use1-az4, and cooling capacity in that hall dropped sharply. AWS described it as an increase in temperatures within a single data center that, in some cases, caused impairments.

As the room heated past operating thresholds, servers did what they are designed to do: they shut themselves down to protect the hardware. That automatic protective shutdown is what produced the power loss, and the abrupt loss of power physically impaired EC2 instances and EBS volumes on the affected racks. Restoration could not simply be a reboot; cooling had to be brought back below thermal thresholds before the hardware could be safely powered on again, which is why the recovery stretched across most of a day.

Cooling was stabilized to pre-incident levels at about 1:50 PM PDT on 8 May, roughly 20 hours after the first status update, and most affected instances and volumes recovered then. Data-heavy managed services that sit on EC2 and EBS, including ElastiCache, MSK, OpenSearch Service, and SageMaker, worked through their own restoration into the evening, pushing full recovery to roughly 28 hours.

Economic Impact

Real losses, but no disclosed total

No firm independent loss estimate has been published for the May 2026 event, in contrast to the October 2025 outage, where CyberCube put insured losses in a $38M to $581M range. The smaller blast radius is part of the reason: a single-Availability-Zone failure hits far fewer customers than a region-wide one, so the aggregate is both smaller and harder to bound. AWS does not disclose customer-impact figures.

What is documented is the shape of the damage at named customers: Coinbase offline for roughly seven hours during a volatile crypto session, FanDuel unable to take cash-outs during a live playoff game, and institutional traders locked out of CME Direct. A conservative revenue-at-risk estimate places aggregate customer losses in the tens of millions of dollars, but treat that as a modeled figure, not a disclosed one.

Any SLA credit those customers received would have been a small fraction of their revenue loss. AWS's EC2 SLA returns 10 to 30 percent of the affected service's monthly fee, never a percentage of your revenue; see our SLA credit asymmetry analysis. To translate the event into your own numbers, the downtime cost calculator applies your revenue and architecture to an outage of any duration.

Architectural Lessons

A single Availability Zone is a real failure domain

The May 2026 event is a clean reminder that physical infrastructure still fails, and that an Availability Zone is the unit of physical fault isolation. Cooling, power, and the servers themselves sit beneath every managed service you run; no amount of software redundancy inside a single zone helps when the building that hosts it overheats.

The mitigation is also clean: spread workloads across at least two Availability Zones, and confirm that failover actually works rather than assuming it does. Customers who genuinely ran multi-AZ largely rode this out; those who had concentrated capacity in use1-az4, often without realizing it, took the brunt. Auto Scaling groups, RDS Multi-AZ, and load balancers spanning zones exist precisely for this failure mode, and it is cheap insurance relative to the revenue at risk.

The flip side matters too: multi-AZ does nothing against a region-wide control-plane failure like October 2025, which defeated multi-AZ designs by breaking a regional dependency. The two events are the two ends of the resilience spectrum, which is why a serious reliability plan addresses both. For the cost-benefit math on multi-AZ versus multi-region, see our business case builder, and for how this event sits against the wider record, see the full AWS outage history.

Frequently Asked

Common Questions