GCP Regions and Zones Explained: Scope, Availability, and Common Mistakes

What regions and zones mean in GCP

A region is an independent geographic location where Google operates data centres. Examples include us-central1 (Iowa), europe-west1 (Belgium), and asia-east1 (Taiwan). Each region is completely isolated from every other region. A failure in us-central1 has no effect on europe-west1.

A zone is a physically separate deployment area inside a region. Each zone has its own power supply, cooling, and networking hardware, independent from the other zones in the same region. Most regions contain three or more zones. Zones within a region are connected by a fast, low-latency internal network, but they are physically separate enough that a hardware failure in one zone is very unlikely to affect another.

Zone names follow the pattern REGION-LETTER. For example, us-central1-a, us-central1-b, and us-central1-c are three zones in the us-central1 region.

Why does this matter? Because every GCP resource has a location scope. Some resources live in a single zone. Some span a region. Some are global. Scope controls where a resource runs, which other resources can connect to it directly, and what happens when there is a failure. For a deeper look at the physical network behind these locations, see the GCP Global Infrastructure guide.

Simple explanation

How location scope works in Google Cloud

Location scope is the mental model that underlies most GCP architecture decisions. Here is how it works:

1. Every resource has a scope. When you create a VM, a database, a network, or a storage bucket, GCP assigns it a location: zonal, regional, or global. This is determined by the resource type and cannot be changed after creation.

2. Zonal resources live in one zone. They can only be accessed by other resources in that same zone. If the zone goes down, the resource is unavailable until it recovers.

3. Regional resources span a whole region. They are not tied to a single zone. They tolerate zone failures automatically because they are distributed across multiple zones internally.

4. Global resources have no specific location. They exist across your entire GCP project and are available everywhere regardless of region or zone.

5. Scope affects how you create and connect resources. Zonal resources require both —region and —zone flags in gcloud. Regional resources need only —region. Global resources need neither.

6. Scope affects latency, availability, and cost. Resources in the same zone communicate with virtually no overhead. Resources in different zones within the same region incur a small egress fee. Resources in different regions incur higher costs and longer latency. See Network Egress Costs for the full breakdown.

Regions

A region is an independent geographic location. Regions are completely isolated from each other: a failure in one region does not affect others. When you create most resources, you choose a region and that resource runs in that region’s infrastructure.

As of early 2026, Google Cloud operates over 40 regions worldwide, spanning North America, South America, Europe, the Middle East, Africa, and Asia-Pacific. New regions are added regularly. The Global Infrastructure guide covers the physical network and region expansion in detail.

Choose a region based on four factors, in priority order:

1. Proximity to your users. Closer regions mean lower latency. If your users are in Western Europe, europe-west1 (Belgium) or europe-west4 (Netherlands) will significantly outperform us-central1 for interactive workloads.

2. Data residency requirements. Legal or compliance constraints may require data to stay within a specific country or jurisdiction. GDPR applies to EU personal data; other regulations apply in India, Australia, and elsewhere. Check your requirements before picking a region, and see Restricting Resource Locations for how to enforce this with Organisation Policies.

3. Service availability. Not every GCP service is available in every region. Newer services typically launch in a subset of regions first. Verify that every service your architecture needs is available in your chosen region before committing.

4. Cost. US regions are consistently the cheapest. European and Asia-Pacific regions carry a small premium. For purely internal or batch workloads with no user-facing latency requirement, cost can be a tiebreaker. See GCP Pricing Models for regional pricing differences.

# List all available regions
gcloud compute regions list

# See details and quotas for a specific region
gcloud compute regions describe us-central1

Zones

A zone is a deployment area within a region. Each zone has independent power, cooling, and networking hardware from the other zones in its region. Most regions have three or more zones. A zone failure does not affect other zones in the same region.

Zone names use the pattern REGION-LETTER, for example:

• us-central1-a
• us-central1-b
• us-central1-c
• us-central1-f

The letters are not always sequential; zones are added at different times. Do not assume consecutive letters.

Zones in the same region are connected by fast, low-latency networking. Inter-zone latency within a region is typically under 5ms. This makes multi-zone architectures practical: you get fault isolation without the significant latency or cost penalty of cross-region communication.

# List all zones
gcloud compute zones list

# List zones in a specific region
gcloud compute zones list --filter="region:us-central1"

Region vs zone: the key difference

The distinction is simple once you have the mental model, but it has real design consequences. Choosing a region is a geographic decision. Choosing a zone is a fault-isolation decision.

The most important thing to remember: a region contains zones. A zone cannot span more than one region. Confusing the two leads directly to deployment errors and availability gaps.

Zonal, regional, and global resources

Every GCP resource type has a scope. This determines where it lives, how to reference it in gcloud commands, and what happens when the zone or region it depends on has a problem.

Zonal resources

Zonal resources live in a single zone and can only be used within that zone. If the zone goes down, the resource is unavailable until the zone recovers.

• Compute Engine VM instances
• Persistent disks (standard, SSD, and balanced)
• GKE node pools (in Standard mode)

Zonal resources are the simplest to create but are a single point of failure. A single zone failure takes them offline.

Regional resources

