AWS CloudHSM

AWS CloudHSM provides dedicated Hardware Security Module (HSM) instances in the AWS Cloud. You have exclusive, single-tenant access to the HSM hardware.

Key Differences from KMS

• Single-tenant: dedicated HSM appliance (vs KMS multi-tenant)
• FIPS 140 Level 3: hsm1.medium is FIPS 140-2 Level 3 validated, hsm2m.medium is FIPS 140-3 Level 3. KMS HSMs are also FIPS 140-3 Level 3 validated, so the real differentiator is single-tenancy and exclusive key control, not the FIPS level
• Full Key Control: you manage the HSM, AWS cannot access your keys
• Industry Standards: supports PKCS#11, JCE, CNG/KSP, and OpenSSL interfaces

Use Cases

• Regulatory requirements mandating single-tenant FIPS 140 Level 3 HSMs (PCI DSS, HIPAA, FedRAMP)
• Custom key store for AWS KMS (HSM-backed KMS keys)
• TLS/SSL offloading for web servers
• Certificate authority (CA) private key protection
• Code signing and document signing

Architecture

• Deploy HSMs in a cluster across multiple AZs for high availability
• Keys are automatically replicated within the cluster
• HSMs run inside your VPC: accessible only through ENIs

How It Goes Wrong in Practice

CloudHSM's headline feature, that AWS cannot access your keys, is also its sharpest edge. Every classic CloudHSM incident is some version of the same story: the customer exercised full key control and then lost the thing that control depended on. The most damaging pattern is credential loss for the crypto officer (CO) role. AWS has no backdoor into the HSM by design, so if your team loses the CO password and has no recovery path, administrative operations on the cluster are simply gone; there is no support ticket that fixes cryptography. The second pattern is availability negligence: a cluster run with a single HSM in a single Availability Zone has no redundancy, and teams discover during an AZ event that the "hardware-backed" dependency at the bottom of their TLS or database encryption stack is a single point of failure. AWS guidance and the cluster model both push toward multiple HSMs across AZs, with keys replicated automatically within the cluster, precisely because the HSM is usually the most critical and least redundant component people deploy. The third pattern is network self-sabotage: HSMs are reachable only through elastic network interfaces in your VPC, so an overly aggressive security group change can cut every application off from its keys at once, which looks exactly like a cryptographic outage but is just a firewall rule. Treat the HSM cluster like the tier-zero infrastructure it is: documented credential ceremonies, multiple HSMs, restrictive but carefully change-managed security groups, and tested procedures for restoring from cluster backups.

Practical Check: Inspect Cluster Health

The v2 CLI gives you the full cluster picture in one call:

aws cloudhsmv2 describe-clusters --filters states=ACTIVE

In the output, check the cluster State (ACTIVE is healthy; DEGRADED means at least one HSM has a problem), the Mode field (FIPS or NON_FIPS), the HsmType, and the Hsms list, which shows each HSM's state, Availability Zone, subnet, and ENI IP address. If the Hsms list contains a single entry, or every entry sits in the same Availability Zone, that is the finding: your key infrastructure has no redundancy. The same output also shows the cluster's SecurityGroup, which is the object to audit when applications suddenly cannot reach their keys.

Frequently Asked Questions

When should I choose CloudHSM over KMS?
Default to KMS. It is cheaper, fully managed, and integrated with nearly every AWS service. CloudHSM earns its cost when you have a hard requirement KMS cannot meet: FIPS 140 Level 3 single-tenant hardware, direct PKCS#11/JCE/CNG application integration, running your own certificate authority, or a mandate that AWS must have no possible access path to key material. Many organizations that think they need CloudHSM actually need a KMS custom key store, which puts KMS's integration surface on top of CloudHSM-held keys.

What HSM hardware types exist?
CloudHSM offers two HSM types, hsm1.medium and the newer hsm2m.medium, and AWS recommends the newer generation for new deployments. The describe-clusters output shows which type a cluster uses, along with whether it runs in FIPS or non-FIPS mode.

Does AWS back up my HSM cluster?
Clusters have a backup policy and retention policy, visible in the describe-clusters output, and keys are replicated across the HSMs in a cluster. But backups protect against hardware loss, not against you: they cannot recover a lost crypto officer credential, and they restore into the same trust model where only you hold the keys to administer them. Your operational procedures are part of the security boundary.

Can AWS staff see or recover my keys?
No. That is the product's core guarantee and its core risk. Plan your credential management, quorum procedures, and backup testing as if no outside help exists, because for key material, none does.