Multi-Region keys, CloudHSM, and external key stores

Lesson 3 of 5 in KMS, Keys, and Certificates.

KMS keys are Regional. A key in us-east-1 cannot decrypt in eu-west-1, which is fine until you replicate data across Regions — and then you discover that a cross-Region replica of an encrypted object is useless unless the destination Region has a key that can open it. Creating a second, independent key does not solve it: different key, different material, ciphertext from the first is meaningless to the second.

Multi-Region keys solve exactly this. You create a primary key in one Region and replicate it to others; the replicas share the same key material and the same key id (they are distinguishable by their full ARNs, which still carry each Region). Because the material is identical, ciphertext encrypted in one Region can be decrypted by the related key in another with no cross-Region call at decrypt time and no re-encryption step. That is the whole feature, and it is what makes disaster recovery, S3 Cross-Region Replication of SSE-KMS objects, global DynamoDB tables and cross-Region backup copies work without a key-shaped hole in the plan.

The things that stay separate matter as much. Each replica is a real key in its own Region with its own key policy, its own grants, its own enablement state, its own tags and aliases — so you can let an application in Frankfurt decrypt while refusing the same principal in Ohio. Rotation is coordinated from the primary and propagates the new material to replicas, keeping them interoperable. You may change which Region holds the primary role. And the design boundary: multi-Region keys reduce isolation deliberately, so AWS’s own guidance is to use single-Region keys unless you have a concrete cross-Region requirement — a multi-Region key is one blast radius spanning several Regions.

The other axis is where the key material physically lives, and there are four answers.

Default KMS keys live in AWS KMS, in multi-tenant hardware security modules validated under FIPS 140-3 Level 3 (the earlier generation of KMS HSMs was validated at FIPS 140-2 Level 3; AWS publishes the current validation status per Region). The material never leaves the HSMs in plaintext. For the overwhelming majority of workloads this is the right answer, and “we need FIPS-validated hardware” on its own does not justify anything else.

AWS CloudHSM gives you single-tenant HSMs in your VPC, validated at FIPS 140-3 Level 3, where you are the only party with access to the crypto officer and crypto user credentials — AWS cannot see your keys and cannot recover them. That custody is the reason to choose it: a regulation or contract that requires sole control of key material, or an application that needs PKCS#11, JCE or OpenSSL dynamic-engine access, or offloading TLS to an HSM. The cost is operational: you size and manage the cluster across Availability Zones, you take and keep backups, you handle client configuration, and availability is now your problem rather than a Regional service’s.

A custom key store is the bridge. It is a KMS key store whose keys are backed by your CloudHSM cluster: the KMS API, the key policies, the CloudTrail records and the service integrations all work as normal, but the cryptographic operations happen in your HSMs. An external key store (XKS) goes one step further — the key material lives in a key manager outside AWS entirely, usually on premises, and KMS calls out to an XKS proxy you run for every operation. That satisfies the strictest “key material must never reside in AWS” mandates, at the price of making your proxy and your data centre a hard dependency of every encrypt and decrypt: if the proxy is unreachable, the data is unreadable. Keys in custom key stores also give up conveniences — automatic and on-demand rotation are not available for them, so rotation is manual.

Key terms: Multi-Region key (MRK), AWS CloudHSM, KMS custom key store, External key store (XKS)

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.