Stay organized with collections
Save and categorize content based on your preferences.
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:
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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["\u003cp\u003eGeographic distribution of resources is crucial for meeting unique company requirements, ensuring low latency, and maintaining high availability.\u003c/p\u003e\n"],["\u003cp\u003eResources are categorized into regions and zones, where regions are independent geographic areas containing multiple zones, which are isolated areas within a region.\u003c/p\u003e\n"],["\u003cp\u003eResource interactions are influenced by whether they are global, regional, multiregional, or zonal, each having distinct access capabilities based on their location.\u003c/p\u003e\n"],["\u003cp\u003eFault-tolerant applications should be deployed across multiple zones within a region to protect against unexpected failures and enhance high availability.\u003c/p\u003e\n"],["\u003cp\u003eConsiderations regarding how resources communicate across regions and zones are important while determining the resource distribution strategy.\u003c/p\u003e\n"]]],[],null,["# Consider geographic distribution\n\nBefore you create resources, consider how you plan to distribute resources\ngeographically to meet your company's unique requirements. Administrators and\narchitects in your organization usually make decisions about geography, and make\ntheir decisions available to people who deploy resources. For example, your\ncompany might have an [Infrastructure as Code (IaC)](/docs/terraform/iac-overview)\nprocess that automatically assigns geographies as you deploy resources.\n\nThis document provides an overview on how geography impacts your workloads.\n\nDistribute resources to help ensure availability\n------------------------------------------------\n\nYou can geographically distribute resources to meet your unique requirements, as\nin the following examples:\n\n- Latency: Ensure you have resources in zones near your users.\n- Availability: Create redundant resources in multiple regions in case of a region failure.\n\nRegions and zones\n-----------------\n\nWhen you create resources, you might select the following geographic categories:\n\n- *Regions* are independent geographic areas that contain zones. For example,\n `asia-east1` (Taiwan).\n\n- *Zones* are areas that are isolated from each other within a region. For\n example, zone `a` in the `asia-east1` (Taiwan) region is named `asia-east1-a`.\n\nConsider a zone as a single failure domain within a region. To deploy\nfault-tolerant applications with high availability and help protect against\nunexpected failures, you might deploy your applications across multiple zones in\na region. For more information, see\n[Geography and regions](/docs/geography-and-regions).\n\nEach resource has its own location dynamics. For example, see the following\ndetails about Compute Engine and Cloud Storage:\n\n- [Compute Engine regions and zones](/compute/docs/regions-zones)\n- [Cloud Storage bucket locations](/storage/docs/bucket-locations)\n\n### Select geographies based on resource interactions\n\nAs you create your resource distribution plan, consider resource communication\nacross zones and regions. Resource interaction capabilities are determined by\nthe following resource types:\n\n- *Global resources* can be accessed by any other resource, across regions and\n zones. Examples include disk images, disk snapshots, and networks.\n\n- *Regional resources* are redundantly deployed across multiple\n zones within a region. Regional resources can be accessed only by resources that\n are located in the same region. Examples include App Engine\n applications and [regional managed instance groups](/compute/docs/instance-groups#types_of_managed_instance_groups).\n\n- *Multiregional* services are redundantly distributed within and across\n regions. These services optimize availability, performance, and resource\n efficiency. For a list of services that have one or more multiregional\n locations, see [Products available by location](/about/locations#multi-region).\n\n- *Zonal resources* can be accessed only by resources that are located in the\n same zone. An example of a zonal resource is a Compute Engine virtual\n machine (VM) instance.\n\nFor example, consider the following resources:\n\n- Globally: a network that can be accessed by all resources.\n- In each region: IP addresses that provide external access to resources only within a single region.\n- In each zone: disks that can connect to VMs that are in the same zone."]]
