Consider geographic distribution

Before you create resources, consider how you plan to distribute resources geographically to meet your company's unique requirements. Administrators and architects in your organization usually make decisions about geography, and make their decisions available to people who deploy resources. For example, your company might have an Infrastructure as Code (IaC) process that automatically assigns geographies as you deploy resources.

This document provides an overview on how geography impacts your workloads.

Distribute resources to help ensure availability

You can geographically distribute resources to meet your unique requirements, as in the following examples:

  • Latency: Ensure you have resources in zones near your users.
  • Availability: Create redundant resources in multiple regions in case of a region failure.

Regions and zones

When you create resources, you might select the following geographic categories:

  • Regions are independent geographic areas that contain zones. For example, asia-east1 (Taiwan).

  • Zones are areas that are isolated from each other within a region. For example, zone a in the asia-east1 (Taiwan) region is named asia-east1-a.

Consider a zone as a single failure domain within a region. To deploy fault-tolerant applications with high availability and help protect against unexpected failures, you might deploy your applications across multiple zones in a region. For more information, see Geography and regions.

Each resource has its own location dynamics. For example, see the following details about Compute Engine and Cloud Storage:

Select geographies based on resource interactions

As you create your resource distribution plan, consider resource communication across zones and regions. Resource interaction capabilities are determined by the following resource types:

  • Global resources can be accessed by any other resource, across regions and zones. Examples include disk images, disk snapshots, and networks.

  • Regional resources are redundantly deployed across multiple zones within a region. Regional resources can be accessed only by resources that are located in the same region. Examples include App Engine applications and regional managed instance groups.

  • Multiregional services are redundantly distributed within and across regions. These services optimize availability, performance, and resource efficiency. For a list of services that have one or more multiregional locations, see Products available by location.

  • Zonal resources can be accessed only by resources that are located in the same zone. An example of a zonal resource is a Compute Engine virtual machine (VM) instance.

For example, consider the following resources:

  • Globally: a network that can be accessed by all resources.
  • In each region: IP addresses that provide external access to resources only within a single region.
  • In each zone: disks that can connect to VMs that are in the same zone.

A global network can contain region-specific resources such as IP addresses and zone-specific resources such as VMs and disks