The 28-Hour Meltdown: What Happened When AWS US-EAST-1 Overheated
A breakdown of the 28-hour aws us-east-1 outage in may 2026. What caused it, what went down, and what it means for how you design your infrastructure.
Cloud Architect | Distributed Systems & Scaling | Building on AWS
On May 7, 2026, a single data center in AWS's us-east-1 region got too hot. Servers shut themselves down. Power was lost. And for the next 28 hours, thousands of customers watched their infrastructure sit there, impaired, while AWS engineers worked to bring cooling systems back online.
This wasn't a software bug. This wasn't a bad deployment. A building got hot, and everything inside it stopped working.
Let me break down what happened, what it affected, and what we can learn from it.
What Actually Happened
At 4:20 PM PDT on May 7, temperatures inside a single data center within availability zone use1-az4 exceeded safe operating thresholds. When that happens, servers don't politely ask you to save your work. They shut down immediately to protect the hardware.
That automatic shutdown caused a loss of power across the affected racks. EC2 instances went down. EBS volumes became degraded. And because so many AWS services depend on EC2 and EBS under the hood, the blast radius kept growing.
By 5:06 PM, AWS had already started shifting traffic away from the affected AZ. By 5:25 PM, they publicly acknowledged the issue. But the real work, restoring cooling capacity, would take much longer than anyone expected.
The Ripple Effect
This wasn't just an EC2 problem. When the underlying compute and storage layer goes down, everything built on top of it feels the pain.
Services that were affected include Elastic Load Balancing, Elastic Kubernetes Service, ElastiCache, Redshift, OpenSearch, and Managed Streaming for Apache Kafka. Some experienced elevated error rates. Others had full workflow failures.
Redshift had its own separate issue on top of the thermal event. An upstream dependency failure that caused query failures and errors for resume and restart workflows. That got resolved independently by May 8, 9:30 AM.
The Recovery Timeline
Here's how it played out:
May 7, 4:20 PM — Thermal event begins, servers lose power.
May 7, 5:06 PM — AWS shifts traffic away from the affected AZ.
May 7, 9:12 PM — Power restored to a subset of infrastructure. Some signs of recovery.
May 7, 10:11 PM — Additional cooling capacity comes online. Some racks recovered.
May 8, 9:30 AM — Redshift fully recovered (separate fix).
May 8, 1:50 PM — Cooling stabilized to pre-event levels. Majority of EC2 and EBS recovered.
May 8, 8:04 PM — Incident marked as resolved. A small number of instances and volumes still impaired, with AWS working directly with those customers.
Total duration: approximately 28 hours.
Why This Took So Long
You might wonder, if it's just a cooling problem, why did it take over a day to fix?
Data center cooling isn't like turning on a fan. These facilities use industrial chilled water systems, cooling towers, and complex thermal management infrastructure. When that fails, you can't just flip a switch. You need to bring capacity back online carefully and in a controlled manner, or you risk damaging hardware that's already been stressed by heat.
AWS was explicit about this in their updates. They repeatedly said they were taking "measured steps" and bringing things back "in a controlled and safe manner." Rushing the recovery could have made things worse.
The Bigger Question: One Data Center, One AZ?
Here's something interesting. AWS said the thermal event happened in "a single data center." But the impact was across the entire use1-az4 availability zone.
An availability zone is supposed to be made up of multiple data centers. So how does one data center's cooling failure take down an entire AZ?
A few possible explanations. Multiple data centers within the same AZ can share physical infrastructure like cooling plants, especially if they're on the same campus. A single chilled water system can serve multiple buildings through underground pipes. If that shared system fails, it doesn't matter how many buildings you have.
Another possibility is that AWS's definition of "single data center" covers a larger physical footprint than what we typically imagine. They don't publicly detail their exact topology, and for good reason.
Either way, it shows that within a single AZ, correlated failures are still very much possible.
What AWS Recommended
Throughout the incident, AWS kept repeating the same advice: if you need immediate recovery, restore from EBS snapshots or launch new resources in an unaffected availability zone.
That's solid advice, but only if you've set yourself up for it. If your architecture is single-AZ, if you don't have recent snapshots, if your recovery process isn't tested, you're stuck waiting or accept the data failure.
What This Means For You
This outage is a reminder of a few things that are easy to forget when everything is running fine.
Multi-AZ isn't optional. It's not a nice-to-have for "enterprise" workloads. If your application can't survive one AZ going down, you have a single point of failure sitting in your architecture right now.
Backups need to be tested. Having EBS snapshots is great. Knowing you can actually restore from them under pressure is better. When was the last time you tested a restore?
Understand what's under the hood. Your managed service whether it's EKS, ElastiCache, or Kafka runs on EC2 and EBS. When those go down, your managed service goes down too.
"Managed" doesn't mean "immune to infrastructure failures."
Physical infrastructure fails. We spend so much time thinking about software failures, bad deployments, and configuration errors. But at the end of the day, your code runs on hardware, in a building, that needs electricity and cooling.
Final Thought
28 hours is a long time. This might be the longest single-AZ outage in recent AWS history. The October 2025 us-east-1 outage lasted about 15 hours and people called it the worst in a decade. This one nearly doubled it.
AWS will publish a post-incident review eventually. When they do, it'll be worth reading carefully. But the lesson is already clear: design for failure, because failure will find you. Sometimes in the form of a cooling system that stops working on a Wednesday afternoon.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article