AWS us-west-2 Outage: Seattle Network Fault Returns

Amazon Web Services has again lost connectivity between its us-west-2 region in Oregon and the Seattle Metro, a short but pointed disruption that traced back to the same network path AWS blamed for a larger outage in July. The incident was brief — a roughly 20-minute window followed by a shorter reconvergence event — but the repeat nature is the story. It is the fourth notable reliability event in AWS’s core infrastructure since May, and it landed on the exact link the company said it had already diagnosed.

For most workloads the impact was measured in minutes, not hours. For the teams whose traffic runs through that corridor — particularly customers using AWS Direct Connect into Seattle-area facilities — it was the second time in about a month that a single stretch of networking hardware took them offline.

What happened

By AWS’s own timeline, the connectivity issue in us-west-2 was resolved between 3:55 a.m. and 4:15 a.m. PDT, a window of about twenty minutes. That was followed by a brief reconvergence event — the period when routers rebuild their view of the network and settle on new paths — that caused intermittent routing problems from 4:47 a.m. to 4:59 a.m. PDT before all routes were fully restored.

AWS pointed to the networking devices that route traffic between the region and the Seattle Metro as the source. That is the same characterization the company gave for the July 24 outage, when it lost connectivity between us-west-2 and Seattle and left most affected customers down for about twenty minutes — but stretched to more than an hour for a subset routing through Direct Connect at the Westin Building Exchange, one of the Pacific Northwest’s densest interconnection points. Two incidents, weeks apart, attributed to the same corridor.

The technical scope was narrow. This was not a region-wide collapse of compute or storage; it was a routing fault on a specific path. But narrow faults in shared network fabric radiate, because everything downstream of the broken link fails at once regardless of how resilient each individual service is.

Why us-west-2 matters

us-west-2 is not a secondary region. It is one of AWS’s oldest and most heavily used, a default home for a large share of West Coast startups, data pipelines, and multi-region deployments that pin a primary there. When it wobbles, the blast radius is wide even for a short outage, because so many architectures treat it as an anchor.

The Seattle Metro connection is load-bearing for a specific reason: it carries interconnection to the carrier hotels and peering points where AWS exchanges traffic with the rest of the internet and where enterprise customers land their private Direct Connect circuits. A fault there does not just slow things inside the region; it can sever the private, predictable links that customers pay for precisely because they do not want to depend on the public internet. The teams most exposed are often the ones who invested the most in a dedicated path.

A pattern, not an incident

The repeat is what elevates this from a footnote to a trend. Counting this one, AWS has now had four notable reliability events in its core infrastructure since May:

• A data-center thermal event in Northern Virginia in May.
• A network disruption in June that also rippled into other providers.
• The July 24 us-west-2 connectivity loss tied to the Seattle path.
• This month’s shorter us-west-2 repeat on the same path.

None of these was individually catastrophic. Taken together, they describe a provider whose failures are clustering in networking and in a small number of physical corridors. That is a different risk profile than a single dramatic outage: it suggests a class of fault that recurs rather than a one-off that gets fixed and forgotten.

It also arrives against a backdrop of broader cloud fragility. AWS’s own CloudFront outage in July took down high-profile services over a single internal limit; Microsoft had a 365 outage the same month; and Cloudflare logged a burst of R2 and network incidents in early August. The common thread is concentration: a handful of providers carry an enormous share of the internet, so their internal faults become everyone’s faults.

What customers can actually do

The uncomfortable truth is that a customer cannot fix AWS’s Seattle routing. What they can control is how much a single region’s networking is allowed to matter. The teams that shrugged off both us-west-2 incidents were the ones that had already designed for a region to disappear.

That means real multi-region posture, not a warm copy of the database that no one has ever failed over to. It means deciding, in advance, the trade-offs captured by RPO and RTO — how much data you can afford to lose and how long you can afford to be down — and building to those targets rather than to a vague hope of resilience. And it means choosing deliberately between active-active and active-passive designs, understanding that active-active costs more but keeps serving through exactly this kind of regional networking fault.

For the private-connectivity crowd, the July and August incidents carry a specific lesson: a single Direct Connect circuit into a single metro is a single point of failure, no matter how premium the link. Redundant circuits into diverse locations are the standard answer, and both outages just made the case for them again.

What it means

A twenty-minute outage is not, by itself, a crisis. The significance is in the repetition: AWS broke the same corridor twice in a month and has now strung together four core-infrastructure incidents since May.

Who’s exposed. Anyone anchored in us-west-2 without a tested failover path, and especially anyone leaning on a single Direct Connect circuit through the Seattle Metro, has now been shown twice that a link they cannot see or control can take them offline. The workloads most at risk are the ones that assumed a mature, decade-old region was effectively always-on.

What AWS owes. After a second incident on the same path, the value is in the detail. A public explanation of why the Seattle Metro networking hardware failed again, what the July fix did or did not address, and how AWS will prevent a third occurrence is what separates a diagnosed problem from a recurring one. The record AWS revenue that funds this infrastructure raises, rather than lowers, the expectation of durability.

What to watch next. Whether AWS ships a change that removes this class of routing fault rather than patching the instance; whether the cadence of core-network incidents slows or keeps clustering; and whether enterprises respond by hardening their multi-region and redundant-connectivity posture — or simply hope the next one lands somewhere else. The pattern has been asking that question for months. This week it asked again.