Google Cloud products are served fromspecific regional failure domainsand are fully supported byService Level Agreements to ensure youare designing your application architecture within the structure of Google Cloud.

Google Cloud infrastructure services are available in locations acrossNorth America, South America, Europe, Asia, the Middle East, and Australia.These locations are divided into regions and zones. You can choose whereto locate your applications to meet your latency, availability, and durabilityrequirements.

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Get started for free

Regions and zones

Regions are independent geographic areas that consist ofzones. Zones and regions arelogical abstractions of underlying physical resources. A region consists of three or more zoneshoused in three or more physical data centers. The regions Stockholm, Mexico, Osaka, and Montrealhave three zones housed in one or two physical data centers. These regions are in the process ofexpanding to at least three physical data centers. When you architect your solutions inGoogle Cloud, consider the guidance inCloud locations,Google Cloud Platform SLAs,and the appropriateGoogle Cloud product documentation.

These data centers might be owned by Google and listed on theGoogle Cloud locations page,or they might be leased from third-party data center providers. For the fulllist of data center locations for Google Cloud, see ourISO/IEC 27001 certificate.Regardless of whether the data center is owned or leased, Google Cloud selectsdata centers and designs its infrastructure to provide a uniform level ofperformance, security, and reliability.

Azone is a deployment area for Google Cloud resources within a region.Zones should be considered a single failure domain within a region. Todeploy fault-tolerant applications with high availability and help protectagainst unexpected failures, deploy your applications across multiple zonesin a region. Google Cloud also offers specialized AI zones that providehigh-capacity GPUs and TPUs for AI and ML workloads. For more information, seeAI zones.

To protect against the loss of an entire region due tonatural disaster, have a disaster recovery plan and know how to bringup your application in the unlikely event that your primary region is lost. Seeapplication deployment considerationsfor more information.

For more information about the specific resources available within each locationoption, see ourCloud locations.

Google Cloud's services and resources can bezonal,regional, ormanaged by Google across multipleregions. For more information about what theseoptions mean for your data, seegeographic management of data.

Google Cloud intends to offer a minimum of three availability zones(physically and logically distinct zones) in every general-purpose region.

Zonal resources

Zonal resources operate within a single zone. Zonal outages can affect some orall of the resources in that zone. An example of a zonal resource is aCompute Engine virtual machine (VM) instance that resides within aspecific zone.

Regional resources

Regional resources are resources that are redundantly deployed across multiplezones within a region, for example App Engine applications, orregional managed instance groups.This gives them higher availability relative to zonal resources.

Multiregional resources

Multiple Google Cloud services are managed by Google to be redundant anddistributed within and across regions. These services optimize availability,performance, and resource efficiency. As a result, these services require atrade-off between either latency or the consistency model. These trade-offs aredocumented on a product specific basis.

The following services have one or moremultiregional locationsin addition to any regional locations:

• Artifact Registry
• Bigtable
• Sensitive Data Protection
• Cloud Healthcare API
• Cloud KMS
• Container Registry
• Spanner
• Cloud Storage
• Database Migration Service
• Datastore
• Firestore

These multiregional services are designed to be able to function following theloss of a single region.

For more information, seeProducts available by location,and the documentation for each product.

Global services

Google Cloud has been designed to operate globallyfrom the ground up and continually conducts maintenance and upgrades 24/7/365without inconveniencing you. Our global backbone providestremendous flexibility for load-balancing, and reduces end-user latency byhaving interconnects close to you. Our global cloud management plane simplifiesmanaging multi-region developments.

Internal services

Underpinning and supporting many customer facing Google Cloud servicesare a set of proven internal services like Spanner, Colossus, Borg, andChubby.

These internal services are either globally load-balanced across multipleregions, or dedicated to each region in which they are available. Whereservices are load-balanced across multiple regions, we deploy updatesprogressively region-by-region, allowing us to detect and address problemswithout affecting your service usage. None of these internal services arelimited to a single logical data center or to a single region.

Global Internal Services can run in or be replicated in the following cloudregions:

Americas

• southamerica-west1
• us-central1
• us-east1
• us-east4
• us-west1
• us-west4

Europe

• europe-north1
• europe-west1
• europe-west4

Asia

• asia-east1
• asia-southeast1

Service dependencies

In general, for Google Cloud services, if a single region fails, onlycustomers solely in that region are impacted; customers who have multi-regionproducts are not impacted. Google Cloud has significant architecturein place with a goal to prevent correlated failures across regions.

All Google Cloud services rely upon core internal tools to providefundamental services such as networking (in and out of data centers), access todata centers, and identity authorization systems. These tools are resilient toregional outages, with the goal of one region not being impacted if otherregions become unavailable.

