---
cuppy_hub: gcp
cuppy_path: reference/overview/regions-zones-and-locations.md
cuppy_section: docs
cuppy_doc: B0AG-XVR3
cuppy_doc_uuid: cb2932cd-947e-40e0-bccf-737778888851
cuppy_permalink: https://cuppy.io/gcp/d/B0AG-XVR3
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/overview/regions-zones-and-locations
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 357d50cf81d37ecfdd46de2507ad62fb3c94a9bbdc6f8eac405d934da270219b
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->