AWS CloudHSM
Dedicated cryptographic hardware for existing HSM-based applications and single-tenant key protection
CloudHSM is easy to mistake for a stronger version of KMS. KMS already protects your keys in tamper-resistant security hardware, and that is all most people need. Think of a bank. KMS is the vault service: staff use your keys only on your instruction. CloudHSM rents you a private vault room in the same bank. The steel is no stronger; the room, its rules, and the work of running it are yours. The room is important for two reasons. Some existing software, like certain database and certificate-authority products, was built to talk to a dedicated key device; KMS doesn't speak that language and CloudHSM does, so the software keeps working. Others simply must have hardware reserved for them alone. Keys created inside can be set so applications use them without copying. Guard the application too: anything allowed to use a key can still abuse it. If neither reason is yours, stay with KMS.
CloudHSM provides dedicated, single-tenant hardware security modules (HSMs) in your VPC. Applications use Client SDK 5 through interfaces such as PKCS #11, Java JCE, or Windows KSP. These support existing HSM-based software, including Oracle database encryption and Windows certificate services. Standard KMS uses AWS APIs, so it cannot directly replace those integrations. Choose CloudHSM for interface compatibility or an explicit dedicated-hardware requirement. AWS maintains the hardware and creates encrypted backups. You manage HSM users, key permissions, client software, and capacity. Persistent keys replicate across HSMs; sensitive keys need non-extractable settings.
Key Capabilities
- Dedicated, single-tenant hsm2m.medium HSMs with FIPS 140-3 Level 3 validation in FIPS mode
- Hardware-based encryption, digital signing, and message authentication using supported algorithms
- Application integration through PKCS #11, Java JCE, and Windows CNG/KSP using supported client software
- HSM users, key permissions, and non-extractable key settings managed separately from AWS resource administration
- Persistent-key replication, client-side load balancing, and automatic encrypted cluster backups
- KMS custom key stores for symmetric encryption keys backed by your cluster; asymmetric KMS keys and automatic key rotation are unsupported
Gotchas & Constraints
Gotcha #1: HSM credentials are separate from IAM. AWS cannot recover lost HSM credentials; keep two HSM admins. Gotcha #2: Each HSM incurs hourly charges until deleted, even when idle. A compromised authorized application can still misuse a protected key. Constraints: Clusters are regional. Use multiple Availability Zones; AWS recommends three HSMs across different zones for newly generated key durability. Retry interrupted operations and check supported algorithms for your client interface and cluster mode.
An insurer moves two Oracle databases containing customer records from its data center to EC2. Its existing encryption setup uses PKCS #11 to access a master key held in an on-premises HSM. The migration must preserve that supported database integration. RDS for Oracle could not host this setup: AWS manages the TDE wallet on its instances and provides no OS access to install the PKCS #11 library. The databases move to EC2, where the documented CloudHSM integration runs. A regular KMS customer-managed key cannot directly replace the HSM because the database expects a PKCS #11 library, while KMS provides AWS API operations. The insurer chooses CloudHSM and configures Oracle to use AWS's PKCS #11 library. CloudHSM protects the master encryption key; Oracle continues encrypting the database files. The team deploys three hsm2m.medium HSMs across three Availability Zones. It verifies the master-key transition and restores a test database backup before cutover. Separate HSM credentials control access to the keys. The team also tests cluster recovery and retries during HSM replacement.
The Result
the databases move to AWS while retaining their supported HSM-based key-management approach, with the added responsibility of operating the CloudHSM cluster.