Within a project, Cloud Key Management Service resources can be created in one of manylocations. These represent thegeographical regions where a Cloud KMS resource is stored and canbe accessed. A key's location impacts the performance of applications using thekey.

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

Support for different protection levels varies by region:

• SOFTWARE: Software keys can be created in allCloud KMS locations.
• HSM: Multi-tenant Cloud HSM keys can be created in mostCloud KMS locations. To view locations where you can createmulti-tenant Cloud HSM keys, selectSupports multi-tenant HSMin theHSM support filter.
• HSM_SINGLE_TENANT: Single-tenant Cloud HSM keys can becreated in select Cloud KMS locations. To view locations where youcan create single-tenant Cloud HSM keys, selectSupportssingle-tenant HSM in theHSM support filter.
• EXTERNAL: Cloud EKM keys where your EKM isaccessed over the internet can be created in most Cloud KMSlocations. To view locations where you can create Cloud EKM keysover the internet, selectEKM by internet in theEKM support filter.
• EXTERNAL_VPC: Cloud EKM keys where your EKM isaccessed over a VPC can be created in most Cloud KMS locations. Toview locations where you can create Cloud EKM keys over a VPC,selectEKM by VPC in theEKM support filter.

The following tables list locations available for use in Cloud KMSfor different parts of the world. You can filter these locations bylocation type, Cloud HSM support, andCloud EKM support:

Types of locations for Cloud KMS

You can create Cloud KMS, Cloud HSM, and Cloud EKMresources in different types of locations in Google Cloud, depending onyour availability requirements. Locations are added regularly. For specificinformation about each location, seeLocations.

You can learn more aboutchoosing the best type of location.

The following location types are available to Cloud KMS:

• Regional locations: A regional location's data centers exist in aspecific geographical place. For example, a resource created in theus-central1 region is located in the central United States.
• Multi-regional locations: Logically distinct from regional keys,multi-regional location keys are physically stored in and served frommultiple regional data centers. For example, a resource created in theeurope multi-region persists in all the data centers within the EuropeanUnion. Your keys are stored in all the data centers of the multi-region.You cannot choose a subset of the multi-region.
• The global location: Theglobal location is a special multi-region.Its datacenters are spread throughout the world. You can'tchoose which data centers within the global multi-region contain yourdata.

Choosing the best type of location

As a rule, design your application so that all of its components aregeographically near each other and near your application's clients. The locationof 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 theeurope multi-region,resources persist in multiple datacenters spread across the multi-region.Creating and updating keys in multi-regional locations, including thegloballocation, might be less efficient than using a single-region location. For moreinformation, seeReading from and writing to multi-region locations.

Use theglobal 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 operationsfrequently.
• Your keys have no geographic residency requirements.
• You aren't using external keys.

For Customer-ManagedEncryption Keys (CMEK) integrations, you must use the same exact location asother resources related to the integration. Some CMEK integrations don't supporttheglobal location. For more information about CMEK integrations, seeCustomer-managed encryption keys (CMEK).

Cloud EKM resources rely on connectivity between Google Cloud andan external key management service, outside of Google Cloud. ForCloud External Key Manager resources, select a location geographically as near as possible tothe location where keys are stored on the external key management service.

Cloud HSM depends on availability of physical hardware in a location'sdatacenters. For Cloud HSM resources, select a location that supportsCloud HSM.

Cloud HSM resources have location-specificquotas.Cloud KMS quotas are global.

Multi-regional locations have separate quotas, independent of thequotas for single-region locations. For example, to create Cloud HSMresources in theeur5 multi-region, you must have HSM quota ineur5, even ifyou already have quota in the single regions that participate ineur5, such aseurope-west2.

Reading from and writing to multi-region locations

Reading and writing resources or associated metadata in multi-regionallocations, including theglobal location, may be slower than reading orwriting from a single region.

• When you create or read key versions, consensus is always required among thedatacenters storing the key material. Reads and writes to a single regionare often more efficient than those to a multi-regional location.
• When you perform cryptographic operations, such as when encrypting ordecrypting 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 thedata they protect or validate, cryptographic operations are usually moreefficient.

The trade-offs between performance and availability are unique to eachapplication. Multi-region locations, includingglobal, are best suited forread-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 aboutGeography and regions in Google Cloud.
• See the full list ofCloud locations.