The numbers behind the Amazon Web Services outage in US-EAST-1 are still settling. Service credits are generally governed by service-specific SLAs, and the available sources do not confirm a specific credit for this incident.
This wasn’t a one-off, and it wasn’t even the only warning sign in between. It was the second time in seven months that a failure inside US-EAST-1, AWS’s oldest and largest region, cascaded into a multi-company outage that made national news. A DynamoDB DNS bug did it first, in October 2025, a failure that network-intelligence firm Ookla measured at more than 17 million user reports spanning upwards of 60 countries, with disruption reaching more than 3,500 companies worldwide. A data center thermal event did it again in May 2026, this time for physical rather than software reasons. In between, the same region kept stumbling on a smaller scale: a CloudFront DNS failure on February 10, 2026 cascaded into problems across eight AWS services and took roughly six hours to clear, according to outage tracker IsDown, while separate US-EAST-1 CloudWatch metrics delays on February 11 and February 25, 2026 left engineers flying blind for anywhere from about one hour to nearly three hours at a stretch, per IsDown.app. The pattern continued into summer: a CloudFront 5xx outage on July 16-17, 2026 combined with a fresh DynamoDB DNS issue to disrupt 37 services over roughly four hours, according to an analysis from NoCode.tech, and that same July an AWS billing console defect briefly displayed one customer a usage fee of $825,850,000,616.00, with Gigazine reporting AWS was targeting a fix by July 19, 2026. Between the headline incidents sits a question the cloud industry keeps asking with less patience each time: how much of the internet can keep depending on one region in Virginia, and what happens to the companies caught in the blast radius when it fails.
The AWS outage history now includes two headline-grade US-EAST-1 failures in under a year. What happened after the May incident, in SLA disputes, market share data, and enterprise disaster-recovery budgets, says as much about the state of cloud computing in 2026 as the outage itself.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Happened Inside AWS’s US-EAST-1 Region on May 7
AWS’s own health dashboard update, timestamped 5:25 PM PDT on Thursday, May 7 (00:25 UTC Friday), flagged trouble in a single availability zone: use1-az4. A thermal event had pushed temperatures in one data center hall past safe operating limits. Rather than risk permanent hardware damage, the affected servers did exactly what they were built to do. They shut themselves down.
That automatic shutdown is what showed up on customer dashboards as a power outage, though the real failure was a cooling system that had already given out. AWS explained the mechanics in a later update, once engineers had a fuller picture: servers “automatically shut down when the temperatures exceeded the operating thresholds in order to protect the hardware,” the company said, according to reporting from Network World.
That is a different failure mode than October’s software bug, and it changed how long recovery took. A bad DNS record can be patched in minutes once engineers find it. A data hall too hot to safely power back on has to be physically cooled first, and only then can racks come back online one at a time.
Why a Cooling Failure Takes Longer to Fix Than a Software Bug
The immediate damage hit Elastic Compute Cloud (EC2) instances and Elastic Block Store (EBS) volumes hosted on the affected hardware. From there, the failure spread sideways. Any AWS service that leans on EC2 or EBS in that zone started to wobble too, including IoT Core, Elastic Load Balancing, NAT Gateway, Redshift, ElastiCache, Amazon Managed Streaming for Apache Kafka, OpenSearch Service, and SageMaker. None of those services broke on their own. They broke because the compute and storage underneath them did.
That dependency chain is the real story of a hyperscale outage. A single overheated room in Virginia does not stay contained to that room. It climbs the stack into managed databases, message queues, and machine learning pipelines that customers rarely think of as living inside one physical building, until the building has a bad night.
The Recovery Timeline, Hour by Hour
AWS posted a string of updates through the night of May 7 into the afternoon of May 8. Pieced together, they show how slowly a physical failure unwinds compared with a software one.
- 5:25 PM PDT, May 7: AWS confirms increased error rates in US-EAST-1, tied to a thermal event in availability zone use1-az4.
- 6:47 PM PDT: AWS warns that other services depending on the affected EC2 instances and EBS volumes may also see impairments.
- 8:06 PM PDT: AWS concedes that “progress is slower than originally anticipated” and recommends customers restore from EBS snapshots or shift workloads to unaffected zones.
- 10:11 PM PDT: AWS reports incremental progress restoring cooling systems, though error rates and latency remain elevated.
- 6:51 AM PDT, May 8: AWS explains the thermal shutdown mechanism in detail for the first time.
- 1:50 PM PDT, May 8: Cooling capacity is stabilized back to pre-event levels, more than 20 hours after the first alert.
Even after cooling capacity normalized, some EC2 instances and EBS volumes stayed impaired while AWS worked through the backlog. Third-party outage trackers, which measure recovery differently depending on whether they count the first alert or full backlog clearance, put the total incident length anywhere from 19 hours to roughly 28 hours.
Who Got Hit: Coinbase, FanDuel and CME Group
Three companies absorbed most of the public attention, and timing made it worse for at least one of them. Coinbase had disclosed a 14% workforce reduction, around 700 employees, the Monday before the outage. On Thursday afternoon, just hours before the thermal event began, the company reported a first-quarter net loss of $394 million and a 31% year-over-year revenue decline. Then, that evening, its exchange went dark for roughly seven hours, taking trading, balance updates, Prime, its international venue, and its derivatives exchange down with it.
The irony is that most of Coinbase’s infrastructure is built for exactly this scenario. Its matching engine ran in a single availability zone by design, optimized for the low latency that trading demands. That tradeoff is common in finance, where microseconds matter more than redundancy, and it is precisely the kind of workload a regional AWS failure is built to expose.
FanDuel went offline around 9 PM ET, just as Game 2 of the NBA’s Lakers-Thunder semifinal series was tipping off, arguably the worst possible window of the week for a sportsbook to lose its platform. Users could not cash out live bets, and social media filled with screenshots and refund demands within the hour. CME Group’s CME Direct, an institutional trading venue, logged login and latency errors of its own. For a regulated derivatives exchange, even a short disruption raises compliance questions that go beyond a customer refund.
The impact reached past the household names, too. KoboToolbox, a data-collection platform widely used by humanitarian and development organizations, saw its global instance go offline at 00:32 UTC on May 8 because of the AWS infrastructure failure, while its separate EU instance kept running. Multiply that pattern across every mid-size company running production workloads in use1-az4, and the actual footprint of the outage was almost certainly wider than the handful of brands that made headlines.
Why US-EAST-1 Keeps Breaking: Concentration Risk, Explained
US-EAST-1 is not just another AWS region. It is the oldest one, the largest one, and for years it has been the default choice for developers spinning up new accounts. That history created a dependency problem that goes beyond any single customer’s architecture choices. Identity and Access Management authentication, CloudFront, Route 53, and DynamoDB Global Tables all lean on US-EAST-1 endpoints, even for resources that technically live in other regions, a fact AWS itself confirmed publicly during the October 2025 incident.
That is what analysts mean by concentration risk. A company can run a picture-perfect multi-region architecture across us-west-2 and eu-west-1 and still get pulled into a US-EAST-1 outage, because the control plane for identity and DNS routing quietly assumes Virginia is available. AWS is far from the only hyperscaler with global dependencies baked into its architecture, but its scale means a bad night in one Virginia data hall has an outsized reach compared with a similar failure at a smaller provider.
The May outage also wasn’t AWS’s only regional incident this year. AWS’s own Health Dashboard had already flagged trouble in the same corner of the internet weeks earlier, acknowledging CloudFront DNS issues at 21:15 UTC on February 10, 2026, according to StatusGator, and by February 16, 2026 Downdetector’s AWS outage reports spiked from around 15 to nearly 100 within minutes, Dataconomy Media reported. AWS added another entry to that list two months later: a CloudFront VPC origins outage in July 2026 ran roughly 3.5 hours, about 15% of a business day for affected customers, according to outage-cost tracker OutageCost, which estimated a business earning $1 million a day would have faced roughly $146,000 in exposure over that window. A separate disruption hit the US-WEST-2 region earlier in 2026, and rival Google Cloud has had its own regional problems, including an outage in India tied to a data center fire in Delhi. Multi-cloud does not automatically solve concentration risk. It just relocates it.
The SLA Credit Math: AWS Refunds 10%, Customers Eat the Rest
Here is the part of the story that keeps showing up in customer complaints after every major cloud outage. AWS’s standard EC2 service level agreement pays a tiered credit: roughly 10% of the monthly compute spend tied to impacted instances once uptime slips below 99.99%, rising to about 30% if uptime falls below 99%, according to a 2026 breakdown from outage-tracking firm OutageCost. Even the higher tier only touches the affected compute spend, not the customer’s entire AWS bill. It does not cover lost revenue. It does not cover regulatory exposure. It does not cover the customer trust that evaporates when an app goes dark during a playoff game or a trading session.
Independent research suggests that gap is large. The 2024 ITIC Hourly Cost of Downtime survey found that 90% of mid-size and large enterprises lose more than $300,000 for every hour of downtime, and 41% lose between $1 million and $5 million per hour. Run that math against a seven-hour outage at a company the size of Coinbase, and a 10% credit on a slice of the compute bill starts to look less like compensation and more like a rounding error. Those industry-wide averages track closely with what analysts pinned on the October 2025 DynamoDB outage specifically: research firm Tenscope estimated Amazon itself lost roughly $72,831,050 for every hour that incident ran, while other affected companies collectively lost closer to $75 million an hour, according to Yahoo Finance’s October 2025 reporting — a range consistent with CyberCube’s own estimate that insured losses from the October incident fell somewhere between $38 million and $581 million.
None of this is unique to AWS. Every major cloud provider’s SLA works the same way: a small, capped refund tied to compute spend, not a business-continuity guarantee. The difference is that AWS’s scale means that when its SLA gets tested, it gets tested in front of a much larger audience.
AWS Outage History: May 2026 vs. the October 2025 DynamoDB Failure
The May thermal event was not US-EAST-1’s first brush with infamy. Seven months earlier, on October 19 and 20, 2025, the same region went down for a very different reason. AWS traced that failure to DynamoDB: “The root cause of this issue was a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record for the service’s regional endpoint (dynamodb.us-east-1.amazonaws.com) that the automation failed to repair,” the company said in its post-incident summary, which put the total outage window at 14.5 hours.
That DNS failure cascaded across more than 70 AWS services and took down Snapchat, Slack, Atlassian, Reddit, Coinbase, and Robinhood, among others, disrupting, in the BBC’s words, “millions” of businesses that rely on AWS worldwide, a scale outage-cost tracker OutageCost later pegged more precisely at roughly 70,000 organizations affected, a figure risk modeler CyberCube corroborated while adding that more than 2,000 large enterprises were among those hit. Ookla’s Downdetector data showed Snapchat logging about 3M outage reports on October 20, 2025, the highest among tracked services, ahead of AWS itself at about 2.5M, Roblox at roughly 716K and Amazon retail at approximately 698K. AWS’s own mitigation window ran from 11:49 PM PDT on October 19 to 2:24 AM PDT on October 20, about four hours and 35 minutes, though the broader downstream recovery stretched closer to 15 hours (IBTimes, writing in April 2026, said the outage lasted up to 15 hours in some cases), with services returning to normal shortly after 6 p.m. ET on October 20, 2025, according to CNBC, and AP News put the global DNS failure’s full resolution at roughly 13 hours. Side by side, the two incidents make an uncomfortable pair.
| Metric | May 7-8, 2026 (Thermal Event) | October 19-20, 2025 (DynamoDB DNS) |
|---|---|---|
| Root cause | Data center cooling failure, thermal shutdown in availability zone use1-az4 | Latent race condition in DynamoDB’s automated DNS management system |
| AWS-measured recovery window | Roughly 20 hours to restore cooling to pre-event levels | 4 hours 35 minutes to mitigation |
| Full recovery estimate (third-party trackers) | 19 to roughly 28 hours | Roughly 15 hours including downstream tail |
| Scope | Single availability zone, hardware-level | Region-wide DNS failure hitting global dependencies |
| Services affected | EC2, EBS, ELB, IoT Core, NAT Gateway, Redshift, ElastiCache, MSK, OpenSearch, SageMaker | 70+ AWS services, per reporting |
| Named companies affected | Coinbase, FanDuel, CME Group, KoboToolbox | Snapchat, Slack, Atlassian, Reddit, Coinbase, Robinhood |
The pattern is hard to miss. Two different root causes, one physical and one in software, produced two similarly disruptive outcomes in the same region within seven months. That repetition is exactly what shows up in the AWS outage history and gets cited every time a CTO argues for a bigger multi-region budget.
AWS vs. Azure vs. Google Cloud: Who Actually Controls the Cloud in 2026
Here is the part that should frustrate anyone hoping outages move market share. According to Synergy Research Group’s Q1 2026 estimates, AWS still led global cloud infrastructure spending with 28% share and roughly $36.1 billion in quarterly infrastructure spend, ahead of Microsoft Azure at 21% and Google Cloud at 14%. Total worldwide cloud infrastructure services spending reached $129 billion for the quarter. Despite two headline US-EAST-1 failures bookending the seven months between October 2025 and May 2026, AWS did not lose its lead.
| Provider | Q1 2026 Market Share | Est. Quarterly Infrastructure Spend | 2025-2026 Outage Note |
|---|---|---|---|
| AWS | 28% | ~$36.1 billion | Two headline US-EAST-1 failures (October 2025, May 2026) |
| Microsoft Azure | 21% | ~$27.1 billion | No major outage surfaced in available reporting for the same window |
| Google Cloud | 14% | ~$18.1 billion | A 2026 data center fire in Delhi disrupted a regional zone |
| All other providers combined | 37% | ~$47.7 billion | Includes Oracle Cloud, Alibaba Cloud, IBM Cloud, and smaller regional clouds |
The takeaway is not that AWS is uniquely unreliable. Every hyperscaler has had regional incidents. The takeaway is that reliability, so far, is not what determines cloud market share. Switching providers means re-architecting applications and renegotiating contracts that often run for years, so frustration after an outage rarely translates into a migration big enough to move a share number AWS has held for years. Demand is pointing the same way: on October 23, 2026, Amazon CEO Andy Jassy said AWS capacity was largely sold out through 2027, with significant commitments extending into 2028, driven by AI infrastructure demand.
What Engineers and Analysts Are Saying
Reaction to the May outage split along familiar lines: relief that recovery eventually finished, and irritation that this keeps happening in the same place. StatusGator, which tracks cloud service status across providers, put it bluntly in its analysis of the region’s track record: “N. Virginia (us-east-1) is once again the least reliable AWS Region.”
That view is not confined to monitoring vendors with an incentive to sell more monitoring. In a Hacker News thread that gathered hundreds of comments during the outage, one commenter summed up the recurring pattern: “AWS us-east-1 has a major incident affecting multiple services (that affect most downstream aws services) multiple times a year.” On LinkedIn, tech commentator Mavrukin made a similar point in blunter terms, writing: “us-east-1 was a liability 10+ years ago when I first used aws, it was a liability 5 years ago, and it’s a liability today.”
None of that commentary is new to anyone who has worked in cloud infrastructure for more than a couple of years. What changed after May 7 is the size of the audience nodding along, now that a crypto exchange, a sportsbook, and a derivatives platform have all gone down in the same week.
High Availability Isn’t Disaster Recovery
The most common lesson drawn from the May outage is also the most misunderstood one. Multi-AZ redundancy, which spreads workloads across multiple data centers within a region, protects against exactly the kind of single-building failure that happened on May 7. It does nothing for a region-wide event, and it would not have helped anyone whose application depends on global services that route through US-EAST-1 regardless of where the application itself runs.
AWS treats availability zones as the failure domain for high availability. Disaster recovery is a different problem, built around regions instead of buildings, and it only works if a team has explicitly configured a secondary region to take over. A thermal event in Virginia will not move a company’s data to Oregon on its own. A simple multi-region Terraform provider setup is one starting point for teams that haven’t mapped which resources are actually region-locked:
provider "aws" {
alias = "primary"
region = "us-east-1"
}
provider "aws" {
alias = "secondary"
region = "us-west-2"
}
resource "aws_db_instance" "primary" {
provider = aws.primary
# ... primary database configuration
}
resource "aws_db_instance" "replica" {
provider = aws.secondary
replicate_source_db = aws_db_instance.primary.arn
}That snippet won’t by itself make an application resilient. It only sketches the starting point: a cross-region replica that exists before the next thermal event, not after.
A Quick Region-Affinity Checklist
Cloud teams reassessing their exposure after the May outage tend to work through the same short list:
- Map which AWS region and availability zone each application tier actually runs in, including caches, queues, and object storage, not just the primary database.
- Confirm whether any “multi-AZ” service quietly depends on a US-EAST-1 global endpoint for identity, DNS, or configuration.
- Time a real failover drill instead of assuming one will work, since an untested runbook is a guess, not a plan.
- Compare the cost of cross-region replication against the hourly cost of downtime for the specific workload.
The Market Impact: What an Hour of Downtime Really Costs
Zoom out from any single company’s bad week, and the May outage lands inside a much larger spending story, and an even larger reliability one: IncidentHub’s H1 2026 reliability report tracked 30,246 separate outages across 1,082 providers between January and June 2026 alone, AWS included. Global cloud infrastructure spending hit $129 billion in the first quarter of 2026 alone, and a growing share of that money is going toward resilience rather than new features. Cross-region disaster recovery, once a line item mostly for banks and government contractors, is increasingly treated as standard insurance for any workload that cannot tolerate a multi-hour gap.
The economics are not subtle once the ITIC downtime figures are on the table. If a mid-size enterprise is losing $300,000 or more per hour during an outage, a cross-region replication setup that costs a few thousand dollars a month starts to look like the cheapest insurance policy the company owns. That math is a big part of why FinOps teams have started treating reliability spending as its own budget category, separate from the general cloud bill they are otherwise under pressure to shrink. Vendors selling cross-region failover, backup, and monitoring tools all pointed to the May outage in their own marketing within days of recovery.
Regulatory and Enterprise Scrutiny Ahead
CME Group’s brush with the outage matters more than a consumer app going dark for an afternoon. Regulated derivatives exchanges operate under rules that assume a baseline of platform availability, and even a short bout of login and latency errors on CME Direct raises compliance questions that a sportsbook outage does not. Financial regulators have spent the past two years paying closer attention to what happens when banks, exchanges, and payment processors all quietly depend on the same three cloud providers.
That scrutiny isn’t limited to the United States. Earlier in 2026, the UK named four cloud giants as critical third parties subject to direct oversight, a designation that comes with its own reporting and resilience requirements. A US-EAST-1 failure of this size gives regulators elsewhere a concrete case study for why similar rules might make sense for finance-adjacent cloud customers, even if AWS itself is never named directly in the rulemaking.
5 Predictions for Cloud Reliability After US-EAST-1
Based on how AWS, its customers, and its competitors have responded to the May outage so far, a few trends look likely to play out over the rest of 2026.
- Cross-region disaster recovery spending keeps growing. Expect vendors across the cloud database and backup markets to report higher adoption of multi-region failover products through the second half of 2026, using the May outage as their sales hook.
- AWS’s SLA terms stay under pressure but don’t change fast. The gap between a 10% compute credit and the real cost of downtime will keep showing up in customer complaints, but a structural rewrite of AWS’s SLA is unlikely before enterprise contracts come up for renewal.
- US-EAST-1’s global dependencies remain the harder problem to fix. AWS can harden individual data halls against thermal failures faster than it can re-architect the identity, DNS, and global table services built around US-EAST-1 as a default years ago.
- Market share stays roughly where it is. AWS’s share of the cloud market is unlikely to move much because of a single incident. Switching costs, not reliability records, remain the dominant force in cloud vendor selection.
- Regulators keep expanding hyperscaler oversight. More jurisdictions are likely to follow the UK’s lead in formally designating cloud providers as critical infrastructure, particularly for finance-adjacent workloads like the ones Coinbase and CME Group run.
Frequently Asked Questions
What caused the AWS US-EAST-1 outage in May 2026?
A cooling system failure inside a Northern Virginia data center pushed temperatures past safe operating limits in availability zone use1-az4. Affected servers automatically shut down to protect the hardware, knocking out EC2 instances and EBS volumes and cascading into dependent services like Redshift and OpenSearch.
How long did the AWS outage last?
AWS took roughly 20 hours to restore cooling capacity to pre-event levels, from 5:25 PM PDT on May 7 to 1:50 PM PDT on May 8. Third-party outage trackers put total recovery time between 19 and roughly 28 hours.
Which companies were affected by the AWS outage?
Coinbase, FanDuel, and CME Group were the most visible names affected, along with humanitarian data platform KoboToolbox. The actual footprint was likely wider, since any workload running in the affected availability zone could have been impacted.
How much money does AWS refund customers after an outage?
AWS’s standard EC2 service level agreement pays a credit worth about 10% of the monthly compute spend tied to impacted instances. It does not cover lost revenue, regulatory penalties, or reputational damage.
Is AWS’s US-EAST-1 region less reliable than other regions?
Monitoring firms including StatusGator have repeatedly ranked US-EAST-1 as AWS’s least reliable region based on incident frequency. Its age, size, and role as a default endpoint for global services like IAM and Route 53 make it more exposed to cascading failures than newer, smaller regions.
How does the May 2026 outage compare to the October 2025 outage?
Both hit US-EAST-1 within seven months of each other, but the causes differed. October 2025 was a software failure, a DNS race condition in DynamoDB. May 2026 was a physical failure, a data center cooling system that couldn’t keep pace with rising temperatures.
Should businesses move off AWS after repeated US-EAST-1 outages?
Most analysts frame this as a multi-region question rather than a multi-cloud one. Migrating away from AWS entirely is expensive and slow, and every major hyperscaler has had its own regional incidents. Architecting critical workloads across at least two AWS regions addresses most of the same risk at a fraction of the cost of a full migration.
How does AWS’s market share compare to Azure and Google Cloud in 2026?
AWS held 28% of global cloud infrastructure spending in the first quarter of 2026, ahead of Microsoft Azure at 21% and Google Cloud at 14%, according to Synergy Research Group. AWS’s lead has held steady despite its recent outage history.
