The Overheated AWS Zone.
The outage was not region-wide, and that is what made it instructive. A thermal event in one Availability Zone still disrupted EC2, EBS, and downstream services whose architectures could not cleanly leave it.
The cloud failure was not a region disappearing. It was narrower and more revealing: one AWS Availability Zone got too hot, servers protected themselves by shutting down, and workloads that still depended on that zone lost the ground underneath them. For teams that treat a region as resilient by default, this is the sharper lesson. A zone can fail cleanly on the provider side while an application still fails messily because one critical dependency never left it.
AWS reported the event in use1-az4, one Availability Zone inside US-EAST-1. The affected hardware hosted EC2 instances and EBS volumes, so the blast radius included both compute and block storage. That combination matters. If an instance disappears, a replacement can often launch elsewhere. If the attached volume is impaired too, recovery depends on replicas, snapshots, or another storage path that already exists.
The event began on May 7, 2026, at 16:20 PDT, according to AWS updates later summarized by Network World. AWS identified impairments in use1-az4 at 00:25 UTC on May 8 and said other Availability Zones were not affected. As temperatures stayed high, AWS shifted traffic away from the impacted zone for most services, but recovery of affected EC2 instances and EBS volumes took longer because the physical environment had to become safe again before hardware could return.
That is what made the incident different from a bad deploy or a control-plane bug. There was no config rollback that could make overheated hardware safe. AWS had to bring additional cooling capacity online, wait for the environment to stabilize, restore power where it was safe, and recover infrastructure in phases. By 20:50 UTC on May 8, AWS reported that cooling capacity had returned to pre-event levels, which removed the physical blocker before the remaining recovery work finished.
Downstream impact depended less on whether a company used AWS and more on whether its critical path could survive the loss of that zone. ITPro reported Coinbase trading disruption lasting more than five hours, and other reports named CME Group and FanDuel. StatusGator correlated status pages and user reports across more than 150 cloud services with confirmed or likely AWS-related impact. The common pattern was not a region-wide outage. It was dependency concentration: compute, storage, brokers, databases, vendors, or recovery paths tied too tightly to the affected zone.
The useful takeaway is not that AWS customers should avoid US-EAST-1. It is that an Availability Zone is only a failure boundary if the application has no load-bearing dependency trapped inside it. A thermal event made the boundary visible: provider containment kept the physical problem zonal, but customer architectures still had to prove they could leave the failed zone without the failed zone's help.
EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event.// AWS Health Dashboard update, quoted by ITPro and Network World
From the first signal to all-clear in 20h 30m.
A physical cooling failure exposed zonal concentration.
The failure started below the software stack. AWS reported increased temperatures inside a single data center in US-EAST-1, affecting resources in the use1-az4 Availability Zone. As temperatures exceeded operating thresholds, servers automatically shut down to protect hardware. That left EC2 instances and EBS volumes on impacted hardware impaired by power loss.
AWS contained the event at the Availability Zone level. Other Availability Zones were not affected by the thermal event, and AWS shifted traffic away from use1-az4 for most services. That containment limited the AWS-side blast radius, but containment did not automatically recover customer workloads that kept compute, storage, databases, brokers, or recovery paths tied to the affected zone.
Recovery depended on the physical environment before orchestration. AWS could not simply restart the affected hardware while temperatures remained above safe thresholds. Engineers had to bring additional cooling capacity online, restore the environment to safe operating conditions, and then recover EC2 instances, EBS volumes, and dependent service workflows in a controlled sequence.