Regions and zones

Compute Engine resources are hosted in multiple locations worldwide. These locations are composed of regions and zones. A region is a specific geographical location where you can host your resources. Regions have three or more zones. For example, the us-west1 region denotes a region on the west coast of the United States that has three zones: us-west1-a, us-west1-b, and us-west1-c.

Resources that live in a zone, such as virtual machine instances or zonal persistent disks, are referred to as zonal resources. Other resources, like static external IP addresses, are regional. Regional resources can be used by any resource in that region, regardless of zone, while zonal resources can only be used by other resources in the same zone.

For example, to attach a zonal persistent disk to an instance, both resources must be in the same zone. Similarly, if you want to assign a static IP address to an instance, the instance must be in the same region as the static IP address.

Putting resources in different zones in a region provides isolation from most types of physical infrastructure and infrastructure software service failures. Putting resources in different regions provides an even higher degree of failure independence. This lets you design robust systems with resources spread across different failure domains.

Only certain resources are region- or zone-specific. Other resources, such as images, are global resources that can be used by any other resources across any location. For information on global, regional, and zonal Compute Engine resources, see Global, Regional, and Zonal Resources.

Zones and clusters

Compute Engine implements a layer of abstraction between zones and the physical clusters where the zones are hosted. A cluster represents a distinct physical infrastructure that is housed in a data center. Each cluster has independent software infrastructure, power, cooling, network, and security infrastructure, and includes a large pool of compute and storage resources.

Each zone is hosted in one or more clusters and Compute Engine independently maps zones to clusters for each organization. For example, the us-central1-a zone for your organization might not map to the same cluster as the us-central1-a zone for another organization.

Decoupling zones from clusters provides a number of benefits to you and to Compute Engine:

  • It allows Compute Engine to ensure resources are balanced across the clusters in a region.
  • The list of zones you can choose from remains manageable as Compute Engine continues to grow its regions over time by adding more clusters.

For most organizations, Compute Engine ensures that all projects in an organization have a consistent zone to cluster mapping. For organizations with projects that use VPC Network Peering or Private services access to share networks or services with other organizations, Compute Engine tries to ensure that the peered organizations all have a consistent zone to cluster mapping. In the case of large-scale SaaS providers, for example, Compute Engine might not provide a consistent mapping for all peered organizations. In these cases, Compute Engine ensures that the peered projects have a consistent zone to cluster mapping.

Choosing a region and zone

You choose which region or zone hosts your resources, which controls where your data is stored and used. Choosing a region and zone is important for several reasons:

Handling failures
Distribute your resources across multiple zones and regions to tolerate outages. Google designs zones to be independent from each other: a zone usually has power, cooling, networking, and control planes that are isolated from other zones, and most single failure events will affect only a single zone. Thus, if a zone becomes unavailable, you can transfer traffic to another zone in the same region to keep your services running. Similarly, if a region experiences any disturbances, you should have backup services running in a different region. For more information about distributing your resources and designing a robust system, see Designing Robust Systems.
Decreased network latency
To decrease network latency, you might want to choose a region or zone that is close to your point of service. For example, if you mostly have customers on the East Coast of the US, then you might want to choose a primary region and zone that is close to that area and a backup region and zone that is also close by.

Identifying a region or zone

Each region in Compute Engine contains a number of zones. Each zone name contains two parts that describe each zone in detail. The first part of the zone name is the region and the second part of the name describes the zone in the region:

  • Region

    Regions are collections of zones. Zones have high-bandwidth, low-latency network connections to other zones in the same region. In order to deploy fault-tolerant applications that have high availability, Google recommends deploying applications across multiple zones and multiple regions. This helps protect against unexpected failures of components, up to and including a single zone or region.

    Choose regions that makes sense for your scenario. For example, if you only have customers in the US, or if you have specific needs that require your data to live in the US, it makes sense to store your resources in zones in the us-central1 region or zones in the us-east1 region.

  • Zone

    A zone is an isolated location within a region. The fully-qualified name for a zone is made up of <region>-<zone>. For example, the fully qualified name for zone a in region us-central1 is us-central1-a.

    Depending on how widely you want to distribute your resources, create instances across multiple zones in multiple regions for redundancy.

