Google Cloud Platform 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 Cloud Platform resources within a region. Zones should be considered a single failure domain within a region. In order to deploy fault-tolerant applications with high availability, you should deploy your applications across multiple zones in a region to help protect against unexpected failures.
To protect against the loss of an entire region due to natural disaster, you should 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 on the specific resources available within each location option, see our Global Data Center Locations.
The Cloud Platform's services and resources can be zonal, regional, or managed by Google across multiple regions. For more information on 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 Google Compute Engine 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. This gives them higher availability relative to zonal resources.
A few Cloud Platform 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 on either latency or the consistency model. These trade-offs are documented on a product specific basis.
The following services have one or more multi-regional deployment areas in addition to any regional deployment areas:
- Google Cloud Datastore
- Google Cloud KMS
- Google Cloud Storage
- Google BigQuery
- Google Cloud Spanner
The data associated with multi-regional resources is not tied to a specific region and can be moved between regions and regions can be added and removed from a region group. For example, buckets in the European Union location for Google 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 Cloud Platform services is governed by the terms of service, including service specific terms. Google understands each customer might have unique security and compliance needs. The Cloud Platform sales team can help you work towards meeting your requirements.
When using regional or zonal storage resources, it is highly recommended that you replicate data to another region or snapshot it to a multi-regional storage resources for disaster recovery purposes.
Application deployment considerations
- To build highly available services and applications that can withstand zones becoming unavailable
- 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, multi-regional storage services such as Cloud Storage, Cloud Datastore, or Cloud Spanner.
- Use zonal or regional resources, but snapshot data to a multi-regional resource such as Cloud Storage or Cloud Datastore.
- 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, multi-regional resource.
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 Cloud Platform 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 Google 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, Google Cloud Storage.
General principles for designing and testing a disaster recovery plan with Cloud Platform.