Every resource you create lives in a location, and that choice drives latency, availability, price and compliance.
Google Cloud is a catalog of managed services running in Google's data centers. Before creating anything you need two ideas: location and resource scope.
A region is a geographic area such as us-central1 or europe-west1. Each region contains three or more zones (europe-west1-b), which are isolated failure domains: separate power, cooling and networking. Some services also offer multi-regions (US, EU) that replicate data across regions.
Resources have a scope that follows from this:
- Zonal: a VM and its persistent disk live in one zone. If that zone fails, they are unavailable.
- Regional: subnets, regional managed instance groups, Cloud Run services and Cloud SQL HA instances span the zones of a region.
- Global: VPC networks, firewall rules, images and the global external load balancer.
The services fall into rough families: compute (Compute Engine, GKE, Cloud Run, Cloud Run functions), storage and databases (Cloud Storage, Cloud SQL, Firestore, Spanner, BigQuery), networking (VPC, Load Balancing, Cloud CDN, Cloud NAT), operations (Logging, Monitoring) and AI (Vertex AI).
Pick a region close to your users, check that the services you need are available there, and keep related resources in the same region: traffic between regions is slower and is billed as egress.
Example
# List regions and the zones of one region
gcloud compute regions list --format="value(name)" | head -5
# africa-south1
# asia-east1
# asia-east2
# ...
gcloud compute zones list --filter="region:europe-west1" --format="value(name)"
# europe-west1-b
# europe-west1-c
# europe-west1-dRemember
- A region holds 3+ isolated zones
- Resources are zonal, regional or global
- Keep chatty resources in one region to avoid latency and egress charges
Watch out for
- Running a single VM in one zone and calling it highly available.