• Skip to primary navigation
  • Skip to main content
Last Week in AWS Logo
Master your cloud costs
  • About
    • Community
    • Contact
  • Blog
  • Newsletter
  • Podcasts
    • Last Week in AWS Podcast
    • Screaming in the Cloud
    • Nominate a Guest
  • Merch
  • Resources
    • AWS Network Map
US-West-1 is unavailable
07.19.2023

us-west-1: The Flagship AWS Region That Isn’t

By Corey Quinn
For a flagship AWS region based in Northern California, us-west-1 gets way less use than you'd expect. Here's my best guess as to why.
FacebookXLinkedInReddit
Home Blog us-west-1: The Flagship AWS Region That Isn’t
Prev
Next

The Monolith
“All these regions are yours except us-west-1; attempt no workloads there”

For most of 2009, AWS looked very different from today. Notably, it comprised two regions: us-east-1 and eu-west-1.

Then, AWS made a curious announcement: a new region in Northern California, dubbed us-west-1, was now available for customer use. Clearly, this looked like one of AWS’s flagship regions.

It would be another two years before AWS launched us-west-2 in Oregon. A number of companies discovering AWS between 2009 and 2011, especially those based on the U.S. West Coast that wanted to be close to their region for latency purposes, decided to base themselves out of us-west-1.

In 2009, us-west-1 was a big deal.

In 2023, it’s more like an albatross.

Let’s talk about us-west-1, the flagship region that got stuck in time.

us-west-1 lags behind on service availability

The overview page for AWS global infrastructure provides the first inkling that there’s something weird about the us-west-1 region. Curiously, while the documentation states that Northern California has three Availability Zones, the fine print on the site states that “new customers can access two Availability Zones in US West (Northern California).” It’s unclear how long this message has been there; an account I spun up a couple of years ago only shows two AZs in us-west-1. This matters in a lot of ways and tips you off to further inconsistencies.

As of this writing, the AWS regional availability site lists 227 services available in us-east-1, 220 services available in us-west-2, but only 161 services available in us-west-1. What’s more is that this only tells part of the story, since a lot of services that exist in the region aren’t fully featured — a challenge you generally encounter only by attempting to deploy a workload that relies upon that feature and, instead, watching your deployment faceplant. For example:

  • API Gateways are there, but not the v2 HTTP APIs that many applications depend upon.
  • EKS is wildly popular but didn’t make its way to us-west-1 until 2020.
  • VPC Lattice is a great offering unless you’re in us-west-1, in which case you’ll have no idea what I’m talking about.
  • SES email receiving isn’t a thing in Northern California, nor is change data capture for AWS Glue if you’re in the DynamoDB world.

It’s really death by a thousand cuts when you’re trying to use an AWS service in what seems a lot like it should be a flagship AWS region, only to discover that it’s very much not.

us-west-1 is more expensive than other U.S. regions

Even if you have service and feature compatibility, you’re staring down the unfortunate reality of paying a premium over the baseline prices of us-east-1, us-east-2, and us-west-2, the three of which all cost the same.

In Northern California, S3 is 8.8% more expensive, Managed NAT Gateways are 9.3% more expensive, and C5 instances are 24% more expensive, to name a few. There are also scenarios where things cost the same (data transfer, as one example), but there’s nothing I’ve ever seen that costs less in us-west–1 than it does one of the actual flagship regions.

When you’re at a certain point of scale, you can get private pricing opportunities in the form of service-specific discounts. However, the us-west-1 region is often pointedly excluded from these discounts by default. When usage warrants its inclusion, discounts are generally smaller than in other U.S. regions.

What happened to us-west-1?

I live in San Francisco, and the very Amazonian-named San Francisco Wavelength Zone us-west-2-wl1-sfo-wlz-1 is, as you can tell by the -2 hidden in there, a child of the Oregon parent region. In fact, all of the Local Zones and Wavelength Zones in the southwestern quadrant of the US (San Francisco, Los Angeles, Las Vegas, Phoenix, and Denver) are extensions of Oregon instead of Northern California. So, um, what happened to us-west-1?

I’m sure there are excellent reasons why us-west-1 is the way that it is. Despite this Cloud Economist’s best efforts, I’ve been unable to confirm anything officially, so I’ll instead share the gossip I’ve heard and logical conclusions I can draw.

There have long been whispers that the Bay Area facilities us-west-1 lives within are power constrained. That tracks, as anyone who’s been a customer of the aptly named Hurricane Electric’s Fremont facility can understand.

Real estate is expensive here as well, with some of the highest prices per square foot in the United States. But AWS isn’t gouging customers, otherwise you’d expect to see some things that I don’t find evident here; for example, data egress charges are the same price in us-west-1 as in other U.S. regions.

I’m willing to accept that the reasons the us-west-1 region leads to a crappy customer experience are well outside of AWS’s ability to control, fantastical though that might sound.

Even so, why is AWS letting customers sign up in a region that’s clearly not getting adequate attention? Perhaps a few more speed bumps or caution signs on the way to spinning up resources in the us-west-1 region would be a good thing, lest customers find themselves with significant infrastructure in a substandard region.

Or, even better: Give the region the investment it deserves.

Corey Quinn Headshot
by Corey Quinn

Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure.

More Posts from Corey

Back to the Blog

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

By Corey Quinn

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […]

Read Moreabout Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […]

Read Moreabout Reading Observability Tools? That’s a Robot’s Job

S3 Is Not a Filesystem (But Now There’s One In Front of It)

By Corey Quinn

I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […]

Read Moreabout S3 Is Not a Filesystem (But Now There’s One In Front of It)
Billie Holding Mail Email Subscribe Icon

Get the newsletter!

Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark.

You’re faced with tough questions about cloud costs. You should have confident answers.
Get in touch.
  • Newsletter
  • Podcasts
  • Blog
  • Merch
  • About
  • Contact
  • Disclosures
Billie Footer
footprint-orange
© 2026 L9 Labs, Inc. All Rights Reserved.
Terms of Service Privacy Policy Cookie Policy