Multi Region Keys, HSM and Key Material

What it is

Standard KMS keys are enough for most workloads. Some designs need keys that work in several Regions, key material you generate yourself, or hardware that only you control.

This page covers the advanced options and, as usual, the trade-off each one makes between convenience and control.

How it works

Multi Region keys

A multi Region key is a set of related KMS keys in different Regions that share the same key ID and key material. You create a primary key, then replicate it to other Regions as replica keys.

Each replica is still a separate KMS key with its own key policy and its own grants, and you manage access independently in each Region. Data encrypted under one key can be decrypted by another key in the set without calling across Regions.

Choose multi Region keys for disaster recovery, active active designs, DynamoDB global tables, Aurora global databases, and client side encryption where ciphertext moves between Regions. For single Region data, a standard key is simpler.

Imported key material

With bring your own key (BYOK), you create a KMS key with an external origin, and import key material you generated in your own system.

1. Create the KMS key with origin EXTERNAL.
2. Download a wrapping public key and an import token.
3. Wrap your key material with the public key, using a supported algorithm.
4. Import the wrapped material.

Trade-offs matter here.

• You can set an expiry date, and when it lapses the key is unusable until you reimport.
• You can delete the imported material on demand, and keep the key itself, which is a way to stop all use at once.
• Automatic rotation is not supported, so rotate by creating a new key and switching an alias.
• You are responsible for the durability of the original material, because AWS cannot regenerate it.

AWS CloudHSM

CloudHSM provides hardware security modules (HSMs) in your VPC. The HSMs are single tenant, validated to FIPS 140 Level 3, and you alone control the keys and the users. AWS manages the hardware but cannot see your keys.

Choose CloudHSM when a rule requires dedicated hardware under your sole control, when you need standard crypto APIs, or when you must run algorithms that KMS does not offer.

Custom key store

A custom key store connects KMS to your own CloudHSM cluster.

You still use KMS APIs and policies, and the key material is created and held in your HSM. This gives single tenant hardware with the familiar KMS integration, at the cost of operating the cluster. If the cluster is unavailable, the keys in it cannot be used.

External key store

An external key store (XKS) keeps the key material outside AWS, in an HSM or key manager you operate, and KMS calls it through a proxy for each cryptographic operation. Choose it for strict sovereignty rules that forbid keys leaving your premises. The cost is added latency and an availability dependency on your infrastructure.

Rotation and compromise handling

• Automatic rotation is designed for customer managed symmetric encryption keys, and the key ID stays the same. Old material is kept to decrypt older data.
• On demand rotation is available for keys when you need to rotate immediately.
• For imported material and keys in custom or external key stores, plan manual rotation: create a new key, move the alias, and re-encrypt where needed. Check the current documentation for other key types.
• If a key is compromised, stop use, re-encrypt data under a new key, and then disable and schedule deletion of the old key.

# AWS CLI: point an alias at a new key during manual rotation
aws kms update-alias --alias-name alias/app-data \
  --target-key-id 0987dcba-09fe-87dc-65ba-ab0987654321

Data encrypted with the old key still needs the old key to decrypt, so keep it until re-encryption finishes.

Choosing