Regions and Zones

Certain Compute Engine resources live in regions or zones. A region is a
specific geographical location where you can run your resources. Each region has
one or more zones; most regions have three or more zones. For example,
the us-central1 region denotes a region in the
Central United States that has zones us-central1-a, us-central1-b,
us-central1-c, and us-central1-f.

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

For example, disks and instances are both zonal resources. To attach a 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.

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.

The following table describes the regions and their associated zones. See the
Available regions & zones section for a complete description
of a zone's available machine types and features.

Region

Zones

Location

asia-east1

a, b, c

Changhua County, Taiwan

asia-east2

a, b, c

Hong Kong

asia-northeast1

a, b, c

Tokyo, Japan

asia-south1

a, b, c

Mumbai, India

asia-southeast1

a, b, c

Jurong West, Singapore

australia-southeast1

a, b, c

Sydney, Australia

europe-north1

a, b, c

Hamina, Finland

europe-west1

b, c, d

St. Ghislain, Belgium

europe-west2

a, b, c

London, England, UK

europe-west3

a, b, c

Frankfurt, Germany

europe-west4

a, b, c

Eemshaven, Netherlands

northamerica-northeast1

a, b, c

Montréal, Québec, Canada

southamerica-east1

a, b, c

São Paulo, Brazil

us-central1

a, b, c, f

Council Bluffs, Iowa, USA

us-east1

b, c, d

Moncks Corner, South Carolina, USA

us-east4

a, b, c

Ashburn, Northern Virginia, USA

us-west1

a, b, c

The Dalles, Oregon, USA

us-west2

a, b, c

Los Angeles, California, USA

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 & zones

The following table lists the region, its location, the available zones in that
region, and the features available in that region.

Each zone supports a combination of Ivy Bridge, Sandy Bridge, Haswell,
Broadwell, and Skylake platforms. When you create an instance
in the zone, your instance will use the default processor supported in that
zone. For example, if you create an instance in the us-central1-a zone, your
instance will use a Sandy Bridge processor.

In 2019, Google will continue expanding into the following new regions:

Zürich (Switzerland)

Osaka (Japan)

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 terminate 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 depend on many factors, but it is expected
most applications and workloads will not notice.

Terminate 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.

Zone deprecation

Compute Engine has made recent improvements in its virtualization
technology that eliminate the need to decommission an existing zone for a
ground-up infrastructure refresh (power, cooling, network fabric, servers,
etc.). 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 Platform 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 hit 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, it is possible that 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. You should also
consider hosting your resources across regions. For example, consider hosting
backup instances in a zone in europe-west3 in the unlikely scenario that
the europe-west1 region experiences a failure. For
more tips on how to design systems for availability, see
Designing Robust Systems.