Regions & Zones

Exam guide§1.1

Google Cloud's physical layout, from big to small:

Multi-region → Region → Zone

• Region - an independent geographic area (e.g. us-central1), containing multiple zones. Regions are isolated from each other for fault tolerance.
• Zone - a single failure domain within a region (e.g. us-central1-a). Roughly "one datacenter's worth" of isolation.
• Multi-region - a large area (e.g. US, EU) spanning several regions, used by some storage products for maximum durability.

Think of it as one area seen at three levels of granularity: a location subdivides into regions, and each region subdivides into zones.

A location subdivides into regions, and each region subdivides into zones: the same area seen at three levels of granularity.

A single network stretches across regions; each subnet lives in one region and owns an IP range; each VM sits in a zone and pulls an internal IP from its subnet.

A network is global and spans regions; each subnet is regional and holds an IP range; VMs are zonal and draw an internal IP from their subnet.

#NumbersZones per region

• Most regions have 3 zones; a handful have 4.
• us-central1 (Iowa) has 4 zones - -a, -b, -c, -f (note -e is skipped). This is the classic "exception to the 3-zone rule" fact.
• Zone counts grow over time - confirm at cloud.google.com/about/locations.

Resource scope: the thing you must memorize

Every resource is global, regional, or zonal, and that scope decides what it can attach to and how it survives failure. The scope is physical placement; billing and reporting stay per project regardless of where a resource lives.

Resource scope decides placement: global resources (images, snapshots, networks) span everything, regional resources (external IP addresses) live in one region, and zonal resources (instances, disks) live in one zone - but every resource still belongs to exactly one project, so billing and reporting are per project.

≡FactsScope of common resources

• Global: images, snapshots, VPC networks, firewall rules, static external IPs (global)
• Regional: subnets, regional Persistent Disks, regional MIGs, static regional IPs, App Engine
• Zonal: VM instances, zonal Persistent Disks, GKE zonal clusters

⚠GotchaA disk and its VM must share a zone

A zonal Persistent Disk can only attach to a VM in the same zone. You cannot move a disk across zones directly - you snapshot it (snapshots are global) and recreate it elsewhere. Any "attach this disk to that VM" question hinges on matching zones.

?DECISIONHigher availability = spread across zones/regions

A single zonal VM dies when its zone does. To survive zone failure, use a regional MIG that spreads instances across zones; to survive region failure, deploy to multiple regions behind a global load balancer. Match the availability requirement in the question to the scope of the fix.

Pick this when: survive a ZONE failure → regional MIG across zones; survive a REGION failure → deploy to multiple regions

Product availability per location

Not every product or machine type exists in every region. Before committing to a location, verify availability - and check pricing, which varies by region.

CommandsCheck what's where

gcloud compute regions list

gcloud compute zones list

gcloud compute machine-types list --zones=us-central1-a

gcloud compute accelerator-types list --filter="zone:us-central1-a" # GPUs

Recap

?DECISIONWhich region should I pick?

Low user latency→Closest region to users

Data residency / compliance→Region in the required jurisdiction

Lowest cost→Compare per-region pricing

Needs a specific product / GPU→Region where it's available

Pick this when: weigh these in order for the given constraint