"Just pick a Region close to your users" is true as far as it goes, but Regions, Availability Zones, Local Zones, and Wavelength Zones are four different things AWS deliberately structures for different failure and latency characteristics — and knowing which one you're actually looking at explains a lot of otherwise-confusing AWS behavior.
Regions: isolated on purpose
A Region is a separate geographic area — us-east-1, eu-west-1, and so on — and per AWS's own documentation, "each Region is designed to be isolated from the other Regions. This achieves the greatest possible fault tolerance and stability." Nothing replicates across Regions automatically — a resource created in us-east-1 simply doesn't exist in eu-west-1 unless you explicitly set up replication. That isolation is the entire point: a full outage in one Region has no direct path to affecting another. See AWS Region Explorer for the current list.
Availability Zones: isolated within a Region
Each Region is made of multiple Availability Zones (AZs) — physically separate data centers close enough for low-latency connections between them, but isolated enough that a single facility problem (power, cooling, a physical event) doesn't take the whole Region down. An AZ's code is its Region code plus a letter, like us-east-1a.
Here's the part that surprises people: that letter doesn't mean what it looks like it means. Per AWS's own docs, "AWS maps the physical Availability Zones randomly to the Availability Zone names for each AWS account" specifically so everyone's workloads don't all pile into whichever data center happens to be labeled "a." The result: us-east-1a in your account and us-east-1a in someone else's account can be — and often are — two completely different physical buildings. This only actually bites when you're coordinating AZ placement across accounts (peering a VPC, sharing a subnet), and AWS provides the fix for exactly that case: an AZ ID like use1-az1, a name that stays consistent for the same physical location across every account. If you ever need to guarantee two accounts' resources land in the same physical AZ, match on the AZ ID, never the letter.
Local Zones and Wavelength Zones: smaller, closer extensions
Both are logical extensions of a parent Region, not Regions of their own — they share the parent's control plane but put compute physically closer to a specific place. Local Zones extend a Region toward a metro area for lower latency to users there; a Local Zone's code is the Region code plus a location identifier, like us-west-2-lax-1 for Los Angeles. Wavelength Zones go a step further, embedding AWS compute inside a telecom carrier's 5G network for ultra-low latency to mobile devices, coded similarly, like us-east-1-wl1-bos-wlz-1 for Boston. Neither shows up in a plain list of Regions — both need to be explicitly enabled and used through a VPC extended into them.
Actually choosing one
Beyond "closest to your users," three other factors usually decide it in practice: data residency (some workloads are legally required to stay within a specific country or jurisdiction, which a Region boundary satisfies and a CDN edge cache doesn't), service availability (new AWS services and features typically launch in us-east-1 first and reach other Regions over weeks or months, so a Region choice can quietly limit which services are even usable), and price (the same instance type can cost meaningfully different amounts in different Regions). None of these are visible from a Region's name — they're worth checking explicitly rather than assumed.
Try it yourself
AWS Region Explorer is a searchable reference for every current Region's code, geography, Availability Zone count, and opt-in status — entirely in your browser.