Available regions and zones

The following sortable table lets you select different options to see where resources are available. For example, you can select Europe from the Select a location drop-down menu, and M2 from the Select a machine type drop-down menu to see a list of zones where M2 machines are available in Europe.

Each zone supports a combination of Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake, or Cascade Lake platforms, as well as the AMD EPYC Rome platform. When you create an instance in a zone, your instance uses the default processor supported in that zone. For example, if you create an instance in the us-central1-a zone, your instance by default uses a Haswell processor, unless you specify another option.

Alternatively, you can choose your desired CPU platform. For more information, read Specifying a minimum CPU platform for VM instances.

Zones Location Machine types CPUs Resources
asia-east1-a Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-b Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-c Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east2-a
asia-east2-b
asia-east2-c
Hong Kong, APAC E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
asia-northeast1-a Tokyo, Japan, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast1-b Tokyo, Japan, APAC E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-c Tokyo, Japan, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
Osaka, Japan, APAC E2, N1 Skylake
asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
Seoul, South Korea, APAC E2, N1, C2 Skylake
asia-south1-a Mumbai, India APAC E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-south1-b Mumbai, India APAC E2, N1, M2, M1 Broadwell, Skylake GPUs
asia-south1-c Mumbai, India APAC E2, N1, M1 Broadwell, Skylake
asia-southeast1-a Jurong West, Singapore, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
asia-southeast1-b Jurong West, Singapore, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast1-c Jurong West, Singapore, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
Jakarta, Indonesia, APAC E2, N1 Skylake
australia-southeast1-a Sydney, Australia, APAC E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
australia-southeast1-b Sydney, Australia, APAC E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPUs
australia-southeast1-c Sydney, Australia, APAC E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPUs
europe-north1-a Hamina, Finland, Europe E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake
europe-north1-b Hamina, Finland, Europe E2, N2, N1 C2 Broadwell, Skylake, Cascade Lake
europe-north1-c Hamina, Finland, Europe E2, N2, N1, C2 M1 Broadwell, Skylake, Cascade Lake
europe-west1-b St. Ghislain, Belgium, Europe E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west1-c St. Ghislain, Belgium, Europe E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
europe-west1-d St. Ghislain, Belgium, Europe E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west2-a London, England, Europe E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west2-b London, England, Europe E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west2-c London, England, Europe E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-a Frankfurt, Germany Europe E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake
europe-west3-b Frankfurt, Germany Europe E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west3-c Frankfurt, Germany Europe E2, N1, M1 Broadwell, Skylake
europe-west4-a Eemshaven, Netherlands, Europe E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west4-b Eemshaven, Netherlands, Europe E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west4-c Eemshaven, Netherlands, Europe E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west6-a
europe-west6-b
europe-west6-c
Zurich, Switzerland, Europe E2, N1 Skylake
northamerica-northeast1-a Montréal, Québec, North America E2, N2, N1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-b Montréal, Québec, North America E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-c Montréal, Québec, North America E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
southamerica-east1-a Osasco, São Paulo, Brazil, South America E2, N2, N1 Broadwell, Skylake, Cascade Lake
southamerica-east1-b Osasco, São Paulo, Brazil, South America E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
southamerica-east1-c Osasco, São Paulo, Brazil, South America E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-central1-a Council Bluffs, Iowa, North America E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-b Council Bluffs, Iowa, North America E2, N2, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake GPUs
us-central1-c Council Bluffs, Iowa, North America E2, N2, N2D, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-f Council Bluffs, Iowa, North America E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-b Moncks Corner, South Carolina, North America E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-c Moncks Corner, South Carolina, North America E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-d Moncks Corner, South Carolina, North America E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-a Ashburn, Virginia, North America E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-b Ashburn, Virginia, North America E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-c Ashburn, Virginia, North America E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west1-a The Dalles, Oregon, North America E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-west1-b The Dalles, Oregon, North America E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-west1-c The Dalles, Oregon, North America E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
us-west2-a Los Angeles, California, North America E2, N1, M2, C2 Broadwell, Skylake, Cascade Lake
us-west2-b Los Angeles, California, North America E2, N1, M1 Broadwell, Skylake GPUs
us-west2-c Los Angeles, California, North America E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west3-a
us-west3-b
us-west3-c
Salt Lake City, Utah, North America E2, N1 Skylake
us-west4-a
us-west4-b
us-west4-c
Las Vegas, Nevada, North America E2, N2, N1 Skylake, Cascade Lake

