Dedicated Key Management with AWS CloudHSM - FIPS 140-3 Level 3 Compliant Encryption
Achieve FIPS 140-3 Level 3 compliant key management with dedicated HSM instances. Learn when to choose CloudHSM over KMS and how to integrate both through KMS custom key stores.
Overview of CloudHSM
CloudHSM is a service that manages encryption keys using dedicated hardware security modules (HSMs). While KMS uses multi-tenant shared HSMs, CloudHSM provides dedicated HSM instances. The current-generation instance type is hsm2m.medium, and clusters in FIPS mode are validated at FIPS 140-3 Level 3 (certificate #4703, as of August 2026). The FIPS 140-2 Level 3 validation (certificate #4218) held by the previous-generation hsm1.medium moved to the CMVP historical list on January 4, 2026. Therefore, when you explain to auditors on the basis of the validation level, refer to the 140-3 side of the current generation. When you create a cluster, you choose either FIPS mode or non-FIPS mode, and you cannot change the mode after creation (non-FIPS mode can be selected only for hsm2m.medium). Backups also cannot be restored across modes, so the choice of mode must be finalized in the initial design. hsm2m.medium can store up to 16,666 keys per cluster and supports mutual TLS (mTLS) between clients and HSMs. To connect, you use Client SDK 5 (5.9.0 or later). Keys are generated and stored within the HSM, and key material is never exported in plaintext outside the HSM. AWS staff cannot access your keys by design, and full ownership of keys belongs to the user. Because clusters in FIPS mode meet the requirements of PCI PIN, PCI-3DS, and SOC 2, you choose FIPS mode for configurations that handle the compliance requirements of financial, healthcare, and government organizations.
Choosing Between KMS and CloudHSM
KMS is suitable for the majority of use cases, with low operational overhead and extensive integration with AWS services. Because both KMS and the FIPS mode of CloudHSM protect keys in HSMs validated at FIPS 140-3 Level 3 (as of August 2026), the rule of “choosing the one with the higher validation level” no longer holds today. You make the selection along the following five axes. The first is whether single-tenant exclusivity is required: CloudHSM gives you exclusive use of an HSM that only you use, while KMS uses a shared HSM fleet operated by AWS. The second is whether you need direct control over cryptographic processing: with CloudHSM, applications can operate the HSM directly through the standard interfaces PKCS#11, JCE, CNG/KSP, and OpenSSL, while KMS is limited to operations through the KMS API. The third is key custody, that is, who holds the key material and who creates the key users: with CloudHSM, both creating HSM users and managing the key lifecycle are the user's responsibility, and AWS does not touch the key material. The fourth is compliance-specific requirements: when audit demands extend to dedicated hardware or your own key hierarchy, CloudHSM becomes a prerequisite. The fifth is operational responsibility and availability: with KMS, AWS takes care of availability and patching, while with CloudHSM, the user takes care of cluster design, backups, and credential management. KMS custom key stores combine the advantages of both, maintaining the KMS API and its integrations while storing keys in CloudHSM. In terms of throughput, KMS symmetric key operations share a request rate quota. The defaults are 10,000 requests per second in many Regions, 20,000 requests per second in Tokyo, Ohio, Singapore, Sydney, Frankfurt, and London, and 100,000 requests per second in Northern Virginia, Oregon, and Ireland (values listed in the official documentation as of August 2026). Asymmetric key operations such as those with RSA keys and ECC keys have a separate quota of 1,000 requests per second, keys in AWS CloudHSM key stores and external key stores have 1,800 requests per second, and these two cannot be raised. Because the processing performance of a single HSM on the CloudHSM side is not published, you measure the throughput you need with your own workload and adjust it with the number of HSMs.
Cluster Design and High Availability
A CloudHSM cluster places HSM instances across multiple Availability Zones with automatic key synchronization for high availability. A configuration with HSMs in at least two AZs is recommended; if one HSM fails, processing continues on the HSM in the other AZ. The client SDK distributes requests across HSMs in the cluster using round-robin and automatically fails over on failure. HSM backups are automatically encrypted and stored in S3, used for cluster restoration and cross-region copying. Standard interfaces including PKCS#11, JCE, and OpenSSL allow applications to perform cryptographic operations, minimizing changes to existing application code.
Common Use Cases
Key use cases for CloudHSM include SSL/TLS offloading, database encryption (TDE), code and document signing, private certificate authority (CA) key storage, financial transaction signing (PCI DSS compliance), and tokenization. For SSL/TLS offloading, web server private keys are stored in the HSM, with signing operations delegated via the OpenSSL engine, eliminating private keys from EC2 instance memory. Integration with Oracle TDE and Microsoft SQL Server TDE to protect database encryption keys in HSM is also common. Combining with AWS Private CA to store CA private keys in CloudHSM and execute certificate signing in the HSM reduces the risk of CA key compromise.
Pricing and Operational Considerations
Pricing (as of August 2026, Northern Virginia / Tokyo) is based only on the running time of HSM instances and does not change with the number of keys stored or the number of HSM users. The unit price per hsm2m.medium HSM is 1.60 USD per hour in Northern Virginia and 1.81 USD per hour in Tokyo. Usage of less than 1 hour is also billed as 1 hour. Converted to 730 hours per month, a one-HSM configuration costs about 1,168 USD / about 1,321 USD, and placing two HSMs in two AZs for high availability costs about 2,336 USD / about 2,643 USD. Empty clusters that contain no HSMs and the storage of backups are free of charge, and data transfer is billed separately. There is no free tier, and there are no discounts through reserved purchases. KMS basically costs 1 USD per month per customer managed key and 0.03 USD per 10,000 requests, and there is also a free tier of 20,000 requests per month (operations of the GenerateDataKeyPair family and asymmetric key operations are both outside the free tier). Because the difference in fixed costs is large, you use CloudHSM only in the scope where there are dedicated HSM or specific compliance requirements. As an operational consideration, losing Crypto Officer (CO) credentials means you permanently cannot access the keys in the cluster, so secure storage of credentials is essential. HSM user management (CU: Crypto User, CO: Crypto Officer) operates independently from AWS IAM, using HSM-internal user management commands. To initialize the cluster, you place the issued certificate in /opt/cloudhsm/etc/ on Linux and match the name of the configuration file, then run cluster activate in the CloudHSM CLI (Client SDK 5), set the initial admin password, and activate admin (CO). After that, you create CUs as the CO and allow applications to perform key operations. The CloudHSM Management Utility (CMU) and Key Management Utility (KMU) of the previous generation are tools dedicated to Client SDK 3 and hsm1.medium and cannot be used with the current generation.
When a Dedicated HSM Is Needed
Many encryption use cases can be handled sufficiently with a managed key management service. Even so, a dedicated HSM becomes necessary when there are specific requirements. A typical case is when regulations or compliance require key management on dedicated hardware that meets a defined certification level. A dedicated HSM is also an option when you want to guarantee that your company fully occupies and manages the keys and that no other party, including the cloud provider, can touch them at all. There are also situations that call for your own cryptographic processing or compliance with specific industry standards. A practical way to divide the roles is to use a dedicated HSM only for the parts with such strict requirements and to cover everything else with managed services.
Summary
CloudHSM is a service that manages encryption keys on dedicated hardware security modules and meets strict compliance requirements premised on FIPS 140-3 Level 3 validation. KMS custom key stores let you operate CloudHSM keys through the KMS API, and standard interfaces like PKCS#11 and JCE make integration with existing applications straightforward. Because the fixed costs are high, it is important to adopt CloudHSM only in the scope where the requirements for exclusivity and key custody are clear, and to plan credential management and high-availability design carefully.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS CloudHSM official page
- AWS KMS official page
- AWS Private Certificate Authority official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.