AWS CloudHSM
Dedicated, single-tenant hardware security modules in your VPC — you own the keys, AWS can't touch them.
Verified against AWS documentation · 2026-08-27
Key facts
- 01Single-tenant hardware in your VPC — FIPS 140-3 Level 3 validated (hsm2m.medium); older hsm1.medium is deprecated
- 02You control keys end-to-end: AWS has zero visibility and zero recovery — lose your crypto credentials and the keys are gone forever
- 03Cluster of 1–28 HSMs; HA is YOUR job — run at least 2 HSMs across 2 AZs, keys sync automatically within the cluster
- 04Talks industry-standard APIs: PKCS#11, JCE (Java), CNG/KSP (Windows) — apps integrate directly, not via AWS APIs
- 05Can back KMS as a custom key store when you need KMS integration but keys must live in dedicated hardware
Exam triggers
Phrases and scenarios that point here.
- "FIPS 140-3 Level 3" or "dedicated/single-tenant hardware" → CloudHSM, not KMS
- "Contractual or regulatory requirement that AWS must have no access to keys"
- Migrating an on-prem HSM workload (PKCS#11 app, Oracle TDE, SSL/TLS offload) to AWS
- "Full control over key hierarchy, algorithms, and key export" — KMS keys can't leave KMS, CloudHSM keys can
Not this service
- Managed encryption integrated with AWS services (S3, EBS, RDS) → KMS
- Storing/rotating passwords, API keys, DB credentials → Secrets Manager
- Payment PIN/card workloads → AWS Payment Cryptography
Use cases
- 01A bank's contract says the cloud provider must never be able to read signing keys — CloudHSM's tamper-resistant hardware makes that a hardware guarantee, not a policy promise
- 02Lifting an on-prem PKCS#11 application (document signing, certificate authority) to AWS without rewriting its crypto layer
- 03Oracle database TDE where the compliance team requires master keys in a dedicated HSM, not shared infrastructure
- 04KMS custom key store: keep the convenience of KMS envelope encryption while auditors get their dedicated-hardware checkbox
- 05Monthly code-signing ceremony: spin HSMs up from backup, sign, delete them — pay only for the hours used
How it's charged
- 01Hourly fee per HSM (prorated to the second), from launch until you delete it — no upfront cost, no free tier, no reserved pricing
- 02The fee is flat regardless of how many crypto operations you run — an idle HSM costs the same as a busy one
- 03An empty cluster costs nothing, and stored encrypted backups are free — the scale-to-zero-and-restore pattern is the main cost lever
- 04Real HA means 2+ HSMs, so budget roughly double the single-HSM hourly rate for production
- 05Data transfer to/from HSMs billed separately at standard EC2 rates