Announced regions

Google will continue expanding into the following new regions:

  • Warsaw, (Poland)
  • Melbourne, (Australia)
  • Toronto, (Canada)
  • Delhi, (India)
  • Doha, (Qatar)

Transparent maintenance

Google regularly maintains its infrastructure by patching systems with the latest software, performing routine tests and preventative maintenance, and generally ensuring that Google infrastructure is as fast and efficient as Google knows how to make it.

By default, all instances are configured so that these maintenance events are transparent to your applications and workloads. Google uses a combination of datacenter innovations, operational best practices, and live migration technology to move running virtual machine instances out of the way of maintenance that is being performed. Your instance continues to run within the same zone with no action on your part.

By default, all virtual machines are set to live migrate, but you can also set your virtual machines to stop and reboot. The two options differ in the following ways:

  • Live migrate

    Compute Engine automatically migrates your running instance. The migration process will impact guest performance to some degree but your instance remains online throughout the migration process. The exact guest performance impact and duration depends on many factors, but it is expected most applications and workloads will not notice. For more information, see Live Migration.

  • Stop and reboot

    Compute Engine automatically signals your instance to shut down, waits a short time for it to shut down cleanly, and then restarts it away from the maintenance event.

For more information on how to set the options above for your instances, see Setting Instance Scheduling Options.

Zone deprecation

It is never necessary to decommission an existing zone for a ground-up infrastructure refresh (power, cooling, network fabric, servers, and so on). Infrastructure refreshes are rare and zones typically run for three to five years between refreshes. These refreshes should be transparent to customers.

If it ever becomes necessary to deprecate a zone, Compute Engine will notify users well in advance of when it will go offline so you have ample time to move your virtual machine instances and workloads.

Quotas

Certain resources, such as static IPs, images, firewall rules, and VPC networks, have defined project-wide quota limits and per-region quota limits. When you create these resources, it counts towards your total project-wide quota or your per-region quota, if applicable. If any of the affected quota limits are exceeded, you won't be able to add more resources of the same type in that project or region.

To see a comprehensive list of quotas that apply to your project, visit the Quotas page in the Google Cloud Console.

For example, if your global target pools quota is 50 and you create 25 target pools in example-region-1 and 25 target pools in example-region-2, you reach your project-wide quota and won't be able to create more target pools in any region within your project until you free up space. Similarly, if you have a per-region quota of 7 reserved IP addresses, you can only reserve up to 7 IP addresses in a single region. After you reach that limit, you will either need to reserve IP addresses in a new region or release some IP addresses.

Tips

When selecting zones, here are some things to keep in mind:

  • Communication within and across regions will incur different costs.

    Generally, communication within regions will always be cheaper and faster than communication across different regions.

  • Design important systems with redundancy across multiple zones.

    At some point in time, your instances might experience an unexpected failure. To mitigate the effects of these possible events, you should duplicate important systems in multiple zones and regions.

    For example, by hosting instances in zones europe-west1-b and europe-west1-c, if europe-west1-b fails unexpectedly, your instances in zone europe-west1-c will still be available. However, if you host all your instances in europe-west1-b, you will not be able to access any instances if europe-west1-b goes offline. Also, consider hosting your resources across regions. For example, in the unlikely scenario that the europe-west1 region experiences a failure, consider hosting backup instances in a zone in the europe-west3 region. For more tips on how to design systems for availability, see Designing Robust Systems.

What's next