AWS logs four incidents in four months, two on the same network path

July 24, 2026, 7:40 a.m. ET. Outage trackers lit up at once: Apple Pay, DoorDash, Reddit, Hulu and the PlayStation Network all stopped responding. The common thread was AWS’s US-WEST-2 region in Oregon, where an internet connectivity problem spilled over onto a slice of the consumer web. In early August 2026, a second incident hit the same network path. That makes four notable AWS incidents in four months — and the signal is less the count than the repetition of a single point of failure.

For an SRE or CISO running production in us-west-2, this is no longer an anecdote. It is a recurring pattern that changes how single-provider risk gets discussed in planning meetings.

July 24, minute by minute

The first reports hit Downdetector shortly after 6:40 a.m. ET. AWS acknowledged the problem at 4:40 a.m. PT, confirming it was investigating connectivity to US-WEST-2. By 8:01 a.m. PT, the company said it had identified the root cause; by 8:14 a.m. PT, US-WEST-2 was restored, four minutes after US-WEST-1 came back. Around 9 a.m. ET the disruption was over — roughly 80 minutes in total.

AWS classified the event as “impaired,” its designation for a visible incident that does not take a region fully offline. Ten offerings were named in its status updates: Direct Connect, Global Accelerator, Internet Connectivity, IoT Core, Site-to-Site VPN, API Gateway, EC2, ECS, ELB and VPC. None is a consumer product, but all sit underneath other companies’ applications — which is exactly why a backend incident became headlines about Reddit and Hulu going dark.

IncidentHub’s independent tally recorded 9 cascade incidents across 7 providers tied to the outage. AWS said no customer data was lost and did not attribute the event to a cyberattack.

A named cause, an undecided common cause

AWS’s public language for July 24 was more specific than a bare “connectivity issue”: an internet connectivity and networking hardware problem on the route linking US-WEST-2 to the Seattle metro area. The company did not say which hardware failed, or whether the fault lay in its own network or further out on the path to Seattle.

That is thinner disclosure than May 2026, when AWS identified a chiller hardware failure in a Northern Virginia datacenter, and far thinner than the detailed writeup published after the October 2025 incident, which named the exact subsystem (DynamoDB’s DNS management) and the failure mode — a race condition between two automated DNS “Enactors” in different availability zones.

In early August 2026, AWS pointed to the same network path during a second, shorter US-WEST-2 incident. Support said on X that it was resolved between 3:55 a.m. and 4:15 a.m. PT — 20 minutes — followed by a brief reconvergence event with intermittent routing from 4:47 a.m. to 4:59 a.m. PT. AWS again named the networking devices carrying traffic from the region to Seattle. The company has not confirmed whether the two incidents share a root cause or are separate failures on the same stretch of infrastructure.

Four incidents, four different layers

Lining up AWS’s 2026 incidents reveals a pattern that is less about the count than about the variety of layers involved.

May was a physical infrastructure problem: a chiller failure in a single availability zone. June sat one layer up, in third-party infrastructure tied to Zayo. July and August point to a third layer entirely: the internet-facing networking hardware carrying traffic between US-WEST-2 and Seattle.

That layer distinction matters more than a raw incident count. A chiller failure and a network fault on the same route call for different mitigations: physical redundancy fixes the former, while network-path diversity or a secondary egress path out of US-WEST-2 fixes the latter. Treating “four incidents” as one undifferentiated reliability problem risks aiming budgets at the wrong fix. Treating July and August as a two-incident cluster on the same network path is a narrower, more actionable finding — and the one AWS’s own public statements support most directly.

Why us-west-2 and us-east-1 concentrate the risk

Almost every one of AWS’s most disruptive incidents over the past decade traces back to two regions: US-EAST-1 (Northern Virginia) and, now, US-WEST-2 (Oregon). That is not a coincidence. US-EAST-1 is the original region, launched in 2006, still the default for countless applications and home to control-plane functions other regions quietly depend on. US-WEST-2 carries a similar concentration on the west coast, favored for latency to Asia-Pacific and picked years ago as a secondary region by companies that never left.

Reliability teams have pushed multi-region architectures for years because of this concentration. The brake is cost: active-active across two regions roughly doubles data transfer and operational overhead for many workloads, which is why so many companies — including billion-dollar ones — still run critical services out of a single region. Cost-visibility tooling can price that redundancy before anyone commits.

What the market does not show yet

None of these incidents has dented AWS’s position in any way visible in the numbers. In Q1 2026, AWS still held 28% of global cloud infrastructure spending per Synergy Research Group, ahead of Azure (21%) and Google Cloud (14%). Enterprise cloud infrastructure spending hit $129 billion in Q1 2026, up 35% year-over-year, largely on AI workload demand.

Azure and Google Cloud are growing faster in percentage terms — 40% and 63% versus AWS’s 19% — but that is a story of smaller bases catching up, not of customers fleeing AWS over an 80-minute incident. Cloud contracts run for years and migration costs are steep. What is changing is the tone inside enterprise teams: four incidents in four months is enough to justify a line item next quarter for disaster-recovery testing, multi-region failover drills, or at minimum a fresh audit of which production workloads still have a single point of failure.

Verdict

The “four incidents in four months” number is a calendar artifact; the durable signal is the July-August cluster on the same network path linking US-WEST-2 to Seattle, which AWS still has not tied to a common cause. That specific point is what should drive your decisions.

If your production runs single-region in us-west-2, you are exposed to a point of failure that multi-AZ does not cover: when the region’s internet connectivity itself fails, spreading instances across availability zones buys you nothing. Plan for one of two options — a documented, tested multi-region failover for critical services, or at minimum a diversified egress path off the Seattle route. If you are already multi-region, your next action is simpler: verify that your failover plan does not, itself, rely on a single network route into US-WEST-2.

Single-region comfort is now paid for in probability, not assumption: two failures on the same stretch in a month is a pattern, not a coincidence.

References

• Tech Insider, “AWS Outage Hits US-West-2: 4th Incident in 4 Months”, updated August 2026.
• AWS Health Dashboard, status updates of July 24, 2026.
• IncidentHub, July 24, 2026 cascade incident tally.
• Synergy Research Group, Q1 2026 cloud infrastructure market share.
• AWS, “Summary of the October 19, 2025 Amazon DynamoDB Service Event”, message 101925.