Geography and Regions

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

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

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.

Multi-regional 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
  • Google Cloud Bigtable
  • Google Cloud Healthcare API

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 resource for disaster recovery purposes.

Application deployment considerations

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

Use either:

  • Regional resources, such as App Engine applications, or managed multi-regional resources, such as Cloud Storage or Cloud Datastore.
  • 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, 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.

For additional information on service dependencies, please contact sales.

Additional solutions and tutorials

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

Building Scalable and Resilient Web Applications

Learn how to use Cloud Platform to build scalable and resilient application architectures using patterns and practices that apply broadly to any web application.

Cross-region Load Balancing for Compute Engine

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.

Building robust systems

Design your application on the Google Compute Engine service to be robust against failures, network interruptions, and unexpected disasters.

Using Google Cloud Storage for Cassandra Disaster Recovery

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.

Disaster Recovery Planning Guide

General principles for designing and testing a disaster recovery plan with Cloud Platform.

Şunun hakkında geri bildirim gönderin...