Regional resources span all zones in a region automatically. They provide redundancy without requiring you to configure multi-zone placement manually. A regional resource survives a zone failure because it is not tied to any single zone.

• Regional managed instance groups (VMs balanced automatically across zones)
• Cloud SQL with high availability (primary in one zone, hot standby in another)
• Regional persistent disks (replicated across two zones)
• Cloud Run services (regional by default; instances spread across zones automatically)
• Subnets (regional scope; each subnet lives in one region, not globally)

Global resources

Global resources are not tied to any region or zone. They work across your entire GCP project regardless of where individual resources are located.

• VPC networks and firewall rules
• Global load balancers
• Global static IP addresses
• IAM policies
• Cloud Storage buckets (data location is configurable as regional, dual-region, or multi-regional)

Scope comparison

How to choose the right scope

The right scope follows directly from what you need the resource to survive:

• Use zonal when failure tolerance is low or irrelevant. Learning environments, dev VMs, scratch disks, and one-off batch jobs are fine as zonal. If a zone failure takes them offline briefly, you restart. The cost and setup simplicity of zonal resources are real advantages here.

• Use regional when you need availability inside one region. Production databases, application servers, and APIs serving real users should use regional resources. Regional managed instance groups and Cloud SQL HA give you zone-failure tolerance with minimal configuration.

• Use global for shared infrastructure. VPC networks, firewall rules, and IAM policies are global by design. You do not choose to make them global; that is simply how they work.

• Do not over-engineer early architectures. Start with multi-zone within one region. Multi-region adds substantial complexity. Get multi-zone right first, and expand to multi-region only when you have a clear requirement for it.

When to use this in real life

Here are practical examples of how region and zone choices play out:

A learning VM

You are following a tutorial. Create a VM in us-central1-a. Zonal is fine. If the zone goes down, you restart and carry on. Cost and simplicity matter most here.

A production web application

Your app serves real users. Use a regional managed instance group in us-central1. GCP spreads your VMs across us-central1-a, us-central1-b, and us-central1-c automatically. If one zone fails, the other two keep serving traffic. Pair it with a global load balancer to distribute incoming requests.

A production database

Use Cloud SQL with high availability enabled. GCP places the primary in one zone and a hot standby in a different zone in the same region. Failover is automatic and typically completes within two minutes. See Backups and High Availability for the full configuration.

A UK or EU application with data residency needs

Choose europe-west2 (London) or europe-west1 (Belgium). Use an Organisation Policy to restrict resources to specific locations. This ensures data stays within the correct jurisdiction for GDPR compliance.

A VPC network used across a project

Your VPC network is global. You create subnets per region. A VM in us-central1 and a VM in europe-west1 can both be in the same VPC, each in its own regional subnet. The network spans everything; the subnets do not.

Designing for multi-zone availability

Spreading across multiple zones is the first and most important availability step. Zone failures are more common than full regional failures, and multi-zone protection is straightforward to set up.

A regional managed instance group handles multi-zone VM placement automatically:

# Create a regional MIG spanning all zones in us-central1
gcloud compute instance-groups managed create my-app-group \
  --region=us-central1 \
  --template=my-instance-template \
  --size=3

# GCP spreads the 3 VMs across us-central1-a, b, and c.
# If one zone fails, the other two keep serving traffic.

For databases, Cloud SQL with high availability places a primary instance in one zone and a standby replica in a different zone in the same region. Failover is automatic and typically completes within two minutes. Cloud SQL HA costs more than single-zone, but for any production database holding real data, it is worth it. See Backups and High Availability for configuration details.

For Cloud Run, services are regional by default. GCP distributes instances across zones in the region automatically. No additional configuration is needed for multi-zone availability on Cloud Run.

Multi-zone vs multi-region

These two terms describe different levels of availability with very different trade-offs. Beginners often conflate them.

Multi-region is the right choice for some applications: a globally distributed API, a service requiring strict disaster recovery guarantees, or a workload serving users on multiple continents with low-latency requirements. But for most teams, multi-zone within one region is the appropriate first step.

If you are designing a multi-region system, see Multi-Region Architectures and Disaster Recovery Strategies.

For Cloud Storage specifically, you can choose regional, dual-region, or multi-regional buckets. See Regional vs Multi-Regional Storage for the trade-offs.

Setting default region and zone in gcloud

Without defaults, gcloud requires —region or —zone on every command that creates a zonal or regional resource. Set them once after installing gcloud and you will not need to repeat them on every command:

# Set default region and zone
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

# Confirm your current settings
gcloud config list

You can always override the defaults for a specific command using the —region or —zone flag. The gcloud CLI guide covers configuration profiles if you work across multiple projects or regions regularly.

Regions and zones vs resource hierarchy

Beginners sometimes conflate two separate concepts: the GCP resource hierarchy and location scope. They are not the same thing.

The resource hierarchy (Organisation, Folders, Projects, and Resources) is an administrative structure. It controls ownership, billing, and access. A project is a billing and access container, not a location.

Regions and zones are location scopes. They describe where resources physically run.

These two systems are independent. A single project can contain resources in multiple regions and zones simultaneously. A VM in us-central1-a and a database in europe-west1-b can both belong to the same project. The project is the administrative boundary; the region and zone is the physical location.