Multi-AZ Is Not Multi-Region: Lessons From the us-west-2 Outage

Multi-AZ Is Not Multi-Region: Lessons From the us-west-2 Outage

Every company hit by the us-west-2 outage almost certainly ran multi-AZ. None of it helped. That's the whole lesson: AZ redundancy solves a different problem than the one that took them down.

On July 24, 2026, a piece of networking hardware failed inside AWS's us-west-2 region in Oregon. Reddit went dark. DoorDash stopped taking orders. Hulu wouldn't load. Apple Pay declined transactions. PlayStation Network dropped players mid-match.

AWS's own timeline puts the primary connectivity fault at around twenty minutes. Other reporting puts the customer-visible disruption closer to eighty minutes, once you count everything downstream still trying to reconnect an hour later (Tech Times).

The easy story is "the cloud went down" — comfortable, because it puts the failure outside anyone's control. It's also the wrong lesson for your own redundancy planning. One distinction explains why AZ redundancy didn't save any of those companies that morning.

What actually broke

AWS attributed the fault to networking hardware carrying routing between the region and the Seattle Metro area — the link between us-west-2 and the wider internet, not a fault inside any specific data hall (IncidentHub). The primary impact window ran roughly 10:55 to 11:15 UTC and touched Direct Connect, Global Accelerator, general internet connectivity, IoT Core, Site-to-Site VPN, API Gateway, EC2, ECS, ELB, and VPC.

Compute and storage inside the region stayed healthy the entire time. Servers were up. Databases answered queries. They just couldn't talk to anyone outside the building.

For a consumer-facing service, that distinction doesn't exist. Reddit's servers being fine while nobody can reach them looks exactly like Reddit being down.

AZs solve a different problem than this one

Picture branch warehouses built far apart on purpose, so a fire in one doesn't spread to the next. That's exactly why AWS builds Availability Zones: to survive shared-fate physical events — utility power loss, water disruption, fiber cuts, earthquakes, fires, floods. AZs within a region sit up to roughly 60 miles apart for that same reason (AWS Fault Isolation Boundaries).

But every AZ in a region still reaches the internet through that region's own shared transit infrastructure. That's the boundary that failed on July 24 — not between two AZs, but between the region and everything outside it. Multi-AZ protects you from losing one building. It does nothing when the region's front door jams, because every AZ behind that door is equally stuck.

Region-to-region is a separate boundary again, and it held: us-east-1 and every other AWS region kept running normally while us-west-2 was cut off. That's regional isolation working exactly as designed. It just wasn't the isolation any of the affected companies were actually leaning on.

The recovery tail nobody plans for

Twenty minutes sounds survivable, and for plenty of businesses it would be. What made this incident worse than its headline number is the tail. SendGrid failed over and was back within about six minutes of routing being restored. NinjaOne took roughly nine and a half hours to clear a backlog of around 150,000 devices all trying to reconnect at once (IncidentHub).

Same root cause, wildly different recovery times. Failover speed and backlog-drain speed are two different engineering problems. Most teams only design for the first one.

This was also AWS's third notable reliability incident in about three months (Tech Times). At this scale, regions and networks fail more than once a quarter. That's a fact to plan around, not a scandal to be surprised by.

What AWS itself says the default should be

Here's the part that surprises most SME owners: AWS does not recommend multi-region as the default. Its Well-Architected Framework names "implementing multi-Region when multi-AZ would satisfy business requirements" as an anti-pattern. Multi-region is reserved for workloads that need extreme resilience — critical infrastructure, health systems, contracts with uptime guarantees a single region can't promise (AWS Well-Architected Framework). For most businesses, that's not you, and AWS says so in its own documentation.

That's not permission to do nothing. It's permission to size the response to the actual risk instead of over-building because a headline scared you.

What multi-region actually costs

If you genuinely need it, know what you're buying. AWS's own guidance spells it out: duplicate infrastructure and data services in a second region, replicate machine images and containers. Add cross-region data replication — DynamoDB global tables, or primary/read-replica pairs for RDS and Aurora. Set up DNS failover on Route 53 health checks or AWS Application Recovery Controller (AWS Well-Architected Framework).

Two of everything, kept in sync, monitored twice. Someone on the team has to understand both halves well enough to fail over under pressure at 3 a.m. For a business running one production workload, that's not a configuration change — it's close to doubling the infrastructure spend, plus a permanent operational habit of keeping two regions from drifting apart. Most SME teams don't have the headcount to sustain that well.

I've priced this out for clients who flinch at the number and, reasonably, ask if there's a cheaper way to buy the same peace of mind.

When a static page is the right answer instead

For most SMEs, there is. Work out what the business genuinely can't survive. It's rarely "twenty minutes of full outage." It's usually "customers think we've shut down" or "we have no way to tell anyone what's happening."

A static status page — hosted on a different provider, or at minimum a different region from production — carries a phone number and a plain "we know, we're on it." It covers that scenario for a few dollars a month and an afternoon of setup. It won't process a single order. It will stop a twenty-minute network fault from reading as a company that quietly went out of business.

That's the sizing exercise AWS is already pointing you toward: match the redundancy spend to what actually breaks the business, not to what happened to Reddit.

Start with a dependency map, not an architecture decision

Before deciding multi-AZ is enough or multi-region is warranted, write down every third-party service that can take your business down if it goes dark: payment processor, SMS or email provider, cloud region, DNS, CDN. For each one, note where its status page lives and what your actual fallback is. A single point of failure hiding in a vendor nobody thinks about causes more bad days than the architecture decisions everyone agonizes over.

That map takes an afternoon. It's the part almost nobody does before the outage, and the part everybody wishes they'd done during it.