Google Cloud Global Infrastructure

A region is an independent geographic area, identified by a code such as us-central1 (Iowa), europe-west1 (Belgium) or asia-northeast1 (Tokyo). A zone is a deployment area inside a region and is the basic failure domain: treat one zone as a single point of failure for anything that lives only in it. A zone name is the region code plus a letter, for example us-central1-a. Regions normally contain three or more zones in three or more physical data centers; a few smaller regions are still expanding towards that, and the locations page lists the exceptions. Some regions also expose specialized AI zones with a name such as us-west4-ai2b.

Regions are isolated from one another and zones are connected to each other inside a region by Google’s private network, so a multi-zone design is the baseline for high availability, and a multi-region design is a separate, more expensive decision. Unlike services that are scoped to one region, a project is not tied to a region at all: the same project holds resources in many regions.

Some services replicate data across regions for you and expose that as a location instead of a region.

Both give higher availability than a single region for a given storage class and both cost more than regional storage, plus inter-region replication charges depending on the service. Pick them when the recovery goal demands surviving a regional outage; otherwise a regional bucket is cheaper and simpler. Where a bucket lives is covered in depth in Cloud Storage, and multi-region databases in Managed databases overview.

Google runs a private, global backbone of terrestrial and subsea fiber that connects every region. Customers reach it through network edge locations, often called points of presence (PoPs), which terminate user connections close to the user and carry the traffic over Google’s backbone instead of the public internet. Edge locations also host caches for Cloud CDN and Media CDN and the entry points of the global external Application Load Balancer, which gives a service a single anycast IP address reachable worldwide. Edge capacity is not something you provision: it is a property of the services you use. Cloud CDN is covered in Cloud CDN and Media CDN and the load balancers in Load balancing and Cloud Armor.

Network service tiers choose how traffic between your resources and the internet travels:

Choose Standard only for cost-sensitive traffic that does not need worldwide reach. Pricing differs per tier and per destination, so use the dated network tiers pricing page and do not hard-code numbers.

Google also offers the same stack in places the public regions do not reach. Google Distributed Cloud runs Google Cloud services on hardware in your data center or at the edge, in connected or air-gapped variants, managed through the same APIs where possible. Sovereign cloud offerings combine in-country regions or partner-operated clouds with extra controls over data residency, encryption keys and operator access. They are mostly sold by contract and are outside the scope of this guide; see the Google Distributed Cloud and sovereign cloud pages if a compliance rule demands one.

Every Google Cloud resource has a scope that says where it exists and, therefore, how it fails. Knowing the scope tells you where to look for a resource, which flag selects it and what outage takes it down.

Pick the broadest scope that meets the availability goal and keep dependent resources close together: a VM can use a zonal disk only in its own zone, a regional resource needs its dependencies in the same region to avoid cross-region latency and transfer charges, and traffic between zones of one region has a lower cost than traffic between regions. Scopes also appear in command names: gcloud compute instances takes --zone, gcloud run services takes --region and gcloud compute networks takes neither because a VPC network is global.

Some tools can show everything of one kind regardless of location. For example gcloud compute instances list lists VMs of every zone, while gcloud run services list --region=us-central1 is limited to one region. Cloud Asset Inventory gives a project-wide view across all locations (see Governance, security and compliance).

No region is best for everything. Weigh these factors, roughly in this order:

For the Bookshelf scenario used throughout this section, us-central1 is a placeholder. A real deployment would choose the region closest to its readers and to any data-residency rule, keep the stack in one region for simplicity and use Cloud CDN for the static front end.

Pricing. Locations themselves are free; you pay for the resources in them, and the price often varies by region. The costs tied to geography are inter-zone, inter-region and internet egress traffic, multi-region and dual-region storage, and the network tier. There is no hard-coded price here: use the dated Google Cloud pricing pages and the calculator, and see Cost management and billing. The Always Free tier applies only in specific regions for some products, so check the free-tier page for the region you intend to use.

Quotas and limits. Many quotas are per region (CPUs, addresses, in-use disk) and some are global, so a project that is out of quota in us-central1 may have headroom in another region. Quotas are visible in IAM & Admin → Quotas & system limits and in gcloud compute regions describe.

Launch stages. A new region usually launches with a subset of products and then expands; individual features start in Preview before reaching General Availability. The product’s locations page and release notes say which.

Where older guides are outdated. Older guides still quote region counts that are long out of date and say nothing about newer regions or AI zones. Take counts and region names from the live locations page, and prefer gcloud storage over the older gsutil for bucket locations, as gsutil is legacy and will no longer ship with the gcloud CLI after March 2027.

The buckets created above cost little but are not free. Delete them (Cloud Storage soft delete keeps removed objects for a retention period by default, so a deleted bucket’s objects may still be billed until it expires) and release the reserved address:

See gcloud storage buckets delete and gcloud compute addresses delete.