Google Cloud services are available in locations across North America, South America, Europe, Asia, and Australia. These locations are divided into regions and zones. You can choose where to locate your applications to meet your latency, availability, and durability requirements.
Regions and zones
Regions are independent geographic areas that consist of zones. Locations within regions tend to have round-trip network latencies of under <1ms on the 95th percentile.
A zone is a deployment area for Google Cloud resources within a region. Zones should be considered a single failure domain within a region. To deploy fault-tolerant applications with high availability and help protect against unexpected failures, deploy your applications across multiple zones in a region.
To protect against the loss of an entire region due to natural disaster, have a disaster recovery plan and know how to bring up your application in the unlikely event that your primary region is lost. See application deployment considerations for more information.
For more information about the specific resources available within each location option, see our Cloud locations.
Google Cloud's services and resources can be zonal, regional, or managed by Google across multiple regions. For more information about what these options mean for your data, see geographic management of data.
Zonal resources operate within a single zone. If a zone becomes unavailable, all of the zonal resources in that zone are unavailable until service is restored. An example of a zonal resource is a Compute Engine Virtual Machine (VM) instance that resides within a specific zone.
Regional resources are resources that are redundantly deployed across all the zones within a region, for example App Engine applications, or regional managed instance groups. This gives them higher availability relative to zonal resources.
A few Google Cloud services are managed by Google to be redundant and distributed within and across regions. These services optimize availability, performance, and resource efficiency. As a result, these services require a trade-off between either latency or the consistency model. These trade-offs are documented on a product specific basis.
The following services have one or more multiregional deployment areas in addition to any regional deployment areas:
- Cloud Key Management Service
- Cloud Storage
- Cloud Spanner
- Cloud Bigtable
- Cloud Data Loss Prevention
- Cloud Healthcare API
The data associated with multiregional resources is not tied to a specific region and can be moved between regions. Regions can be added and removed from a region group. For example, buckets in the European Union location for Cloud Storage keep data at-rest inside the European Union, but at-rest data can be stored in or moved to any Cloud Storage region within the European Union (subject to terms of service and service specific terms).
Geographic management of data
Data locality for Google Cloud services is governed by the terms of service, including service specific terms. Google understands that each customer might have unique security and compliance needs. The Google Cloud sales team can help you work toward meeting your requirements.
When using regional or zonal storage resources, we strongly recommend that you replicate data to another region or snapshot it to a multiregional storage resource 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 Engine applications, regional managed instance groups, or managed multiregional resources such as Cloud Storage, Datastore, Firestore, or Cloud Spanner.
- Zonal resources, such as Compute Engine virtual machines, but manage your own 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 Cloud Spanner.
- Use zonal or regional resources, but snapshot data to a multiregional resource such as Cloud Storage, Datastore, Firestore, or Cloud Spanner.
- Use zonal or regional resources, but manage your own data replication to one or more other regions.
For compute, use the following strategy:
- Use zonal or regional resources, such as Compute Engine or App Engine, but manually or automatically bring up your application in another region (on regional failure) referring to copies of your primary data if the data is not already in a managed, multiregional resource.
For more information about service dependencies, contact sales.
Additional solutions and tutorials
The following solutions and tutorials provide guidance for ensuring your application is highly available and can withstand outages:
Learn how to use Google Cloud to build scalable and resilient application architectures using patterns and practices that apply broadly to any web application.
Configure Compute Engine instances in different regions and use HTTP load balancing to distribute traffic across the regions to increase availability across regions and provide failover in the case of a service outage.
Design your application on the Compute Engine service to be robust against failures, network interruptions, and unexpected disasters.
Learn how to add basic disaster recovery to your Cassandra installation by backing up your data into, and restoring your data from, Cloud Storage.
General principles for designing and testing a disaster recovery plan with Google Cloud.