# Google Cloud multi-regional deployment archetype

This section of the
[Google Cloud deployment archetypes](https://docs.cloud.google.com/architecture/deployment-archetypes)
guide describes the multi-regional deployment archetype.

In a cloud architecture that uses the multi-regional deployment archetype, the
application runs in two or more
[Google Cloud regions](https://docs.cloud.google.com/docs/geography-and-regions#regions_and_zones).
Application data is
replicated across all the regions in the architecture. To ensure fast and
synchronous replication of data, the regions are typically within a continent.

The following diagram shows the cloud topology for an application that runs in
two Google Cloud regions:

The preceding diagram shows two isolated multi-tier application stacks that run
independently in two Google Cloud regions. In each region, the application
runs in three zones. The databases in the two regions are replicated. If the
workload has a low recovery point objective (RPO) or if it requires strong
cross-region consistency of data, then the database replication needs to be
synchronous. Otherwise, the databases can be replicated asynchronously. User
requests are routed to regional load balancers by using a
[DNS routing policy](https://docs.cloud.google.com/dns/docs/policies-overview#routing_policies).
If an outage occurs
in any one of the two regions, DNS routes user requests to the load balancer in
the other region.

## Use cases

The following sections provide examples of use cases for which the
multi-regional deployment archetype is an appropriate choice.

### High availability for geographically dispersed users

We recommend a multi-regional deployment for applications that are
business-critical and where high availability and robustness against region
outages are essential. If a region becomes unavailable for any reason (even a
large-scale disruption caused by a natural disaster), users of the application
don't experience any downtime. Traffic is routed to the application in the other
available regions. If data is replicated synchronously, the recovery time
objective (RTO) is near zero.

### Low latency for application users

If your users are within a specific geographical area, such as a continent, you
can use a multi-regional deployment to achieve an optimal balance between
availability and performance. When one of the regions has an outage, the global
load balancer sends requests that originate in that region to another region.
Users don't perceive significant performance impact because the regions are
within a geographical area.

### Compliance with data residency and sovereignty requirements

The multi-regional deployment archetype can help you meet regulatory
requirements for
[data residency and operational sovereignty](https://cloudsovereignty.withgoogle.com/).
For example, a country in Europe might require that all user data be stored and
accessed in data centers that are located physically within the country. You can
deploy the application to
[Google Cloud regions in Europe](https://cloud.google.com/about/locations#europe)
and use DNS with a
[geofenced routing policy](https://docs.cloud.google.com/dns/docs/policies-overview#geo-fenced-policy)
to route traffic to the appropriate region.

## Design considerations

When you provision and manage redundant resources across locations, the volume
of cross-location network traffic can be high. You also store and replicate data
across multiple regions. When you build an architecture that uses the
multi-regional deployment archetype, consider the potentially higher cost of
cloud resources and network traffic, and the complexity of operating the
deployment. For business-critical applications, the availability advantage of a
multi-region architecture might outweigh the increased cost and operational
complexity.

## Reference architecture

For a reference architecture that you can use to design a multi-regional
deployment on Compute Engine VMs, see
[Multi-regional deployment on Compute Engine](https://docs.cloud.google.com/architecture/multiregional-vms).