Hardware Security Modules - Dedicated Management of Cryptographic Keys with AWS CloudHSM
Explains dedicated management of cryptographic keys with AWS CloudHSM. Covers exclusive use of a single-tenant HSM, direct control through PKCS#11 and JCE, key custody, the selection criteria versus KMS, migration to the hsm2m.medium generation, and TLS offload and Oracle TDE integration.
Cryptographic Key Management Requirements and Where CloudHSM Fits
Managing cryptographic keys is the foundation of information security. On AWS, there are two options for confining key material to hardware: AWS KMS (Key Management Service) and AWS CloudHSM. As of August 2026, both KMS and the current generation of CloudHSM in FIPS mode handle key material on HSMs (Hardware Security Modules) validated at FIPS 140-3 Level 3. KMS protects keys with a fleet of HSMs validated at FIPS 140-3 Security Level 3, and plaintext key material never leaves the HSM boundary and is never written to disk. CloudHSM clusters in FIPS mode have also obtained FIPS 140-3 Level 3 validation with the hsm2m.medium generation described later. The earlier framing of "choose the one with the higher validation level" therefore can no longer be used for current selection decisions. Today the differences lie in whether you have dedicated key hardware to yourself, how far you control the keys directly by your own hand, and who holds custody (the managing party) of the keys. What CloudHSM provides is a single-tenant, general-purpose HSM, and key generation / storage / use within a cluster all take place entirely inside the HSM. Users and roles are managed in the HSM's own authentication system outside IAM, so the scope of responsibility that you bear widens accordingly. AWS handles hardware provisioning, patching, and storage of encrypted backups, but it cannot access the keys inside the HSM, and the contents of data plane communication are not visible to AWS either. KMS, on the other hand, is a multi-tenant managed service in which the service takes on key creation, rotation, and availability. CloudHSM becomes a candidate when compliance requirements or internal policies call for "exclusive use of dedicated key hardware" or "explicit identification of where key material resides and who manages it."
Migration to the hsm2m.medium Generation and the Current State of FIPS Validation
CloudHSM HSM types are in the middle of a generational transition. The following is the situation as of August 2026. The new-generation hsm2m.medium became generally available on August 20, 2024, and from April 2025 onward it is no longer possible to create new clusters with the previous-generation hsm1.medium in any Region. Automatic migration by CloudHSM began in January 2026, and hsm1.medium reached end of support on March 31, 2026. FIPS validation also differs by generation. hsm1.medium was validated under FIPS 140-2 Level 3 certificate #4218, but it moved to the CMVP historical list on January 4, 2026. hsm2m.medium is validated under FIPS 140-3 Level 3 certificate #4703. The design also changed with hsm2m.medium. You can choose FIPS mode or non-FIPS mode when creating a cluster, and this setting cannot be changed after creation. A cluster can store a total of 16,666 keys, of which up to 3,333 can be asymmetric keys. The client and the HSM authenticate each other with mutual TLS, and Client SDK 5.9.0 or later is required. Two migration paths are available. One is to opt in to the migration managed by CloudHSM and move the existing cluster to the new generation. The other is to create a new hsm2m.medium cluster from an hsm1.medium backup, switch over, and then delete the old cluster. If you choose the former, one prerequisite is that all connections over the last 7 days used Client SDK 5.9 or higher (5.13 or higher if you run ECDSA Verify). The other prerequisites are that the cluster is ACTIVE and that it has 27 HSMs or fewer. Backups cannot be restored across FIPS mode and non-FIPS mode. As for generations, only one direction is possible, restoring an hsm1.medium backup to an hsm2m.medium cluster in FIPS mode, and you cannot restore an hsm2m.medium backup to an hsm1.medium cluster. This means you cannot take a path such as replacing a cluster that you have operated in non-FIPS mode with one in FIPS mode.
Cluster Architecture and Standard APIs
CloudHSM is managed in units of clusters. When you create a cluster, you specify a VPC and subnets in your own AWS account, and each time you add an HSM, CloudHSM places an ENI (Elastic Network Interface) in the specified subnet. The HSM itself resides in a separate VPC owned by CloudHSM, and applications communicate with the HSM through this ENI. It is sometimes described as "the HSM is placed inside your VPC," but strictly speaking, only the network interface appears in your subnet. Because an HSM and its corresponding ENI are placed in the same AZ, the recommended configuration is to prepare one subnet per AZ and spread HSMs across two or more AZs. Keys are synchronized automatically among the HSMs in a cluster, so even if one HSM is lost, you can continue using the keys on the remaining HSMs. On the application side, you install Client SDK 5 to use the HSM. The PKCS#11 library conforms to PKCS#11 version 2.40, and lets C/C++ applications and HSM-aware middleware work with keys. For Java, a provider built on the JCE (Java Cryptography Extension) provider framework is offered, letting Java applications operate on keys in the HSM. For Windows, a CNG provider and a KSP (Key Storage Provider) are offered, and for use through OpenSSL, the OpenSSL Dynamic Engine and the OpenSSL Provider are available. Because all of these are industry-standard interfaces, changes to existing applications are often limited to connection settings and key references, and there is almost no need to rewrite cryptographic code. The client software is commonly installed on EC2 instances in the VPC, but it does not have to be EC2 as long as the environment can reach the HSM's ENI. You allow traffic from clients to the HSM using the security group that is generated when the cluster is created.
Choosing Between CloudHSM and KMS - Five Selection Criteria
Now that the FIPS validation level can no longer separate the two, the choice is made along the following five criteria. The first criterion is single-tenant exclusive use. With CloudHSM, you occupy your own dedicated HSMs on an hourly basis, and the keys on that hardware exist only in your cluster. KMS shares a multi-tenant HSM fleet operated by AWS. The second criterion is direct control. CloudHSM is a good fit when you need to call HSM mechanisms directly through PKCS#11, JCE, CNG/KSP, or OpenSSL, or when existing middleware is designed on the assumption of an HSM connection. KMS operations are performed through the KMS API and integrations with each AWS service. The third criterion is key custody. With CloudHSM, you create users and roles yourself and also design taking and restoring backups as part of your own operations. With the KMS standard key store, AWS takes on storage and redundancy of key material. As a middle ground between the two, KMS offers three types of key store. In the terminology of the current documentation, there is the usual "standard key store." In addition, there is the "AWS CloudHSM key store," which keeps key material in your own CloudHSM cluster while operations are performed with the KMS API. There is also the "external key store," which keeps key material in a key management system outside AWS. If you want to combine server-side encryption of AWS services such as S3, EBS, and RDS with your own HSMs, going through this AWS CloudHSM key store is the standard path. The fourth criterion is compliance-specific requirements. If a requirement refers only to "a module validated at FIPS 140-3 Level 3," KMS alone can satisfy it. A difference arises when the requirement specifies single tenancy, physical exclusive possession of keys, or HSM operation under a particular audit scheme. CloudHSM clusters in FIPS mode are described as usable for meeting PCI PIN, PCI-3DS, and SOC2 requirements. You also need to check that the assumptions vary by region, for example the HSMs for KMS in the China Regions are certified by OSCCA rather than validated by CMVP. The fifth criterion is operational responsibility and assurance of availability. With KMS, the service takes care of availability, patching, and scaling. With CloudHSM, you are responsible for sizing the number of HSMs, distributing them across AZs, the procedure for restoring from backups, and keeping up with Client SDK and HSM generations. The pricing structures are also very different, as described later, so the practical order is to check against these five criteria whether "exclusive use and direct control are truly requirements" before choosing CloudHSM.
TLS Offload and Database Encryption
A representative use case for CloudHSM is TLS/SSL offload. You keep the TLS private keys of web servers (Nginx, Apache) inside CloudHSM, and perform private key operations during the TLS handshake inside the HSM. Because the private key is not loaded into the server's memory or onto its disk, you can avoid the risk of the private key itself being taken out even if the server is compromised. For Nginx and Apache, a configuration that sets up CloudHSM as an OpenSSL Dynamic Engine is officially documented, and for Java's Tomcat, a procedure for TLS offload through JSSE is provided. For database encryption, you can manage the master encryption key of Oracle TDE (Transparent Data Encryption) with CloudHSM. By specifying the CloudHSM client as the PKCS#11 library in the Oracle Database settings, the database encryption keys are protected inside the HSM. In addition, official setup procedures are also available for configuring Windows Server as a certificate authority and keeping the CA's private key in the HSM. In each of these cases, the core value lies in the property of never letting the key leave the HSM, and the application side only needs to reference the key through standard APIs.
CloudHSM Pricing
The unit prices shown here are the values for the N. Virginia and Tokyo Regions as of August 2026, and monthly amounts are calculated on the basis of 730 hours per month. We start by organizing the billing dimensions. The only thing CloudHSM charges for is the running time of HSMs provisioned in a cluster. Any fraction of an hour is billed as a full hour, and the unit price varies by region. The unit price does not change with the number of users or the number of stored keys. In addition to this, network data transfer to and from the HSM is billed separately at standard data transfer rates. Conversely, there is no charge for a cluster that contains no HSMs or for storage of the encrypted backups that CloudHSM takes automatically. The unit price per hsm2m.medium is $1.60 per hour in N. Virginia and $1.81 per hour in Tokyo. On a 730-hour basis, that comes to about $1,168 per HSM in N. Virginia and about $1,321 in Tokyo. A high-availability configuration that places one HSM in each of two AZs costs about $2,336 per month in N. Virginia and about $2,643 per month in Tokyo. Because unit prices differ by region, check the values for the target region individually when estimating. As for minimum charges and the free tier, CloudHSM has no free tier, and no upfront discounts like Reserved Instances are offered. On the other hand, for uses that do not need to run all the time, such as clusters for testing, reducing the HSMs to zero during periods of non-use and resuming by restoring from a backup is described as a cost measure. KMS pricing is basically $1 per key per month (prorated hourly) and $0.03 per 10,000 requests, and a free tier of 20,000 requests per month applies in total across all Regions. However, GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext are not covered by the free tier. Sign, Verify, Encrypt, Decrypt, and GetPublicKey on asymmetric keys are not covered either. In a configuration that uses an AWS CloudHSM key store, both sets of charges add up. In the example published on the official KMS pricing page, one key, about 1.99 million billable requests, and two HSMs running for 31 days total $2,387.77 per month, of which $2,380.80 is the HSM running charge. From this breakdown, you can see that the cost of dedicated HSMs dominates the cost of the whole configuration.
Operational Responsibilities That Come with Dedicated Management
CloudHSM's greatest feature is that it lets you place cryptographic keys entirely under your own organization's control, but that also means your organization bears responsibility for key availability and backups. With a managed key management service, the service takes on key redundancy and backups, but with dedicated HSMs, you need to design these yourselves. If you lose a key, you can no longer decrypt the data encrypted with it, so it is essential to place clusters redundantly across multiple AZs and to operate secure backups of keys. The scope of responsibility is not limited to key availability. Users and roles on the HSM are managed outside IAM, so you also need to establish your own procedures for issuing and revoking credentials and for reviewing permissions. Backups cannot be restored across FIPS mode and non-FIPS mode, and generations are limited to one direction, from hsm1.medium to hsm2m.medium, so disaster recovery procedures must be written on the assumption of the generation and mode you currently use. Furthermore, work to keep up with HSM generations and Client SDK versions, such as the migration from hsm1.medium to hsm2m.medium, also arises periodically. In exchange for gaining complete control, you take on the responsibility of maintaining it. When choosing dedicated management, it is important to assess whether you have a team in place to take on this operational burden.
Summary - Guidelines for Using CloudHSM
AWS CloudHSM is the service to choose when you want to manage cryptographic keys with exclusive use of single-tenant hardware. Both KMS and CloudHSM have moved to generations that use HSMs validated at FIPS 140-3 Level 3, so a decision based on whether the validation level is higher or lower no longer holds. The decision criteria are five: exclusive use of hardware, direct control through PKCS#11, JCE, and others, where key custody lies, whether compliance requirements go as far as specifying single tenancy, and whether you can take on the operational responsibility. If you want to keep key material in your own cluster while retaining integration with AWS services, you can also consider the middle-ground solution of the KMS AWS CloudHSM key store. hsm2m.medium is the current generation of HSM type, and hsm1.medium reached end of support on March 31, 2026, so if you operate existing clusters, checking the migration status comes first. Pricing for a two-HSM configuration is at a considerable level, from about $2,336 per month (N. Virginia) to about $2,643 (Tokyo), so we recommend deciding on adoption after checking the requirements against the five criteria above (as of August 2026).
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.
If this page and the official documentation disagree, treat the official documentation as authoritative.