Hardware Security Modules get specified for the wrong reasons more often than not. I've seen it twice in the same year: one organisation deployed AWS CloudHSM because a compliance questionnaire asked whether cryptographic keys were stored in hardware, and another skipped it entirely for a PKI platform that genuinely needed dedicated key custody. Both decisions caused problems.

The confusion comes from conflating three things that are actually quite different: what HSMs protect, who they protect it from, and what operational overhead you accept when you add one to a platform. None of this is complicated, but the vendor documentation tends to start at "here is how to provision a cluster" rather than "here is how to decide if you need one at all."

What an HSM actually does

An HSM is a tamper-resistant device that generates and stores cryptographic keys and performs cryptographic operations. The keys never leave the device in plaintext. If you try to extract the key material physically, the device zeros itself. That is the value proposition. Everything else, certificate issuance, TLS termination, signing, is just a use case built on top of that fundamental property.

The word "tamper-resistant" is doing real work in that sentence. An HSM does not make your application more secure in a general sense. It makes key exfiltration harder by ensuring the key material exists only inside the physical device. If your threat model does not include an attacker who can exfiltrate key material from software key stores or your cloud provider's infrastructure, you may not need an HSM at all.

The question worth asking first: what specifically are you protecting the key from, and who is the attacker? If the answer is "a compromised EC2 instance," AWS KMS already prevents that. If the answer is "our cloud provider's infrastructure team," you need a dedicated HSM with a CloudHSM custom key store or an on-premise HSM. These are different threat models and they lead to different decisions.

The three options and what distinguishes them

On AWS, you have three practical paths for key management. They are not a spectrum from "less secure" to "more secure." They are different architectural choices that each involve different trade-offs.

AWS KMS with AWS-managed keys means AWS controls the key material and the HSM infrastructure. Your keys are protected inside AWS-operated HSMs that are FIPS 140-2 Level 2 validated. You get envelope encryption, automatic key rotation, and CloudTrail logging. You cannot export key material. Most regulated workloads stop here and it is the right call: the threat model for most organisations does not extend to "AWS itself is compromised."

AWS KMS with a custom key store connects KMS to a CloudHSM cluster that you control. AWS manages the KMS API surface and the key hierarchy, but the underlying cryptographic operations happen in your HSM cluster. The keys never leave your cluster. You get the operational simplicity of KMS combined with the custody properties of dedicated hardware. This is the middle path, and it is underused.

AWS CloudHSM direct means you manage everything: provisioning, clustering, client libraries, key backup, and key ceremonies. You interact with the HSM directly using PKCS#11, JCE, or the CloudHSM CLI. You take on full operational responsibility. The HSM is yours, which means the key ceremony is yours, the backup procedures are yours, and the recovery exercise is yours.

// Visual summary
The whole decision on one screen: cost, FIPS level, native integration, and the use case each path is actually for. Opens full screen.
// Decision framework
Click each option to understand the reasoning. This is a starting point, not a substitute for a proper threat model.
Start here
Does your compliance requirement specifically mandate dedicated hardware key custody (not just FIPS 140-2)?
No
Yes
Next question
Do you have an internal policy requiring you to control key material independently of your cloud provider?
Why this matters: Some regulated sectors (financial services, certain government frameworks) require that key material never passes through infrastructure you do not control. AWS KMS with AWS-managed keys does not meet this requirement even though it uses FIPS-validated HSMs, because AWS operates them.
No
Yes
AWS KMS (managed keys)
Use this when: FIPS 140-2 Level 2 satisfies your compliance requirement, your threat model does not include your cloud provider, and you want operational simplicity. This covers the majority of regulated workloads including most ISO 27001, SOC 2, and PCI-DSS implementations. Cost: pay-per-API-call, no infrastructure overhead.
KMS Custom Key Store (CloudHSM-backed)
Use this when: You need to control key material but want the KMS API surface and its integrations (S3, EBS, RDS, Secrets Manager). You get dedicated hardware custody without losing native AWS service integration. Two CloudHSM instances minimum for HA. Cost: ~$1.60/hr per HSM instance plus KMS API costs.
Next question
Do you need to use PKCS#11 or JCE directly, or run your own CA operations (PKI, code signing, payment PIN)?
Examples where this applies: Running an offline root CA, implementing payment HSM operations under PCI-PTS, code signing infrastructure where the signing key cannot touch cloud software, or UK CNI environments (Smart DCC SMKI) where the PKI chain requires dedicated hardware custody at each tier.
No
Yes
KMS Custom Key Store
This path covers most dedicated custody requirements without taking on the full operational burden of direct CloudHSM management. You satisfy the compliance requirement for dedicated hardware while AWS still handles the KMS control plane. Review your compliance framework's exact wording before deciding.
AWS CloudHSM direct
Use this when: You genuinely need direct PKCS#11/JCE access, you're running PKI operations (CA hierarchies, OCSP), or your compliance framework mandates single-tenant dedicated hardware with full key ceremony control. Be honest about whether your team has the operational capability before committing to this path.

The operational cost that doesn't appear on the pricing page

