AWS Outages: What Multi-AZ Does and Does Not Protect

Multi-AZ protects against some failures within a cloud region, but it may not protect a service from shared regional network failures. The reported us-west-2 outage illustrates why redundancy must match the failure being planned for. The public reports do not establish the architecture of every affected company.

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 Multi-AZ alone may not cover this kind of regional connectivity failure.

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.

The reports identify a connectivity fault; they do not prove every customer’s compute and storage stayed healthy. A server can keep running and answering local queries while users outside the region cannot reach it.

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 AZs can still depend on shared regional network and service components. That's the boundary that failed on July 24 — not between two AZs, but between the region and everything outside it. Multi-AZ helps isolate failures in one location. It may not preserve access when the failed component is shared across the regional paths your application uses.

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. The public reports do not establish which isolation boundaries every affected company relied 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). That recent history supports planning for failures; three incidents do not establish the frequency of future outages.

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). Assess those needs against your own business requirements rather than assuming every business needs multi-region.

Use business requirements and failure scenarios to decide how much redundancy is justified.

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 — an active-active design can approach doubling the infrastructure spend; standby designs have different costs, 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." Estimate its hosting cost and setup effort for the chosen provider. It won't process a single order. It gives customers a way to distinguish an acknowledged outage from an abandoned service.

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.

A first version can be brief; its effort depends on the number of systems and unknown dependencies. It's the part almost nobody does before the outage, and the part everybody wishes they'd done during it.