Within a project, Cloud Key Management Service resources can be created in one of many locations. These represent the geographical regions where a Cloud KMS resource is stored and can be accessed. A key's location impacts the performance of applications using the key. Some resources, such as Cloud HSM keys, are not available in every location.
Key material for Cloud KMS and Cloud HSM keys is confined to the selected region while at rest and in use.
Types of locations for Cloud KMS
You can create Cloud KMS, Cloud HSM, and Cloud EKM resources in different types of locations in Google Cloud, depending on your availability requirements. Locations are added regularly. For specific information about each location, see Locations.
You can learn more about choosing the best type of location.
Regional locations
A regional location's data centers exist in a specific geographical place. For
example, a resource created in the us-central1
region is located in the
central United States.
Cloud KMS resources can be created in the following regional locations:
Region name | Region description | Cloud HSM available | Cloud EKM available |
---|---|---|---|
asia-east1 |
Taiwan | Yes | Yes |
asia-east2 |
Hong Kong | Yes | Yes |
asia-northeast1 |
Tokyo | Yes | Yes |
asia-northeast2 |
Osaka | Yes | Yes |
asia-northeast3 |
Seoul | Yes | Yes |
asia-south1 |
Mumbai | Yes | Yes |
asia-southeast1 |
Singapore | Yes | Yes |
asia-southeast2 |
Jakarta | Yes | Yes |
australia-southeast1 |
Sydney | Yes | Yes |
europe-central2 |
Warsaw | Yes | Yes |
europe-north1 |
Finland | Yes | Yes |
europe-west1 |
Belgium | Yes | Yes |
europe-west2 |
London | Yes | Yes |
europe-west3 |
Frankfurt | Yes | Yes |
europe-west4 |
Netherlands | Yes | Yes |
europe-west6 |
Zürich | Yes | Yes |
northamerica-northeast1 |
Montréal | Yes | Yes |
us-central1 |
Iowa | Yes | Yes |
us-east1 |
South Carolina | Yes | Yes |
us-east4 |
Northern Virginia | Yes | Yes |
us-west1 |
Oregon | Yes | Yes |
us-west2 |
Los Angeles | Yes | Yes |
us-west3 |
Salt Lake City | Yes | Yes |
us-west4 |
Las Vegas | Yes | Yes |
southamerica-east1 |
São Paulo | Yes | Yes |
Dual-regional locations
A dual-regional location's data centers exist in two specific geographical
places. For example, a resource created in the nam4
dual-regional location
persists in datacenters in both the central and eastern United States.
Cloud KMS resources can be created in the following dual-regional locations:
Dual-region name | Dual-region description (bold indicates third replica) | Cloud HSM available | Cloud EKM available | |
---|---|---|---|---|
asia1 |
Tokyo, Osaka, and Seoul | No | Yes | |
eur4 |
Finland, Netherlands, and Belgium | No | Yes | |
eur5 |
London, Netherlands, and Belgium | Yes | Yes | |
nam4 |
Iowa, South Carolina, and Oklahoma | No | Yes |
Multi-regional locations
A multi-regional location's data centers are spread across a general
geographical area. For example, a resource created in the europe
multi-region
persists in multiple data centers spread across Europe. It is not possible to
predict or control exactly which data centers are selected or where they are
located within the multi-region.
Cloud KMS resources can be created in the following multi-regional locations:
Multi-region name | Notes | Cloud HSM available | Cloud EKM available |
---|---|---|---|
global |
Yes | No | |
asia |
Yes | Yes | |
asia1 |
Considered dual-regional for Cloud Storage. | No | No |
eur3 |
No | No | |
eur5 |
Considered dual-regional for Cloud Storage. | No | No |
europe |
Yes | Yes | |
nam3 |
No | No | |
nam6 |
No | No | |
us |
Yes | Yes |
The global location
The global
location is a special multi-region. Its datacenters are spread
throughout the world. It is not possible to predict or control exactly which
datacenters are selected or where they are located.
Choosing the best type of location
As a rule, design your application so that all of its components are geographically near each other and near your application's clients. The location of your keys is an important aspect of your application's design. After creation, a key cannot be moved or exported.
When using a multi-regional location, such as the europe
multi-region,
resources persist in multiple datacenters spread across the multi-region.
Creating and updating keys in multi-regional locations, including the global
location, may be less efficient than using a single-region location. For more
information, see Reading from and writing to multi-region locations.
Use the global
location if all of the following are true:
- Your application's components are distributed globally
- You have infrequent reads or writes but use other cryptographic operations frequently
- Your keys have no geographic residency requirements
For Customer-Managed Encryption Keys (CMEK) integrations, you must use the same
exact location as other resources related to the integration. Some CMEK
integrations don't support the global
location.
For more information about CMEK integrations, see the relevant section of Encryption at rest.
Dual-regional locations are only supported for use with Cloud Storage resources which also use a dual-regional location.
Cloud EKM resources rely on connectivity between Google Cloud and an external key management service, outside of Google Cloud. For Cloud External Key Manager resources, select a location geographically as near as possible to the location where keys are stored on the external key management service.
Cloud HSM depends on availability of physical hardware in a location's datacenters. For Cloud HSM resources, select a location that supports Cloud HSM.
Cloud HSM resources have location-specific quotas. Cloud KMS quotas are global.
Dual-regional and multi-regional locations have separate quotas, independent of
the quotas for single-region locations. For example, to create Cloud HSM
resources in the nam4
dual-region, you must have HSM quota in nam4
, even if
you already have quota in the single regions that participate in nam4
, such as
us-central1
.
Reading from and writing to multi-region locations
Reading and writing resources or associated metadata in dual-regional or
multi-regional locations, including the global
location, may be slower than
reading or writing from a single region.
- When you create or read key versions, consensus is always required among the datacenters storing the key material. Reads and writes to a single region are often more efficient than those to a dual-regional or multi-regional location.
- When you perform cryptographic operations, such as when encrypting or decrypting data, consensus is not required. For cryptographic operations, dual- regional and multi-regional locations perform similarly to single-region locations.
- When you store your keys in a location or locations geographically near the data they protect or validate, cryptographic operations are usually more efficient.
The trade-offs between performance and availability are unique to each
application. Multi-region locations, including dual-region or global
, are
best suited for read-heavy workloads.
Determining available regions
You can use the Cloud SDK or Cloud Key Management Service API to get a list of available regions.
gcloud
gcloud kms locations list
In the output from the command, the HSM_AVAILABLE
column indicates whether
the location supports Cloud HSM.
API
Use the
Locations.get
and
Locations.list
methods.
The responses from both of these methods include boolean fields related to a location's capabilities:
If a location supports Cloud HSM keys,
hsmAvailable
istrue
.If a location supports Cloud EKM keys,
ekmAvailable
istrue
.
What's next
- Learn more about Geography and Regions in Google Cloud.
- See the full list of Cloud Locations.