KMS custom key storeAn AWS KMS custom key store is either a CloudHSM key store or an external key store (XKS). Where the key material sits, who operates it, and when XKS is the one you need.
An AWS KMS custom key store is a key store associated with key material outside the default AWS KMS store. AWS documents two kinds. A CloudHSM key store is backed by an AWS CloudHSM cluster in your account. An external key store (XKS) is backed by a key manager you operate outside AWS, reached through an XKS proxy. (AWS KMS: Key stores, AWS KMS: External key stores)
Search results mix the names. "AWS KMS custom key store", "external key store" and "XKS" are not three products. Custom key store is the parent. XKS is one of the two children. CloudHSM is the other.
This page is the comparison. The build steps, proxy and operating model for XKS are the AWS XKS implementation guide.
| Option | Where the key material is | What you control |
|---|---|---|
| Customer managed key in AWS KMS | Inside AWS KMS | Key policy, grants, rotation, who may call the key |
| CloudHSM key store (a custom key store) | A CloudHSM cluster in your AWS account. The hardware is in an AWS data center. You control the HSM users and the keys | The cluster. AWS operates the data center |
| External key store (a custom key store) | Your key manager, outside AWS. Each KMS key maps to an external key | The key manager and the XKS proxy. AWS calls out when it needs a cryptographic operation |
With a standard customer managed key, you control access. AWS holds the key material. A custom key store is the step you take when that is not enough, and the next question is whether "not enough" means a dedicated HSM inside AWS or key material that never sits on AWS infrastructure.
| CloudHSM key store | External key store (XKS) | |
|---|---|---|
| Custom key store | Yes | Yes |
| Key material | In your CloudHSM cluster, physically in AWS | In your external key manager |
| Who generates the key material | AWS KMS generates non-extractable key material in your CloudHSM cluster | Your key manager. AWS KMS cannot create, view, manage or delete those keys. It talks only to your XKS proxy |
| Availability of crypto operations | AWS operates the HSM hardware. You operate the cluster | Yours: the proxy and the key manager. If they stop, KMS operations on those keys stop. No AWS SLA on that path |
| Latency | Inside the AWS network | A round trip to your key manager. AWS recommends a Region with a round-trip time of 35 ms or less |
| Key types | Symmetric encryption KMS keys only | Symmetric encryption KMS keys only. The external key is 256-bit AES |
| Fit | Dedicated HSM control, keys may reside in AWS | Only when you have an explicit requirement to keep key material outside AWS, and the workload is low throughput |
Both types are limited to symmetric encryption KMS keys. Asymmetric keys, HMAC, imported key material, automatic rotation and multi-Region keys are not available in a custom key store.
Sources: AWS KMS key stores and external key stores. AWS states that a custom key store is not more secure than the standard KMS key store. It also states that external key stores are not the default choice: use one only when you have an explicit requirement to keep key material outside AWS. The availability and latency risk is yours, and AWS describes them as a fit for low-throughput workloads such as EBS volume encryption or RDS, not for high-volume S3, analytics or DynamoDB.
XKS uses double envelope encryption: AWS KMS encryption plus your external key. Ciphertext is at least as strong as standard KMS. It is additive. (XKS implementation guide)
Applications keep calling AWS KMS. AWS services that support customer managed keys for symmetric encryption can use a key in an external key store. Whether you should is a separate question: AWS's current guidance reserves this path for low-throughput encryption, such as EBS or RDS, because the proxy round trip does not suit high-volume S3 or DynamoDB. The change on the key path is:
You take on availability, durability and latency for that path. Some AWS services cache data keys briefly, so revoking the external key does not freeze every cached operation in the same instant. The XKS guide covers the proxy, the failure modes and the operating checklist.
Ask the requirement in this order:
"We want a custom key store" is not yet a design. Name which of the two stores, and name the sentence in the regulation that forces the choice.
DuoKey is an external key manager for the XKS path. AWS KMS calls the XKS proxy. The key material stays in DuoKey, outside AWS. The same pattern is how Snowflake Tri-Secret Secure can keep its customer-managed key off AWS: the CMK is an XKS key. (Snowflake Tri-Secret Secure guide, DuoKey for AWS XKS)
DuoKey does not replace a CloudHSM cluster. If the requirement is a dedicated HSM inside AWS, that is CloudHSM, and this product is the wrong answer.
What is an AWS KMS custom key store?
A KMS key store backed by key material outside the default KMS store. The two types are a CloudHSM key store and an external key store.
Is an external key store the same as XKS?
Yes. XKS is AWS's name for the external key store: a custom key store whose keys live in your key manager, behind an XKS proxy.
Is a custom key store the same as CloudHSM?
A CloudHSM key store is one kind of custom key store. An external key store is the other. CloudHSM keeps the HSM in AWS. XKS keeps the key manager outside AWS.
Can I use a custom key store for asymmetric keys or automatic rotation?
No. Both custom key store types support symmetric encryption KMS keys only. Asymmetric keys, HMAC, imported key material, automatic rotation and multi-Region keys stay on the standard KMS key store. An external key is a 256-bit AES key. (AWS KMS: Key stores)
Where is the setup guide?
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
