Cloud KMS locations

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 support is available for all regional locations listed in the table. Refer to the following table for Cloud HSM and Cloud EKM support for 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-south2 Delhi No Yes
asia-southeast1 Singapore Yes Yes
asia-southeast2 Jakarta Yes Yes
australia-southeast1 Sydney Yes Yes
australia-southeast2 Melbourne 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
northamerica-northeast2 Toronto No 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
southamerica-west1 Santiago No 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 support is available for all dual-regional locations listed in the table. Refer to the following table for Cloud HSM and Cloud EKM support for 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 No
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 within the European Union. 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 support is available for all multi-regional locations listed in the table. Refer to the following table for Cloud HSM and Cloud EKM support for 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 Yes
eur3 No Yes
eur5 Considered dual-regional for Cloud Storage. Yes Yes
europe Data centers within member states of the European Union1 Yes Yes
nam3 No Yes
nam6 No Yes
nam9 No Yes
us Yes Yes
1 Resources created in the europe multi-region are not stored in the europe-west2 (London) or europe-west6 (Zurich) data centers.

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 eur5 dual-region, you must have HSM quota in eur5, even if you already have quota in the single regions that participate in eur5, such as europe-west2.

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. The EKM_AVAILABLE column indicates whether the location supports Cloud External Key Manager.

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 is true.

  • If a location supports Cloud EKM keys, ekmAvailable is true.

What's next