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.
A regional location's datacenters 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|
||Salt Lake City||Yes||Yes|
A dual-regional location's datacenters 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||Cloud HSM available||Cloud EKM available|
||Finland and Netherlands||No||Yes|
||Iowa and South Carolina||No||Yes|
A multi-regional location's datacenters are spread across a general geographical
area. For example, a resource created in the
europe multi-region persists in
multiple datacenters spread across Europe. It is not possible to predict or
control exactly which datacenters are selected or where they are located within
Cloud KMS resources can be created in the following multi-regional locations:
|Multi-region name||Cloud HSM available||Cloud EKM available|
The global location
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
resources persist in multiple datacenters spread across the multi-region.
Creating and updating keys in multi-regional locations, including the
location, may be less efficient than using a single-region location. For more
information, see Reading from and writing to multi-region locations.
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
- You don't need to store your key in an HSM
- 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
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
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
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 kms locations list
In the output from the command, the
HSM_AVAILABLE column indicates whether
the location supports Cloud HSM.
The responses from both of these methods include boolean fields related to a location's capabilities: