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.

Key material for Cloud KMS and Cloud HSM keys is confined to the selected region while at rest and in use.

Support for different protection levels varies by region:

• SOFTWARE : Software keys can be created in all Cloud KMS locations.
• HSM : Multi-tenant Cloud HSM keys can be created in most Cloud KMS locations. To view locations where you can create multi-tenant Cloud HSM keys, select Supports multi-tenant HSMin the HSM supportfilter.
• HSM_SINGLE_TENANT : Single-tenant Cloud HSM keys can be created in select Cloud KMS locations. To view locations where you can create single-tenant Cloud HSM keys, select Supports single-tenant HSMin the HSM supportfilter.
• EXTERNAL : Cloud EKM keys where your EKM is accessed over the internet can be created in most Cloud KMS locations. To view locations where you can create Cloud EKM keys over the internet, select EKM by internetin the EKM supportfilter.
• EXTERNAL_VPC : Cloud EKM keys where your EKM is accessed over a VPC can be created in most Cloud KMS locations. To view locations where you can create Cloud EKM keys over a VPC, select EKM by VPCin the EKM supportfilter.

The following tables list locations available for use in Cloud KMS for different parts of the world. You can filter these locations by location type , Cloud HSM support, and Cloud EKM support:

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 .

The following location types are available to Cloud KMS:

• 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.
• Multi-regional locations: A multi-regional location's data centers are spread across a large geographical area. For example, a resource created in the europe multi-region persists in multiple data centers within the European Union. You can't choose which data centers within the multi-region will contain your data.
• The global location: The global location is a special multi-region. Its datacenters are spread throughout the world. You can't choose which data centers within the global multi-region will contain your data.

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, might 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.
• You aren't using external keys.

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 Customer-managed encryption keys (CMEK) .

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.

Multi-regional locations have separate quotas, independent of the quotas for single-region locations. For example, to create Cloud HSM resources in the eur5 multi-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 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 multi-regional location.
• When you perform cryptographic operations, such as when encrypting or decrypting data, consensus is not required. For cryptographic operations, 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 global , are best suited for read-heavy workloads.

Determining available regions

You can use the Google Cloud CLI or Cloud Key Management Service API to get a list of available regions.

gcloud kms locations list

What's next

• Learn more about Geography and regions in Google Cloud.
• See the full list of Cloud locations .