Google Cloud provides clear direction on how customers can architecttheir applications for the desired level of resilience on ourpublic website,especially for commonly-used Google Cloud products such asCompute Engine, BigQuery, Pub/Sub, andother services.

Our major dependencies are listed below, starting with dependencies common toall services, with the proviso that lower level implementation details aresubject to change.

Common dependencies for all services

• Identity data plane for authentication and authorization
• Internal services that provide logging, metadata storage, and workflowmanagement
• Access to Google Cloud APIs depends on DNS, globally-distributedload balancers, and points of presence (PoPs).
• The configuration of global resources: For example, IAMpolicies, global firewall rules, global load balancer configurations, andPub/Sub topics are stored in replicated databases.
• When Google Cloud services makes requests to customer-controlledendpoints, for example, Cloud EKM fetching customer keys, orPub/Sub delivering messages, those requests depend on ourglobal network infrastructure to access those customer-controlled endpoints.

Services with additional dependencies

• Compute Engine services
  • The Google Cloud VM and Persistent Disk data planes depend onlower-level Compute Engine and Cloud Storage servicessuch as Borg and Colossus.
• Google Cloud and infrastructure storage services like Spanner,Bigtable, and Cloud Storage depend on:
  • Encryption and key management infrastructure for customer(Cloud KMS / Cloud EKM) and internal infrastructure forGoogle-owned keys
  • Internal services to provide logging and auditing of data access
  • Internal data replication services, where data is expected to be availableacross multiple regions
  • Explicitly-configured backups and replication to other regions dependson cross-region networking
• Messaging services
  • Pub/Sub depends on our global network infrastructure to accesscustomer-controlled endpoints
• Networking services
  • Global load balancing, DNS, and failover between regions all depend onphysical networking infrastructure.
  • Preventing DDos attacks, and the like, depends on lower-levelCompute Engine infrastructure.
• Managed and hosted services like GKE and Cloud SQL
  • Depend on Compute Engine and either Container Registry orArtifact Registry for VM images.
• Self-contained lower-level infrastructure
  • Our internal cluster-level control plane including Borg and network fabrics
  • Cluster-level storage, such as Colossus
  • Encryption and key management infrastructure

Maintaining and improving availability and resilience

Site Reliability Engineering (SRE) is Google's internal organization dedicated toworking on availability, latency, performance, and capacity. Outages and serviceunavailability are correlated to the deployment of new code or changes to theenvironment. By using industry best practices, SRE balances the need to releasenew software and keeps the environment secure with the understanding that thosenecessary changes might cause downtime.

Partnering with customers to build resilient services

If you have mission-critical needs and need to architect for resilience anddisaster recovery, our SRE/CRE and PSO teamscan work with you to architect your applications to bridge multiple regions andzones and can further assist you with designing High Availability (HA) systems.

If you have heightened availability requirements around specific dates,such as Black Friday and Cyber Monday, Google Cloud has a program topartner with you to check and validate your specific application running onGoogle Cloud and identify any unexpected service dependencies between yourapplication and our services.

Points of presence (POPs)

Google operates a global network of peering points of presence, which means thatcustomer traffic can travel within the Google network until it's close to itsdestination, providing users with a better experience and better security. Formore information, seeNetwork edge locations.

Geographic management of data

Data locality for Google Cloud services are governed by theterms of service, includingservice specific terms. Google understands that eachcustomer might have unique security and compliance needs. TheGoogle Cloud sales team can help you work towards meetingyour requirements.

When using regional or zonal storage resources, we strongly recommend thatyou replicate data to another region or snapshot it to a multiregional storageresource for disaster recovery purposes.

Application deployment considerations

To build highly available services and applications that can withstand zones becoming unavailable

Use the following:

• Regional resources, such as App Engineapplications,regional managed instance groups,ormanaged multiregional resources such asCloud Storage, Datastore, Firestore, or Spanner.
• Zonal resources, such as Compute Engine virtual machines, but manage yourown compute and storage redundancy across zones or across regions.

To build disaster recovery capable applications that can withstand the extended loss of entire regions

For data, use one or more of the following strategies:

• Use managed, multiregional storage services such as Cloud Storage,Datastore, Firestore, or Spanner.
• Use zonal or regional resources, but snapshot data to a multiregionalresource such as Cloud Storage, Datastore,Firestore, or Spanner.
• Use zonal or regional resources, but manage your own data replication toone or more other regions.

For compute, use the following strategy:

• Use zonal or regional resources, such as Compute Engine orApp Engine, but manually or automatically bring up yourapplication in another region (on regional failure) referring to copies ofyour primary data if the data is not already in a managed, multiregionalresource.

For more information about service dependencies,contact sales.

Additional solutions and tutorials

The following solutions and tutorials provide guidance for ensuring yourapplication is highly available and can withstand outages: