This document describes regional, dual-region, and multi-region instance
configurations in Spanner, and compares the [trade-offs](https://docs.cloud.google.com/spanner/docs/instance-configurations#tradeoffs),
replication topologies, and available locations for each configuration type. An
*instance configuration* defines the geographic placement and replication
topology of the databases in your instance. Choosing the right configuration
lets you balance availability, read and write latency, cost, and data residency
requirements for your workload.
## Instance configurations
When you create a Spanner instance, you must configure it as
*regional* , *dual-region* , or *multi-region*. You make this choice by selecting
an instance configuration, which determines where your data is stored for that
instance:
- [Regional configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-configurations): all the resources reside within a single Google Cloud region
- [Dual-region configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-region-configurations): all resources span two regions and reside within a single country (available in the [Spanner Enterprise Plus edition](https://docs.cloud.google.com/spanner/docs/editions-overview))
- [Multi-region configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#multi-region-configurations): all resources span more than two regions (available in the [Enterprise Plus edition](https://docs.cloud.google.com/spanner/docs/editions-overview)).
For more information about region-specific considerations, see
[Geography and regions](https://docs.cloud.google.com/docs/geography-and-regions#regions_and_zones).
Instance configurations with predefined regions and replication topologies are
called **base instance configurations** . You can create **custom instance
configurations** and add optional read-only replicas to a predefined base
instance configuration (available in [Enterprise edition and
Enterprise Plus edition](https://docs.cloud.google.com/spanner/docs/editions-overview)).
The added read-only replica must be in a region that isn't part of the existing
instance configuration. For a list of the optional read-only regions that you
can add, see the **Optional region** column under
[Regional available configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-regional)
and [Multi-region available configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-multi-region).
You can't change the replication topology of base instance configurations. For
more information, see [Read-only replicas](https://docs.cloud.google.com/spanner/docs/replication#read-only).
You can [move your instance](https://docs.cloud.google.com/spanner/docs/instance-configurations#move-instance)
from any instance configuration to any other regional, dual-region, or
multi-region instance configuration (for example, from `regional-us-central1` to
`nam3`). You can also [create a custom instance configuration with additional
replicas](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration) and
then move your instance to the new custom instance configuration. For example,
suppose your instance is in `regional-us-central1` and you want to add a
read-only replica in `us-west1`. You can create a custom instance configuration
with `regional-us-central1` as the base configuration, add `us-west1` as a
read-only replica, and then move your instance to this new custom instance
configuration.
## Regional configurations
Google Cloud services are available in [locations](https://docs.cloud.google.com/about/locations) across North
America, South America, Europe, Asia, Australia, the Middle East, and Africa.
If your users and services are located within a single region, choose a
regional instance configuration for the lowest-latency reads and writes.
For any base regional configuration, Spanner maintains three
[read-write replicas](https://docs.cloud.google.com/spanner/docs/replication#read-write), each within a different
Google Cloud [zone](https://docs.cloud.google.com/docs/geography-and-regions) in that region. Each read-write
replica contains a full copy of your operational database that is able to serve
read-write and read-only requests. Spanner uses replicas in
different zones so that if a single-zone failure occurs, your database remains
available.
### Available configurations
Spanner offers the following base regional instance
configurations. To request an optional read-only replica region that isn't
listed in the following table, submit the
[optional read-only replica request form](https://docs.google.com/forms/d/e/1FAIpQLSfw9Rj4p4KA8oLu7MhIpSyPRd-4qxqazwsFZIY-_tkNrpWFcw/viewform).
Google uses these requests to gauge demand for future regions and might not
respond directly to your submission.
| Base configuration name | Region description | Optional region |
|---|---|---|
| **Americas** |||
| `regional-northamerica-northeast1` | Montréal  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-northamerica-northeast2` | Toronto  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-northamerica-south1` | Querétaro | |
| `regional-southamerica-east1` | São Paulo  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-southamerica-west1` | Santiago  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-us-central1` | Iowa  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | Read-only: `asia-northeast1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `asia-south1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `europe-west1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-2-OR) `europe-west2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `europe-west9` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `us-west3` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) |
| `regional-us-east1` | South Carolina | Read-only: `us-central1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `europe-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `europe-west3` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) |
| `regional-us-east4` | Northern Virginia | |
| `regional-us-east5` | Columbus | Read-only: `us-central1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) |
| `regional-us-south1` | Dallas  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-us-west1` | Oregon  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-us-west2` | Los Angeles | |
| `regional-us-west3` | Salt Lake City | |
| `regional-us-west4` | Las Vegas | |
| **Europe** |||
| `regional-europe-central2` | Warsaw  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-north1` | Finland  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-north2` | Stockholm  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-southwest1` | Madrid  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west1` | Belgium  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | Read-only: `us-central1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-1-OR) |
| `regional-europe-west2` | London  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west3` | Frankfurt | |
| `regional-europe-west4` | Netherlands  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west6` | Zurich  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west8` | Milan  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west9` | Paris  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| `regional-europe-west10` | Berlin | |
| `regional-europe-west12` | Turin  [Low CO~2~](https://cloud.google.com/sustainability/region-carbon#region-picker) | |
| **Asia Pacific** |||
| `regional-asia-east1` | Taiwan | |
| `regional-asia-east2` | Hong Kong | |
| `regional-asia-northeast1` | Tokyo | |
| `regional-asia-northeast2` | Osaka | |
| `regional-asia-northeast3` | Seoul | |
| `regional-asia-south1` | Mumbai | |
| `regional-asia-south2` | Delhi | |
| `regional-asia-southeast1` | Singapore | |
| `regional-asia-southeast2` | Jakarta | |
| `regional-asia-southeast3` | Bangkok | |
| `regional-australia-southeast1` | Sydney | |
| `regional-australia-southeast2` | Melbourne | |
| **Middle East** |||
| `regional-me-central1` | Doha | |
| `regional-me-central2` | Dammam | |
| `regional-me-west1` | Tel Aviv | |
| **Africa** |||
| `regional-africa-south1` | Johannesburg | |
- *1-OR*: One optional replica. You can
create a custom regional instance configuration and add one optional read-only
replica. For more information, see
[Create a custom instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration).
- *2-OR*: Up to two optional replicas. You
can create a custom regional instance configuration and add one or two
optional read-only replicas. Where possible, add two optional replicas to help
maintain low read latency. For more information, see
[Create a custom instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration).
### Replication
Base regional configurations contain three
[read-write replicas](https://docs.cloud.google.com/spanner/docs/replication#read-write). Every Spanner
mutation requires a write quorum that's composed of a majority of voting
replicas. In regional configurations, two of the three replicas form a write
quorum. For more information about leader regions and voting replicas, see
[Replication](https://docs.cloud.google.com/spanner/docs/replication).
You can [create a custom regional instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration)
and add optional read-only replicas. Read-only replicas can help scale reads and
support low-latency stale reads. These read-only replicas don't take part in
write quorums and don't function as a standalone disaster recovery (DR)
solution. Instance availability is determined by the quorum of voting replicas. If the Spanner instance goes offline, the read-only replicas also go offline shortly afterward and can't serve reads, including stale reads.
The replicas don't affect the
[Spanner \>= 99.99% SLA](https://cloud.google.com/spanner/sla) for
regional instances.
You can add locations listed in the **Optional region** column as optional
read-only replicas. If your preferred read-only replica location isn't listed,
you can [request a new optional read-only replica region](https://docs.google.com/forms/d/e/1FAIpQLSfw9Rj4p4KA8oLu7MhIpSyPRd-4qxqazwsFZIY-_tkNrpWFcw/viewform).
For more information, see [Read-only replicas](https://docs.cloud.google.com/spanner/docs/replication#read-only).
### Performance best practices for regional configurations
For optimal performance, follow these best practices:
- [Design a schema](https://docs.cloud.google.com/spanner/docs/schema-design) that prevents hotspots and other performance issues.
- Place critical compute resources within the same region as your Spanner instance.
- Provision enough [compute capacity](https://docs.cloud.google.com/spanner/docs/compute-capacity) to keep high-priority total CPU utilization under 65%.
- For information about the amount of throughput per Spanner node, see [Performance for regional configurations](https://docs.cloud.google.com/spanner/docs/performance#regional-performance).
## Dual-region configurations
> [!NOTE]
> **Note:** This feature is available with the Spanner Enterprise Plus edition. For more information, see the [Spanner editions overview](https://docs.cloud.google.com/spanner/docs/editions-overview).
Dual-region configurations let you replicate the database's data in
multiple zones across two regions in a single country, as defined by the
instance configuration.
Dual-region configurations do the following:
- Serve reads from two regions in a single country.
- Meet data residency requirements.
- Provide higher availability and SLAs than regional configurations.
Spanner offers dual-region configurations in Australia, Canada,
Germany, India, and Japan.
For information about the amount of throughput per Spanner node,
see [Performance for dual-region configurations](https://docs.cloud.google.com/spanner/docs/performance#dual-region-performance).
### Available configurations
Spanner offers the following base dual-region instance
configurations:
| Base configuration name | Resource location | Regions |
|---|---|---|
| `dual-region-australia1` | au (Australia) | Sydney: `australia-southeast1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-L), [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) Melbourne: `australia-southeast2` [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) |
| `dual-region-canada1` | ca (Canada) | Toronto: `northamerica-northeast2` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-L), [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) Montréal: `northamerica-northeast1` [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) |
| `dual-region-germany1` | de (Germany) | Berlin: `europe-west10` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-L), [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) Frankfurt: `europe-west3` [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) |
| `dual-region-india1` | in (India) | Mumbai: `asia-south1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-L), [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) Delhi: `asia-south2` [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) |
| `dual-region-japan1` | jp (Japan) | Tokyo: `asia-northeast1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-L), [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) Osaka: `asia-northeast2` [*2RW+1W*](https://docs.cloud.google.com/spanner/docs/instance-configurations#dual-2RW) |
- *L*: Default leader region. For more information,
see [Modify the leader region of a database](https://docs.cloud.google.com/spanner/docs/modifying-leader-region).
-
*2RW+1W*: Two read-write
replicas and one witness replica in the region.
### Benefits
Dual-region instances offer these primary benefits:
- **99.999% availability**: provides 99.999% availability across two regions in the same country, which is greater than the 99.99% availability that Spanner regional configurations provide.
- **Data distribution**: automatically replicates your data between the two regions with strong consistency.
- **Data residency** : meets residency requirements in the countries listed under dual-region [Available configurations](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-dual).
### Replication
A dual-region configuration contains six replicas, three in each region. One of
the regions is designated as the default leader region (listed in the previous
table). You can [change the leader region of a database](https://docs.cloud.google.com/spanner/docs/modifying-leader-region#changing_the_leader_region_of_a_db).
In each region, there are two read-write replicas and one
[witness replica](https://docs.cloud.google.com/spanner/docs/replication#witness). When both regions are
healthy and running in a dual-region configuration, all six replicas participate
in the dual-region quorum. Forming a write quorum and committing a transaction
requires at least two voting replicas in each region.
### Failover and failback
After you create a dual-region configuration, you can view the
**Dual-region quorum health timeline** metric on the
[**System insights**](https://docs.cloud.google.com/spanner/docs/monitoring-console) dashboard. This metric is only
available for dual-region configurations. It shows the health of three quorums:
- The dual-region quorum: `Global`
- The single-region quorum in each region (for example, `Sydney` and `Melbourne`)
The timeline shows an orange bar when there's a service disruption. You can hold
the pointer over the orange bar to see the start and end times of the
disruption.
For a faster recovery time objective (RTO), monitor or set up an alert on the
**Dual-region quorum health timeline** metric. This metric helps you decide when
to manually fail over during regional failures. After you trigger instance
failover, the failover usually completes within one minute.
Spanner also supports automatic, Google-managed failovers, which
might take up to 45 minutes from the time the failure is first detected. The
longer RTO is due to Google's service-wide monitoring. Google gathers additional
signals to verify that the entire region is disrupted and validate that there's
region-level impact. This also ensures that a failover results in better overall
service for users in the configuration.
To fail over and fail back manually, see
[Change dual-region quorum](https://docs.cloud.google.com/spanner/docs/change-dual-region-quorum).
Consider the following when making manual failover and failback decisions:
- If all three quorums are healthy, then no action is needed.
- If one of the regions shows disruption, then there's probably a regional
service disruption. This might reduce availability for the databases running
in your dual-region quorum, and writes might fail if a quorum can't be
established and transactions time out. Google automatically performs
failover and failback when it detects a regional outage, but you can also
manually fail over for a faster RTO. On the **System insights** dashboard,
observe error rates and latency in your database. If error rates or latency
increase, you can manually *fail over* , changing the dual-region quorum to a
single-region quorum in the healthy region. If you manually fail over, you
must manually *fail back* to a dual-region quorum after the disrupted region
is healthy again.
- If the dual-region quorum shows disruption even though both single regions
are healthy, then there's a network partitioning issue. The two regions can
no longer communicate with each other, so each region shows healthy even
though the overall system isn't. In this scenario, you can manually fail
over to the default leader region so that your database can continue serving
writes without changing the leader region. After the network partition issue
is resolved and the dual-region quorum is healthy again, you must manually
fail back.
Dual-region configurations provide a zero recovery point objective (RPO) because
there's no data loss during a regional outage or when a network partition issue
arises.
To check the mode (single or dual) of your dual-region quorum, see
[Check dual-region quorum](https://docs.cloud.google.com/spanner/docs/change-dual-region-quorum#check).
#### Failover and failback best practices
Failover and failback best practices include:
- Don't fail over to a single region if no region failures or disruptions occur. Failing over to a single region increases the possibility of overall system unavailability if that single region fails.
- Be mindful when selecting the failover region. Failing over to the disrupted region results in database unavailability, which is unrecoverable until that region is back online. To verify, you can use a [bash script](https://docs.cloud.google.com/spanner/docs/change-dual-region-quorum#rest-gcloud) to check the health of your single-region quorum before performing the failover.
- If the unhealthy region is the default leader region, [change the default leader region](https://docs.cloud.google.com/spanner/docs/modifying-leader-region#change-leader-region) to the failover region after performing the failover. After confirming both regions are healthy again, fail back, and then change the leader region back to your original leader region.
- Remember to manually fail back if you performed a manual failover.
### Limitations
You can't create a custom dual-region instance configuration, and you can't add
read-only replicas to a dual-region instance configuration.
### Performance best practices for dual-region configurations
For optimal performance, follow these best practices:
- [Design a schema](https://docs.cloud.google.com/spanner/docs/schema-design) that prevents hotspots and other performance issues.
- For optimal write latency, place compute resources for write-heavy workloads within or close to the default leader region.
- To avoid single-region dependency for your workloads, place critical compute resources in both regions of your dual-region configuration.
- For information about the amount of throughput per Spanner node, see [Performance for dual-region configurations](https://docs.cloud.google.com/spanner/docs/performance#dual-region-performance).
## Multi-region configurations
> [!NOTE]
> **Note:** This feature is available with the Spanner Enterprise Plus edition. For more information, see the [Spanner editions overview](https://docs.cloud.google.com/spanner/docs/editions-overview).
Spanner base regional configurations replicate data between
multiple zones within a single region. However, a base regional configuration
might not be optimal if:
- Your application often needs to read data from multiple geographic locations (for example, to serve data to users in both North America and Asia).
- Your writes originate from a different location than your reads (for example, if you have large write workloads in North America and large read workloads in Europe).
While you can add optional read-only replicas in other regions to a
[custom regional configuration](https://docs.cloud.google.com/spanner/docs/instance-configurations#regional-replication) to serve low-latency
stale reads in these scenarios, multi-region configurations can also:
- Maintain write availability across read-write regions with automatic leader failover during regional disruptions.
- Provide higher availability and SLAs than regional configurations.
Multi-region configurations let you replicate your databases in multiple zones
across multiple regions, as defined by the instance configuration. Most base
multi-region configurations contain two read-write regions, each with two
read-write replicas in separate zones, and one witness region. The exception is
the `asia2` configuration, which has no witness region and instead contains
three read-write regions: two regions with two read-write replicas each, and a
third region with one read-write replica. These read-write replicas let you read
data with lower latency from multiple locations close to or within the regions
in the configuration.
There are trade-offs though, because in a multi-region configuration, the quorum
(read-write) replicas are spread across more than one region. You might notice
additional network latency when these replicas communicate with each other to
form a write quorum. Reads don't require a quorum. The result is that your
application achieves faster reads in more places at the cost of a small increase
in write latency. For more information, see
[The role of replicas in writes and reads](https://docs.cloud.google.com/spanner/docs/replication#role-of-replicas).
### Available configurations
Spanner offers the following base multi-region instance
configurations. To request an optional read-only replica region that isn't
listed in the following tables, submit the
[optional read-only replica request form](https://docs.google.com/forms/d/e/1FAIpQLSfw9Rj4p4KA8oLu7MhIpSyPRd-4qxqazwsFZIY-_tkNrpWFcw/viewform).
Google uses these requests to gauge demand for future regions and might not
respond directly to your submission.
#### One continent
The following table lists multi-region configurations that span a single
continent:
| Base configuration name | Resource location | Read-write regions | Read-only regions | Witness region | Optional region |
|---|---|---|---|---|---|
| `asia1` | global | Tokyo: `asia-northeast1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Osaka: `asia-northeast2` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Seoul: `asia-northeast3` | Read-only: `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-east5` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `asia2` [*A*](https://docs.cloud.google.com/spanner/docs/instance-configurations#A) | global | Mumbai: `asia-south1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Delhi: `asia-south2` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Singapore: `asia-southeast1` [*1R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1R) | None | None | |
| `eur3` | eu (European Union) | Belgium: `europe-west1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Netherlands: `europe-west4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Finland: `europe-north1` | Read-only: `us-central1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-east4` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `eur5` | global | London: `europe-west2` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Belgium: `europe-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Netherlands: `europe-west4` | Read-only: `us-central1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-east1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `eur6` | global | Netherlands: `europe-west4` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Frankfurt: `europe-west3` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Zurich: `europe-west6` | Read-only: `us-east1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) |
| `eur7` | eu (European Union) | Milan: `europe-west8` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Frankfurt: `europe-west3` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Turin: `europe-west12` | |
| `nam3` | us (United States) | Northern Virginia: `us-east4` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) South Carolina: `us-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Iowa: `us-central1` | Read-only: `asia-south1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `asia-southeast1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `asia-southeast2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west4` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west9` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-east5` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west4` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west8` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam6` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) South Carolina: `us-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Oregon: `us-west1` [*1R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1R) Los Angeles: `us-west2` [*1R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1R) | Oklahoma: `us-central2` | |
| `nam7` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Northern Virginia: `us-east4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Oklahoma: `us-central2` | Read-only: `us-east1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) `us-south1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) |
| `nam8` | us (United States) | Los Angeles: `us-west2` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Oregon: `us-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Salt Lake City: `us-west3` | Read-only: `asia-northeast1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) `asia-southeast1` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) `europe-west2` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) `europe-west3` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) `us-east5` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam9` | us (United States) | Northern Virginia: `us-east4` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Iowa: `us-central1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Oregon: `us-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | South Carolina: `us-east1` | |
| `nam10` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Salt Lake City: `us-west3` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Oklahoma: `us-central2` | Read-only: `us-east4` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam11` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) South Carolina: `us-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Oklahoma: `us-central2` | Read-only: `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam12` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Northern Virginia: `us-east4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Oregon: `us-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Oklahoma: `us-central2` | |
| `nam13` | us (United States) | Oklahoma: `us-central2` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Iowa: `us-central1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Salt Lake City: `us-west3` | |
| `nam14` | global | Northern Virginia: `us-east4` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Montréal: `northamerica-northeast1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | South Carolina: `us-east1` | |
| `nam15` | us (United States) | Dallas: `us-south1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Northern Virginia: `us-east4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Iowa: `us-central1` | Read-only: `us-central2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-east1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `us-west3` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam16` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Northern Virginia: `us-east4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Columbus: `us-east5` | Read-only: `us-west2` [*2-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2-OR) |
| `nam22` | us (United States) | Columbus: `us-east5` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) South Carolina: `us-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Northern Virginia: `us-east4` | Read-only: `us-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam23` | us (United States) | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Las Vegas: `us-west4` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Dallas: `us-south1` | Read-only: `asia-northeast1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `australia-southeast2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west1` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) `europe-west3` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam24` [*A*](https://docs.cloud.google.com/spanner/docs/instance-configurations#A) | us (United States) | Northern Virginia: `us-east4` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Oregon: `us-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | None | Iowa: `us-central1` | |
#### Three continents
The following table lists multi-region configurations that span three
continents:
| Base configuration name | Resource location | Read-write regions | Read-only regions | Witness region | Optional region |
|---|---|---|---|---|---|
| `nam-eur-asia1` | global | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Oklahoma: `us-central2` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Belgium: `europe-west1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) Taiwan: `asia-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | South Carolina: `us-east1` | Read-only: `us-west2` [*1-OR*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1-OR) |
| `nam-eur-asia3` | global | Iowa: `us-central1` [*L*](https://docs.cloud.google.com/spanner/docs/instance-configurations#L),[*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) South Carolina: `us-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Belgium: `europe-west1` [*1R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1R) Netherlands: `europe-west4` [*1R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#1R) Taiwan: `asia-east1` [*2R*](https://docs.cloud.google.com/spanner/docs/instance-configurations#2R) | Oklahoma: `us-central2` | |
- *L*: default leader region. For more information, see
[Modify the leader region of a database](https://docs.cloud.google.com/spanner/docs/modifying-leader-region).
- *1R*: one replica in the region.
- *2R*: two replicas in the region.
- *2RW+1W*: two read-write replicas and one witness
replica in the region.
- *1-OR*: one optional replica. You can create a
custom regional or multi-region instance configuration and add one optional
read-only replica. For more information, see
[Create a custom instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration).
- *2-OR*: up to two optional replicas. You can
create a custom regional or multi-region instance configuration and add one
or two optional read-only replicas. Where possible, consider adding two
optional replicas to help maintain low read latency. For more information,
see
[Create a custom instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration).
- *A*: This instance configuration is restricted with an
allowlist. To get access, contact your Technical Account Manager.
The resource location of a multi-region configuration defines its disaster
recovery zone guarantee. While this location sets the overall boundary for all
data throughout its lifecycle, the data itself is only stored at rest within
your selected replica locations.
### Benefits
Multi-region instances offer these primary benefits:
- **99.999% availability**, which is greater than the 99.99% availability that
Spanner regional configurations provide.
- **Data distribution**: Spanner automatically replicates your
data between regions with strong consistency. This lets you store your data
where it's used, which can reduce latency and improve the user experience.
- **External consistency** : Even though Spanner replicates across
geographically distant locations, you can still use Spanner as if it
were a database running on a single machine. Transactions are serializable,
and the order of transactions within the database is the same as the order in
which clients observe the transactions to have been committed. External
consistency is a stronger property than "strong consistency," which is
offered by some other products. Read more about this property in [TrueTime
and external consistency](https://docs.cloud.google.com/spanner/docs/true-time-external-consistency).
### Replication
Most base multi-region configurations contain two regions that are designated as
**read-write regions** , each of which contains two read-write replicas. One of
these read-write regions is designated as the *default leader region* , which
means that it contains your database's leader replicas. Spanner
also places a witness replica in a third region called a **witness region** . The
exception is the `asia2` configuration, which places a fifth read-write replica
in a third read-write region instead of using a witness region.
Each time a client issues a mutation to your database, a write quorum forms,
consisting of one of the replicas from the default leader region and any two of
the additional four voting replicas. (The quorum could be formed by replicas
from two or three of the regions that make up your configuration, depending on
which other replicas participate in the vote.) In addition to these five voting
replicas, some base multi-region configurations contain read-only replicas for
serving low-latency reads. The regions that contain read-only replicas are
called **read-only regions**.
In general, the voting regions in a multi-region configuration are placed
geographically close---less than a thousand miles apart---to form a
low-latency quorum that enables fast writes. However, the regions are still far
enough apart---typically, at least a few hundred miles---to avoid
coordinated failures. In addition, if your client application is in a non-leader
region, Spanner uses leader-aware routing to route read-write
transactions dynamically to reduce latency in your database. For more
information, see
[Why read-only and witness replicas?](https://docs.cloud.google.com/spanner/docs/replication#aside-why-read-only-and-witness-replicas) and
[Leader-aware routing](https://docs.cloud.google.com/spanner/docs/leader-aware-routing).
You can
[create a custom multi-region instance configuration](https://docs.cloud.google.com/spanner/docs/create-manage-configurations#create-configuration) with
optional read-only replicas. Any custom read-only replicas you create can't be
included in write quorums and don't function as a standalone disaster recovery
(DR) solution. Instance availability is determined by the quorum of voting replicas. If the Spanner instance goes offline, the read-only replicas also go offline shortly afterward and can't serve reads, including stale reads. You can add locations
listed in the **Optional region** column as optional read-only replicas. If your
preferred read-only replica location isn't listed, you can
[request a new optional read-only replica region](https://docs.google.com/forms/d/e/1FAIpQLSfw9Rj4p4KA8oLu7MhIpSyPRd-4qxqazwsFZIY-_tkNrpWFcw/viewform).
For more information, see [Read-only replicas](https://docs.cloud.google.com/spanner/docs/replication#read-only).
> [!NOTE]
> **Note:** if you are interested in more detailed information about how data is replicated in Spanner, and about the different types of replicas and their roles in reads and writes, see [Replication](https://docs.cloud.google.com/spanner/docs/replication).
### Performance best practices for multi-region configurations
For optimal performance, follow these best practices:
- [Design a schema](https://docs.cloud.google.com/spanner/docs/schema-design) that prevents hotspots and other performance issues.
- For optimal write latency, place compute resources for write-heavy workloads within or close to the default leader region.
- For optimal read performance outside of the default leader region, use staleness of at least 15 seconds.
- To avoid single-region dependency for your workloads, place critical compute resources in at least two regions. A good option is to place them next to the two different read-write regions so that any single-region outage won't affect all of your application.
- Provision enough [compute capacity](https://docs.cloud.google.com/spanner/docs/compute-capacity) to keep high-priority total CPU utilization under 45% in each region.
- For information about the amount of throughput per Spanner node, see [Performance for multi-region configurations](https://docs.cloud.google.com/spanner/docs/performance#multi-region-performance).
## Move an instance
You can move your Spanner instance from any instance
configuration to any other instance configuration, including between regional,
dual-region, and multi-region configurations. Moving your instance doesn't cause
downtime, and Spanner continues to provide the usual
[transaction guarantees](https://docs.cloud.google.com/spanner/docs/transactions#rw_transaction_properties),
including strong consistency, during the move.
For more information about moving a Spanner instance, see
[Move an instance](https://docs.cloud.google.com/spanner/docs/move-instance).
## Configure the default leader region
To change the location of your database's default leader region to be closer to
connecting clients to reduce application latency, you can change the leader
region for any Spanner instance that uses a dual-region or
multi-region configuration. For instructions on changing the location of the
leader region, see [Change the leader region of a database](https://docs.cloud.google.com/spanner/docs/modifying-leader-region#changing_the_leader_region_of_a_db).
The only regions eligible to become the default leader region for your database
are the read-write regions in your [dual-region](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-dual)
or [multi-region](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-multi-region)
configuration.
The leader region is responsible for handling all database writes, therefore if
most of your traffic comes from one geographic region, you can move it to that
region to reduce latency. Updating the default leader region is a metadata
operation that doesn't move data between regions. The new value takes a few
minutes to take effect.
The only regions eligible to become the default leader region for your database
are the read-write regions in your
[dual-region](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-dual) or
[multi-region](https://docs.cloud.google.com/spanner/docs/instance-configurations#available-configurations-multi-region) configuration. For
instructions, see
[Change the leader region of a database](https://docs.cloud.google.com/spanner/docs/modifying-leader-region#changing_the_leader_region_of_a_db).
> [!NOTE]
> **Note:** In the event that the default leader region fails or isn't available, Spanner automatically places your database's leader replicas in the second read-write region of your instance configuration, ensuring high availability and no impact to your application.
Changing the default leader region is a metadata operation that uses a
long-running operation. If needed, you can
[check the progress of the long-running operation](https://docs.cloud.google.com/spanner/docs/manage-and-observe-long-running-operations#check_the_progress_of_a_long-running_schema_update_operation).
## Trade-offs: regional versus dual-region versus multi-region configurations
The following table summarizes the trade-offs between regional, dual-region,
and multi-region configurations:
| Configuration | Availability | Latency | Cost | Data locality |
|---|---|---|---|---|
| Regional | 99.99% | Lower write latencies within region. | Lower cost; see [pricing](https://docs.cloud.google.com/spanner/pricing). | Enables geographic data governance. |
| Dual-region | 99.999% | Lower read latencies from two geographic regions; a small increase in write latency. | Higher cost; see [pricing](https://docs.cloud.google.com/spanner/pricing). | Distributes data across two regions in a single country. |
| Multi-region | 99.999% | Lower read latencies from multiple geographic regions; a small increase in write latency. | Higher cost; see [pricing](https://docs.cloud.google.com/spanner/pricing). | Distributes data across multiple regions within the configuration. |
## What's next
- Learn how to [create a Spanner instance](https://docs.cloud.google.com/spanner/docs/create-manage-instances#create-instance).
- Learn more about [Google Cloud geography and regions](https://docs.cloud.google.com/docs/geography-and-regions).