AWS Lays Out the KMS vs. CloudHSM Decision
AWS published a direct comparison guide for AWS Key Management Service and AWS CloudHSM on July 28, 2026. The post gives cloud platform owners, security leaders, and application teams a structured framework for choosing between the two services.
Both services use FIPS 140-3 Level 3 validated hardware security modules. Both meet FIPS 140-3, PCI-DSS, HIPAA, and FedRAMP compliance requirements. Neither service allows AWS employees to access your key material. The shared foundation is real. The operational differences, however, are substantial.
What Actually Separates the Two Services
AWS KMS is fully managed, integrates with all AWS services, and operates across all AWS Regions. AWS CloudHSM is a customer-managed service accessed through an Elastic Network Interface in your VPC and available in 32 Regions as of July 2026.
The management burden difference is significant. AWS KMS handles HSM provisioning, automatic key rotation, auto-scaling, disaster recovery, and audit logging without any customer action. AWS CloudHSM is a zonal service where customers manage their own high availability and durability. That means provisioning additional HSM instances, managing cluster backups, and handling peak capacity planning without utilization metrics to guide you.
Performance headroom differs too. AWS KMS supports a default request rate from 10,000 to 100,000 transactions per second per account based on Region, with quota increases available on request. AWS CloudHSM requires explicit provisioning of additional instances for higher throughput, and customers typically provision at least one additional HSM instance to handle peak activity.
There is also a hybrid path. AWS KMS supports AWS CloudHSM key stores, which let you store KMS key material inside an AWS CloudHSM cluster you own and manage. This combines the AWS KMS console and API with the additional controls of an AWS CloudHSM cluster.
As Metrotechs analysis, connecting a custom key store involves real setup work. The cluster must contain at least two active HSMs in different Availability Zones. Unsupported features in custom key stores include asymmetric KMS keys, HMAC KMS keys, imported key material, automatic key rotation, and multi-Region keys.
The Cost Gap Is Wide for Most Workloads
AWS KMS costs $1 per key per month plus $0.03 per 10,000 requests for symmetric and RSA 2048 operations. AWS KMS also provides a free tier of 20,000 requests per month across all Regions.
AWS CloudHSM costs approximately $1.60 per HSM instance per hour, which is roughly $1,152 per month per HSM before staff overhead.
The AWS guide provides a direct example. A workload with 100 keys and 100 million monthly operations using two CloudHSM instances for high availability runs approximately $2,304 per month for the HSMs plus operational costs. The same workload on AWS KMS costs approximately $400 per month, an 83% reduction.
The AWS analysis sets out three cost tiers. Below 500 million operations per month, AWS KMS typically costs 35–99% less. Between 500 million and 1 billion operations, costs are comparable. Above 1 billion operations per month, AWS CloudHSM might be more cost-effective.
One important modifier: many AWS services cache Data Encryption Keys locally, which reduces the actual number of AWS KMS API calls. Real costs at scale are often lower than raw operation counts suggest.
When CloudHSM Is Actually Required
AWS is direct about the scope. The guide states to choose AWS CloudHSM only when you require one of three things.
First, direct integration with third-party tools that rely on traditional HSM interfaces. The listed examples include Microsoft SignTool, Nginx, and HAProxy, using PKCS#11, Java Cryptographic Extension, OpenSSL Provider, or Key Storage Provider interfaces. These are required when your application communicates with an HSM directly rather than through a cloud API.
Second, deprecated algorithms such as 3DES and PKCS#1 v1.5 with RSA. AWS KMS does not support these.
Third, less commonly used operations not supported by AWS KMS, such as AES key wrapping and AES with CTR or CBC modes.
Outside those three cases, the AWS guide is unambiguous: AWS KMS is the right choice for most cloud key management workloads.
On the compliance question, the guide makes one specific argument that security teams often dispute. It states that the multi-tenant architecture of AWS KMS provides the same security guarantees as the single-tenant model of AWS CloudHSM. The guide's basis for that claim is that compliance frameworks validate security based on cryptographic boundaries rather than hardware dedication.
It also states that customer security teams consistently approve AWS KMS after confirming that cryptographic isolation meets their single-tenant requirements.
This is AWS's position. Security and compliance teams that have contractual, regulatory, or internal policy requirements for single-tenant hardware should evaluate that claim against their own obligations before acting on it.
Both services are investing in post-quantum cryptography and support ML-DSA. AWS states both are committed to expanding post-quantum algorithm support as NIST standards are finalized.
What Cloud Platform Owners Should Do Now
This guide gives security and platform teams a clear audit starting point. Run through three questions for any system currently using or planning to use CloudHSM.
First, does any application in scope use a legacy HSM interface, meaning PKCS#11, JCE, OpenSSL Provider, or KSP? If yes, CloudHSM stays. If no, document that explicitly.
Second, does any workload depend on 3DES, PKCS#1 v1.5 RSA, AES key wrapping, or AES CTR/CBC modes? If yes, CloudHSM stays. If no, that dependency is gone.
Third, what is the monthly operation count? Pull actual API call volumes from AWS CloudTrail logs. Factor in DEK caching before projecting AWS KMS cost. The $400-versus-$2,304 example in the guide uses a workload that many teams will recognize immediately.
Teams running CloudHSM key stores through the custom key store feature should verify two things separately. First, confirm the cluster meets the minimum of two active HSMs in different Availability Zones. Second, confirm that unsupported features are not part of the current design. Those features include asymmetric KMS keys, HMAC KMS keys, imported key material, automatic key rotation, and multi-Region keys.
The AWS documentation does not state whether AWS plans changes to the custom key store feature set.
For teams with no existing CloudHSM dependency, the decision is straightforward by AWS's own framework. AWS KMS covers the workload, integrates natively, and costs substantially less at typical cloud-application operation volumes.