A Year of AWS Outages: Why Multi-Region Is Still Hard, Even With AI

You probably already know that us-east-1 is the least reliable major AWS region by a wide margin. I personally didn't expect it to be nearly 3x worse than the second-worst region.

StatusGator publishes an annual outage report built from real status page data (instead of vendor marketing). The 2025 numbers for AWS are hard to argue with, and 2026 has already added three more data points that make the case even stronger.

This post walks through both, then gets into why multi-AZ alone still isn't enough, why multi-region is still genuinely hard to build, and why none of the AI tooling flooding this space has changed that significantly.

The 2025 Numbers, From StatusGator

us-east-1 had 10 major outages in 2025, adding up to almost 34 hours of total downtime across 126 affected components. The second-worst region, Stockholm (eu-north-1), had about 12 hours. That's not a small gap, but close to 3x.

If you were running heavy compute workloads on EC2, ECS, or EMR, you likely felt this the most. Those services concentrate in us-east-1 more than most, partly because it's AWS's oldest and largest region, and partly because new features still land there first.

The part that's easy to miss: "regionless" outages, the ones that hit a global service or control plane rather than one specific region, were unusually high too. 12 incidents, 32 hours of downtime.

That's almost as bad as us-east-1 itself, and a multi-region setup does nothing to protect you from it if the failure is in IAM, Route 53, or another global control plane.

The headline event of the year was the October 20 us-east-1 incident. If you run production workloads there, you remember exactly where you were.

Here's the full regional breakdown from StatusGator's 2025 report, sorted by how often each region actually went down:

Two things jump out.

1. N. Virginia had the most total downtime, but "regionless" incidents, the ones tied to no single region, actually had more individual outages, 12 versus 10.
2. Most regions on this list had exactly one outage all year.

Below the top two rows, 2025 was a genuinely quiet year for AWS regional reliability. That's what makes N. Virginia's number so lopsided: it's not that AWS regions fail constantly, it's that this one specific region fails constantly.

Here's the worst, a European region, and the best, side by side.

Each bar is a 52-week view of the year, one segment per week, colored in if that region had a reported outage during that week. Outage counts and downtime hours are the exact StatusGator 2025 figures; the week position within the bar is illustrative, not the real calendar week.

2026 Didn't Slow Down

We wrote this post expecting the 2025 numbers to be the whole story. They aren't.

• January 28: eu-west-1 (Ireland): a region-specific incident lasting about 5 hours and 5 minutes.
• March 1: me-central-1 (UAE): an AZ hit by a genuinely unusual failure mode. AWS reported that objects struck the data center, creating sparks and fire. Not a software bug or a bad deploy to be fair. A physical event that took out compute in that AZ.
• May 7-8: mass outage: 2,370 status changes across 748 monitored services in under seven hours, with more than 150 cloud services affected.

None of these are cherry-picked. They're the three biggest AWS-related incidents StatusGator logged in the first five months of 2026, and they span three different failure classes: a regional incident, a physical AZ-level event, and a mass multi-service outage.

The pattern from 2025 didn't stop. It kept going.

Multi-AZ Is the Floor, Not the Answer

"We're multi-AZ, so we're fine" is one of the most common false-confidence statements in cloud architecture.

Multi-AZ protects you against exactly one thing: a single availability zone going down. Power loss, network partition, or even (as March 2026 proved) a literal fire. If your workload spans two or three AZs in the same region with automatic failover, that class of failure is a non-event.

What multi-AZ does not protect you against:

• A regional control-plane issue that affects every AZ in the region at once.
• A "regionless" outage in a global service like IAM or Route 53.
• The kind of cascading, multi-service event we saw in May 2026, where the blast radius crossed region boundaries entirely.

Multi-AZ is table stakes. It's the floor you build on, not the ceiling you're aiming for. Treating it as the finish line is how teams end up surprised when the outage that takes them down isn't the one they built resilience for.

Why Multi-Region Is Still Hard

If multi-AZ is table stakes, why doesn't everyone just go multi-region?

Because the honest answer is that multi-region is still one of the hardest things to get right in cloud architecture, and no amount of AI-assisted coding has changed that.

• The data layer is the real problem: DynamoDB Global Tables and Aurora Global Database both give you cross-region replication, but neither removes the underlying trade-off: replication lag means the region you fail over to might be seconds or minutes behind. For some workloads that's fine. For anything involving money, inventory, or state that must not diverge, it's a design problem you have to solve explicitly, not a checkbox you tick.
• Failover ordering is unforgiving: Which services come up first in the new region? What happens to in-flight requests when you cut over? Get the ordering wrong and you don't get downtime, you get data corruption, which is worse.
• DNS and traffic shifting only work if you've tested them under load: Route 53 health checks with latency-based or failover routing are the standard pattern, and they work. But a health check that hasn't been tested against a real regional failure is a hope, not a plan. (We've written about the Route 53 failover pattern in detail if you want the implementation walkthrough.)
• Game days beat documentation: The teams that actually survive a regional outage are the ones who have simulated one on purpose, on a random day, and watched what broke. A runbook nobody has executed is 100% worthless. Trust me.

Here's the part that surprises people: none of this got (much) easier with AI coding assistants.

Writing the Terraform for a second region was never the hard part. The hard part was always the distributed systems problem underneath it, replication semantics, failover ordering, testing discipline, and an AI that writes correct-looking infrastructure code doesn't make a genuinely difficult distributed systems problem simpler. If anything, it makes it easier to ship a multi-region setup that looks complete and has never actually failed over quietly.

That's the hard truth.

What Actually Works

The pattern itself isn't complicated. Route 53 health-checks the primary region and fails traffic over to the secondary on a bad check, while the data layer replicates in the background so the secondary region isn't starting cold. Inside each region, the containers themselves are spread across three AZs, not parked in one, because a region-level failover setup that quietly runs single-AZ underneath defeats half the point.

Worth calling out: both of those hops, container-to-container across AZs inside a region, and the replication link across regions, are exactly the kind of traffic that's easy to get wrong and expensive to get wrong quietly. Cross-AZ data transfer isn't free, and it doesn't page anyone when it spikes. We went deep on that specific problem, and how a Kubernetes cluster can drift into it without anyone noticing, in Networking Is Still Hard. Same rule applies one level up: cross-region traffic is the same trap, just with a (much) bigger bill attached.

What's hard is everything underneath that one diagram: the replication lag, the failover ordering, and actually testing it.

Full active-active, multi-region for everything, is expensive and most teams don't need it.

A tiered approach is more realistic:

• Tier 1 (revenue-critical, can't-be-down): full multi-region, tested failover, accept the operational cost.
• Tier 2 (important but tolerant of a short outage): multi-AZ, with a documented and manual failover plan for the rare regional event.
• Tier 3 (internal tools, non-critical): multi-AZ is enough. Don't over-engineer this tier just because the tier 1 postmortem was scary.

The mistake isn't picking multi-AZ for tier 3 workloads, but rather not deciding which tier something is in, and finding out during an actual outage.

The Trade-off, Stated Plainly

us-east-1 is convenient for multiple reasons: new features launch there first, most tutorials assume it, and a huge share of the ecosystem defaults to it without thinking.

It's also the least reliable major AWS region by a wide margin, three years running if the 2026 data holds the pattern.

That's not an argument to panic-migrate everything out of us-east-1 tomorrow. It's an argument to make the trade-off on purpose instead of by default. Multi-region isn't a technical decision you can delegate to an AI coding assistant or a Terraform module. It's a business decision about how much downtime you can actually afford, made with real numbers instead of vibes.

The data says the regional outages aren't slowing down either. Plan like it.