AWS had four separate outages in 2026. Multi-region would have caught exactly one.

Four AWS outages in 2026, four different postmortems

Between early May and late July 2026, AWS logged four separate incidents that took large parts of the internet offline for stretches ranging from eighty minutes to several hours. Coinbase and FanDuel lost trading functionality. HuggingFace, the UK National Lottery, and Tailscale went dark. Apple Pay, Reddit, Hulu, DoorDash, and PlayStation Network stopped responding on a Thursday morning. Four AWS outages in 2026, four postmortems, and the detail worth sitting with: four unrelated root causes.

That last detail changes what the right response actually is. Most disaster-recovery playbooks treat "the cloud provider had an outage" as a single risk with a short menu of standard mitigations: spread instances across availability zones, spread workloads across regions, add retries and circuit breakers at the client. Those mitigations were built for one specific failure shape, a facility or a region going dark, and they work well against it. They did nothing against the other three shapes AWS produced in the same eleven weeks.

May 7: a data center overheated, and multi-AZ did what it was built to do

On the evening of May 7, cooling capacity failed inside a single data center supporting the use1-az4 availability zone in Northern Virginia. Temperatures climbed, AWS shed load on the affected racks to protect the hardware, and the EC2 instances and EBS volumes hosted there lost power. ElastiCache, Managed Streaming for Apache Kafka, OpenSearch, and SageMaker workloads pinned to that AZ went down with them. Coinbase and FanDuel both reported disrupted trading while AWS brought supplemental cooling capacity online.

This is the outage shape almost every AWS architecture diagram is drawn to survive. A single facility failed; the blast radius stopped at the AZ boundary. Workloads that had already spread their EC2 fleet and stateful services across two or three AZs in the region rode through it without much drama. The ones treating an AZ as though it had the durability of a region were the ones stuck waiting on chillers.

The catch is that multi-AZ isn’t free, and teams that skip it usually skip it on purpose rather than by accident. Cross-AZ data transfer has a cost line item, replication adds latency, and a stateful service that needs synchronous writes across AZs pays for consistency on every request. May 7 was the incident that justifies paying that cost: it’s the one failure mode multi-AZ is specifically priced to solve, and where it existed, it worked.

June: the dependency wasn’t inside AWS at all

The next incident didn’t start inside an AWS facility. In June, a failure at a third-party network transit provider disrupted connectivity for a set of AWS-linked services, alongside a separate set of Cloudflare-linked services riding the same underlying transit. Nothing overheated. No AWS region went dark. The routing infrastructure a large share of the internet leans on for last-mile transit had a bad day, and customers who assumed "network path to AWS" meant "AWS’s network" found out otherwise.

Multi-AZ does nothing here. Multi-region inside AWS does nothing here either, if the shared transit provider sits upstream of every region a workload would fail over to. The only mitigation that touches this failure class is knowing which network providers actually sit between your users and your cloud provider, and having a second one — a question almost no standard DR runbook asks.

Most teams can name their cloud provider and their CDN. Far fewer can name the transit and peering providers those two actually route through, because that layer is normally invisible until it breaks. Answering it usually means asking your network or platform team a question they haven’t had to answer before: if this specific upstream provider went dark for an hour, which of our regions would still be reachable, and by which path?

July 16: a software limit, not a facility

Nine days before the next headline outage, CloudFront spent roughly three and a half hours failing to load routing configuration changes because of an internal connection-management limit. HuggingFace, the UK National Lottery, Tailscale, and Ubiquiti were among the services that went down or degraded. There was no hardware to point at and no data center that lost power. A software constraint inside AWS’s own control plane stopped configuration from propagating, and every service depending on CloudFront inherited the delay.

This is the failure class regional redundancy is worst at catching, because CloudFront is a global service layered above the region model, not a regional one. Failing over to a second AWS region does not help when the component that broke sits above the region layer entirely. CloudFront isn’t alone in that category either — Route 53, IAM, and STS are all global services most multi-region architectures quietly depend on without treating them as a separate point of failure.

July 24: routing hardware between a region and the outside world

Eight days after that, networking hardware carrying traffic between us-west-2 and the Seattle Metro area failed at 10:55 UTC. AWS’s automated systems engaged within six minutes, and initial connectivity began returning by 11:15. Direct Connect stayed degraded for an hour and seventeen minutes while routes reconverged, with intermittent flapping through late morning before AWS confirmed a full fix at 12:12 UTC. Direct Connect, Global Accelerator, API Gateway, EC2, ECS, Elastic Load Balancing, and VPC all showed impact. Nine downstream incidents were confirmed across seven providers; the slowest of them took more than nine hours to fully recover. On the consumer side, Apple Pay, Reddit, Hulu, DoorDash, and PlayStation Network were unreachable for roughly eighty minutes.

Multi-region would have caught this one, provided the failover path didn’t also route through the same physical connection between us-west-2 and Seattle. That "provided" is doing real work: plenty of architectures failing over from us-west-2 land on us-west-1 or us-east-1, which sidesteps this specific hardware. But it’s worth noticing that this is the only one of the four incidents where the standard playbook, spread across regions, applies cleanly.

Why "multi-region" catches one of four

AWS’s previous marquee incident, the October 2025 DynamoDB DNS race condition that took us-east-1 down for fifteen hours, had one root cause. It was a bad outcome from a single bug. The 2026 cluster is a different kind of signal: four incidents in eleven weeks that share no cause, no layer, and no fix. Lay them side by side and the pattern is that they don’t overlap at all.

Multi-AZ addresses the first category. A second network transit path addresses the second. Nothing in a standard architecture addresses the third except not depending on a single global control-plane component, which for most teams using CloudFront, Route 53, or IAM isn’t really optional. Multi-region, chosen with the physical failure in mind rather than just the logical one, addresses the fourth.

What changes in a resilience plan built for four failure classes

Three changes are worth making to a standard multi-AZ, multi-region checklist, none of which require a bigger infrastructure budget:

• Map the network path, not just the compute path. Ask which transit providers and DNS resolvers sit between users and the workload, and whether the two AWS regions in the DR plan still share one of them upstream. This is usually a half-day exercise with a traceroute and a call to whoever owns the network contract, not a re-architecture.
• Separate "AWS regional outage" from "AWS global control-plane outage" as two distinct failure modes in the runbook, since CloudFront, Route 53, IAM, and STS don’t fail over the way EC2 does. A runbook that only has one entry for "AWS is down" will send whoever is on call looking in the wrong place at 3 a.m.
• Write down, explicitly, which of the four failure classes the current architecture actually mitigates and which it has silently accepted as risk. Most teams have accepted three of the four without ever making that decision on purpose, which is a different thing from making it on purpose and being fine with the cost of leaving it uncovered.

Measuring readiness in failure classes, not nines

An SLA number describes how much downtime a provider promises to own. It says nothing about which of an organisation’s failure classes the next incident will fall into. Four outages in eleven weeks, four different root causes, is a more useful diagnostic than any uptime percentage: it’s a short list of failure shapes worth being able to name before the next one arrives with a service’s own name in the headline instead of somebody else’s.