Regions, zones and location scope — zonal, regional and global resources, and what that costs on a migration
Where a Google Cloud resource lives and what that commits you to: how a region and a zone are defined, the stated failure-independence argument, which Compute Engine resources are zonal, regional or global, and the constraint that an attachable disk and its instance must share a zone.
markdownreferencev1B0AG-XVR3stage: designtrust: officialfamily: overviewservice: compute-engineinterface: anyregionzonemulti-regionzonal resourceregional resourceglobal resourcefailure domainus-central1-aAI zones
Regions, zones and location scope
1. The two words
- a region is an independent geographic area made of multiple zones;
- a zone is a deployment area inside a region.
Zone names are region-letter — us-central1-a. AI zones are named differently: region-ai#letter, as in
us-west4-ai2b. An agent parsing a zone name with a one-letter-suffix assumption will mis-handle those.
2. Failure independence, in the page's own terms
The page is careful and so is this document: "zones and regions are logical abstractions of underlying physical resources", designed to minimise correlated failures. Distributing across zones reduces the risk of a simultaneous outage; distributing across regions gives an "even higher degree of failure independence".
The hub's reading: treat a zone as a strong-but-not-absolute failure boundary and a region as a stronger one. The page does not promise that two zones never fail together, and a design that needs that promise should be multi-region.
3. Location scope, per resource
| Scope | Examples the page gives |
|---|---|
| zonal | Compute Engine instances, zonal disks |
| regional | static external IP addresses |
| global | images |
The constraint that bites first, verbatim:
"To attach a zonal persistent disk to an instance, both resources must be in the same zone."
So a zonal disk is not a thing you move to another zone by reconfiguration; it is a thing you copy. The page
does not document moving a resource between zones or regions, and this document does not claim it can be
done — it points to the migration family instead (reference/migration/migrate-to-virtual-machines.md).
Cloud KMS states the strongest form of the same rule: "Cloud KMS resources can't be moved to a different location after they are created."
4. Why this is the first thing to settle in a cross-cloud estimate
The three clouds divide location differently, and every per-resource count downstream depends on which division you count in:
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| the unit a resource usually lives in | zone (instances, disks) | Availability Zone | region, with zones optional per service |
| the unit the control plane usually lives in | region, with many services global | region, with some global services | region |
| what is global by default | images, and much of networking (see reference/networking/vpc.md) | IAM, Route 53, CloudFront | Entra ID, some global services |
The estimate-bearing difference: Google Cloud's VPC is global and its subnets are regional, while an AWS
VPC is regional and an Azure virtual network is regional. So a Google Cloud estate often has one network
object where an AWS or Azure estate has one per region — and converting a network count between them is not a
multiplication, it is a re-modelling. That row is the single largest source of error in a like-for-like
network estimate; it is set out in guides/parity/networking.md.