CloudHSM direct costs $1.60 per hour per instance. You need a minimum of two instances for high availability. That's roughly $2,800 per month before you've written a single line of application code. The pricing page makes this clear. What it doesn't make clear is the operational overhead that comes with it.

The key ceremony is the first thing. Before your HSM cluster is useful, you need to initialise it, create the cluster HSM administrator credentials, and establish your key backup procedures. A key ceremony for a production environment isn't a 20-minute task. Done properly, with documented procedures, witnessed steps, and tested recovery, it takes a full day and needs people in the room who understand what they're signing off on.

Backup is the second thing. CloudHSM encrypts all key material under an ephemeral backup key before exporting it. That backup key is derived from a manufacturer key baked into the hardware. Which means your backup is only useful if you have another HSM from the same manufacturer family to restore to. If Thales (who make the Luna HSMs that back CloudHSM) changes their hardware family, your backups from the old family may not restore to the new hardware. This is not theoretical. It has happened. Test your restore procedure before you need it, not when you need it.

The latency reality: HSM-backed cryptographic operations add measurable latency. On CloudHSM, a single RSA-2048 private key operation takes roughly 1 to 2 milliseconds. For a TLS handshake at low volume, imperceptible. For a high-throughput API gateway processing 10,000 connections per second, you've just added 10 to 20 seconds of aggregate crypto latency per second of throughput. Size your cluster and your performance requirements together, not sequentially.

Where HSMs genuinely add value

Having said all of that, there are environments where dedicated HSMs are the right call and not just a compliance checkbox. The patterns I've seen that genuinely justify the operational overhead are worth being specific about.

PKI hierarchies for regulated environments. When I was at Smart DCC working on the SMKI platform, the PKI supporting the smart metering infrastructure required dedicated hardware custody at each CA tier. This wasn't about FIPS compliance on paper. It was about ensuring that the keys signing device certificates for national infrastructure could not be extracted by a compromised cloud workload, a malicious insider with cloud console access, or a supply chain attack on a software KSP. The threat model was specific and the HSM decision followed from it.

Payment card PIN processing. PCI-PTS requires dedicated hardware for PIN encryption. This is non-negotiable and it's one of the few cases where "dedicated hardware" means exactly that, not "FIPS 140-2 Level 2 on shared infrastructure." CloudHSM satisfies PCI-PTS HSP requirements. AWS KMS does not.

Code signing infrastructure. If you're signing firmware, container images, or application packages for distribution, the signing key represents the trust anchor for every device or system that validates those signatures. Keeping that key in software, even encrypted software key stores, means a compromised build pipeline could sign malicious artefacts. An HSM-backed signing key requires physical interaction to use, which is a meaningful control for out-of-band verification.

The comparison that actually matters

Factor AWS KMS (managed) KMS Custom Key Store CloudHSM direct
Monthly cost (baseline) Pay per call (~$0.03/10k) ~$2,800 (2x HSM) + KMS ~$2,800+ depending on cluster size
Key ceremony required No Yes (CloudHSM initialisation) Yes (full documented ceremony)
Native AWS service integration Full (S3, EBS, RDS, Secrets Manager) Full via KMS API Manual integration only
PKCS#11 / JCE access No No Yes
Backup complexity AWS managed CloudHSM backup process Full operational responsibility
Right for most workloads Yes Specific cases Rare, justified cases only

The questions to ask before you specify

Before any HSM specification goes into a design document, four questions are worth sitting with honestly.

First: does your compliance requirement actually specify dedicated hardware, or does it specify FIPS 140-2 Level 2? These are different things. FIPS 140-2 Level 2 is satisfied by AWS KMS. "Dedicated hardware key custody" is not. Read the exact requirement, not the summary.

Second: who specifically is in your threat model that you're protecting against? If the answer is "a compromised EC2 instance," KMS handles that. If the answer is "AWS itself," you need CloudHSM. If the answer is genuinely unclear, the threat model needs work before the HSM specification does.

Third: does your team have the operational capability to run a CloudHSM cluster properly? Not "can we follow the getting started guide," but "do we have documented key ceremony procedures, tested recovery processes, and someone who owns the operational responsibility ongoing?" If the answer is no, a custom key store buys you most of the custody properties without the full operational burden.

Fourth: have you tested your backup and restore procedure in a non-production environment? If you've deployed CloudHSM and the answer is no, that is the first thing to fix, not the last.

The summary position: AWS KMS with managed keys is the right choice for most regulated workloads. A CloudHSM-backed custom key store covers most remaining cases where dedicated custody is a genuine requirement. Full CloudHSM direct is for a small set of specific use cases where PKCS#11 access, PKI operations, or payment processing requirements make it unavoidable. Specifying CloudHSM for any other reason adds cost and complexity without proportionate security benefit.

None of this is controversial if you've worked through it before. The problem is that the decision often gets made by someone reading a compliance framework for the first time, seeing the phrase "cryptographic key management" and defaulting to the most hardware-sounding option. The architecture conversation needs to happen before the procurement conversation, not after.