Summary:
- AWS CloudHSM vs KMS represents a fundamental choice between dedicated hardware control and managed service convenience, each serving distinct compliance and operational requirements.
- Recent updates through 2024-2026 have narrowed the gap significantly, with KMS now achieving FIPS 140-3 Security Level 3 validation and supporting asymmetric key imports.
- Custom key stores bridge both worlds by letting you use KMS APIs while storing keys in your CloudHSM cluster, though with specific feature limitations.
- Cost analysis reveals CloudHSM clusters can exceed $1,000/month per HSM, while KMS charges per-key and per-request, making workload volume the deciding factor.
When your organization faces a compliance audit or handles cryptographic operations at scale, the choice between AWS CloudHSM and AWS Key Management Service becomes more than a technical preference. It becomes a strategic decision that affects your security posture, operational overhead, and monthly AWS bill for years to come. Understanding the AWS CloudHSM vs KMS differences requires examining not just feature lists, but the architectural philosophies behind each service and how recent AWS updates have reshaped the decision matrix for 2025 and beyond.
The following diagram illustrates the high-level architectural differences between AWS KMS and CloudHSM. It shows how each service handles key storage, access patterns, and integration with other AWS services.
Understanding the core architectural differences
AWS KMS and CloudHSM solve the same fundamental problem of protecting cryptographic keys, but they approach it from opposite ends of the control spectrum. KMS operates as a fully managed, multi-tenant service where AWS handles all HSM infrastructure, patching, and availability concerns. You interact exclusively through AWS APIs and IAM key policies, never touching the underlying hardware.
CloudHSM, by contrast, provisions dedicated hardware security modules within your VPC. This gives you exclusive access to single-tenant devices that you manage directly using industry-standard PKCS#11, JCE, and CNG interfaces.
This architectural split creates cascading differences in how you approach key lifecycle management. With KMS, AWS generates keys inside its HSMs and those keys never leave the HSM boundary in plaintext. You gain automatic integration with over 100 AWS services, from S3 server-side encryption to EBS volume encryption, without writing custom code.
CloudHSM requires you to generate, store, and manage keys yourself. However, it grants capabilities KMS cannot match. These include exporting key material, running custom cryptographic algorithms, and maintaining keys that AWS operators cannot access under any circumstances.
Tenancy and isolation models
The tenancy model represents perhaps the most significant AWS KMS CloudHSM difference for compliance-sensitive workloads. KMS uses a fleet of HSMs shared across AWS customers, with cryptographic isolation ensuring your keys remain inaccessible to other tenants. AWS has validated this architecture to FIPS 140-3 Security Level 3 standards as of recent updates. However, the multi-tenant nature still concerns some regulatory frameworks and internal security policies.
CloudHSM eliminates this concern entirely by provisioning HSMs exclusively for your account. Each HSM in your cluster runs in an AWS data center but operates as dedicated hardware that no other customer can access. You receive the HSM’s credentials during initialization, and AWS cannot recover keys if you lose those credentials. This single-tenant model satisfies the strictest interpretations of regulations requiring dedicated cryptographic hardware, including certain government and defense contracts.
Recent updates reshaping the decision landscape (2023-2026)
AWS has significantly evolved both services over the past three years, narrowing gaps that previously made the choice more straightforward. Understanding these updates is essential for making informed architectural decisions in 2025 and beyond.
KMS achieves FIPS 140-3 Security Level 3 validation
Perhaps the most consequential recent change is KMS achieving FIPS 140-3 Security Level 3 validation for its underlying HSMs. Previously, KMS operated at Level 2, which satisfied many compliance requirements but fell short for organizations mandating Level 3 physical tamper resistance. This update means KMS now meets the same FIPS validation level as CloudHSM for the cryptographic modules themselves. The multi-tenant versus single-tenant distinction remains.
Asymmetric key import capabilities
KMS now supports importing asymmetric key material, a capability previously limited to symmetric keys. This enables scenarios where you generate RSA or ECC key pairs in external HSMs or on-premises systems and then import them into KMS for use with AWS services. The import process uses a wrapping key to protect your key material during transit. You can set expiration dates requiring periodic re-import for additional security controls.
The following CLI example demonstrates importing an asymmetric RSA key into KMS:
Algorithm deprecations and additions
AWS has removed support for legacy algorithms like 3DES from CloudHSM firmware updates, reflecting industry movement away from deprecated cryptographic standards. Simultaneously, both services have expanded support for modern algorithms. KMS now supports HMAC keys for message authentication, and CloudHSM clusters running current firmware support additional elliptic curves for specialized signing workloads.
Custom key stores and bridging KMS and CloudHSM
AWS offers a hybrid approach through KMS Custom Key Stores, which now come in two flavors: AWS CloudHSM key stores and External Key Stores (XKS).
CloudHSM key stores let you use familiar KMS APIs while storing key material in your dedicated CloudHSM cluster. External Key Stores (XKS) take this a step further by allowing you to connect KMS to an external HSM located outside of AWS (such as on-premises or in a multi-cloud environment). This architecture provides the operational simplicity of KMS integration with AWS services while ensuring your root of trust satisfies the strictest data sovereignty and compliance requirements.
The diagram below shows how custom key stores connect KMS to your CloudHSM cluster. It illustrates the request flow when an AWS service encrypts data using a key stored in your dedicated HSMs.
Unsupported features in custom key stores
Custom key stores come with significant limitations that affect architectural decisions. Understanding these constraints prevents surprises during implementation:
- Symmetric keys only: Custom key stores support only symmetric encryption keys. You cannot create asymmetric keys or HMAC keys in a custom key store.
- No automatic key rotation: Unlike standard KMS keys, keys in custom key stores do not support automatic annual rotation. Because the key material lives in your dedicated HSM, AWS KMS lacks the administrative authority to autonomously generate new keys inside your cluster. You must implement manual rotation procedures via your Crypto User (CU) credentials.
- No multi-region keys: Custom key store keys cannot be configured as multi-region keys, limiting disaster recovery architectures that rely on this feature.
- No imported key material: You cannot import external key material into a custom key store key. KMS generates all key material within the CloudHSM cluster.
Region availability considerations
CloudHSM and custom key stores are not available in all AWS regions. As of 2025, several newer and smaller regions lack CloudHSM support, which directly affects custom key store availability. Organizations with global deployments should verify region support during architecture planning, particularly for regions in South America, Africa, and some Asia-Pacific locations. The AWS Regional Services List provides current availability information.
Feature comparison across deployment models
The following table provides a comprehensive comparison across three deployment models. These are standard KMS, KMS with custom key store, and direct CloudHSM usage. This comparison reflects capabilities as of 2026.
| Feature | KMS (standard) | KMS custom key store | CloudHSM direct | KMS External Key Store (XKS) |
|---|---|---|---|---|
| Tenancy model | Multi-tenant | Single-tenant | Single-tenant | Single-tenant |
| FIPS 140-3 level | Level 3 | Level 3 | Level 3 | Depends on external HSM |
| Symmetric keys | Yes | Yes | Yes | Yes |
| Asymmetric keys | Yes | No | Yes | No |
| HMAC keys | Yes | No | Yes | No |
| Key material export | No | No | Yes | Depends on external HSM |
| Key material import | Yes | No | Yes | No |
| Automatic rotation | Yes (annual) | No | Manual only | No |
| Multi-region keys | Yes | No | Manual sync | No |
| AWS service integration | Native (100+ services) | Native (100+ services) | Custom code required | Native (100+ services) |
| Pricing model | Per-key + per-request | Per-key + per-request + HSM hourly | HSM hourly only | Per-key + per-request + External HSM costs |
| Minimum monthly cost | ~$1 per key | ~$2,117 (2 HSM minimum) | ~$2,117 (2 HSM minimum) | Variable (Vendor dependent) |
Cost analysis and workload considerations
Cost structures differ dramatically between KMS and CloudHSM, making workload volume a critical factor in service selection. KMS charges approximately $1 per month per customer-managed key plus $0.03 per 10,000 requests. For most workloads, this results in predictable, low costs that scale linearly with usage.
CloudHSM pricing follows a fundamentally different model. Each HSM instance costs $1.45 per hour (in standard regions like US-East-1), and AWS recommends a minimum of two HSMs across availability zones for production workloads. This translates to roughly $2,117 per month before any cryptographic operations occur. CloudHSM does not charge per-request, making it potentially more economical for extremely high-volume cryptographic workloads.
Break-even analysis
The cost break-even point between KMS and CloudHSM depends heavily on your request volume and the type of cryptographic operation. Standard symmetric KMS operations cost $0.03 per 10,000 requests, meaning you need approximately 705 million operations per month before CloudHSM ($2,117/month) becomes more economical purely on request costs.
However, asymmetric operations in KMS are much more expensive. Asymmetric signing costs $0.15 per 10,000 requests, and generating RSA data key pairs costs $12.00 per 10,000 requests.
Consider the following cost comparison for different workload profiles against a baseline $2,117 CloudHSM cluster:
- Low volume symmetric (1 million requests/month): KMS costs $3. CloudHSM costs $2,117. (KMS wins)
- High volume symmetric (1 billion requests/month): KMS costs $3,000. CloudHSM costs $2,117. (CloudHSM wins)
- Medium volume asymmetric signing (150 million requests/month): KMS costs $2,250. CloudHSM costs $2,117. (CloudHSM break-even point drops drastically for asymmetric workloads)
- High volume RSA key generation (2 million requests/month): KMS costs $2,400. CloudHSM costs $2,117. (CloudHSM becomes economical very quickly for heavy key-generation workloads).
Use case decision framework
Selecting between AWS CloudHSM and KMS requires evaluating multiple dimensions beyond cost. The following framework helps structure the decision process based on common organizational requirements.
When to choose standard KMS
Standard KMS fits most AWS workloads where compliance does not mandate dedicated hardware. Choose KMS when your requirements include native integration with AWS services like S3, EBS, RDS, and Lambda. KMS excels when you need automatic key rotation, multi-region key replication for disaster recovery, or when your team lacks HSM administration expertise. The managed nature of KMS eliminates operational burden while providing FIPS 140-3 Security Level 3 validated cryptography.
When to choose CloudHSM
CloudHSM becomes necessary when specific technical or compliance requirements exceed KMS capabilities. Choose CloudHSM when you must export key material for backup or migration to other systems. Select CloudHSM for high-volume signing workloads where per-request KMS costs become prohibitive, or when you need cryptographic algorithms KMS does not support. Organizations subject to regulations explicitly requiring dedicated, single-tenant HSMs should evaluate CloudHSM or custom key stores.
When to choose custom key stores
Custom key stores provide a middle path when you need single-tenant key storage but want to maintain KMS API compatibility and AWS service integration. This approach suits organizations that must satisfy compliance requirements for dedicated HSMs while lacking resources to build custom CloudHSM integrations with every AWS service. Accept the limitations around asymmetric keys and automatic rotation if your use case involves only symmetric encryption.
Governance and audit integration
Both KMS and CloudHSM integrate with AWS CloudTrail for audit logging, though the depth and nature of logged events differ. KMS automatically logs every API call, including encryption, decryption, and key management operations. These logs capture the calling principal, timestamp, and request parameters, providing comprehensive audit trails for compliance reporting.
CloudHSM audit logging operates differently. The HSMs generate their own audit logs that you must configure and export. These logs capture cryptographic operations performed directly on the HSM but require additional infrastructure to collect, store, and analyze. Organizations using CloudHSM should implement log aggregation pipelines to maintain audit capabilities comparable to KMS.
Practical implementation for setting up a CloudHSM cluster
For teams choosing CloudHSM, the initial cluster setup involves several steps that differ significantly from KMS key creation. The following sequence outlines the process for establishing a production-ready cluster across availability zones.
First, create the CloudHSM cluster in your VPC:
After initialization, you must create HSM users and configure your applications to authenticate. Unlike KMS where IAM policies control access, CloudHSM uses its own user management system with crypto users (CU) for key operations and crypto officers (CO) for administrative tasks. This separation of duties aligns with security best practices but requires additional management overhead.
Conclusion
The AWS CloudHSM vs KMS decision ultimately balances compliance requirements, operational capabilities, and cost constraints. KMS serves as the default choice for most AWS workloads, offering managed simplicity, native service integration, and now FIPS 140-3 Security Level 3 validation. CloudHSM addresses specialized requirements, including key export, single-tenant hardware mandates, and high-volume cryptographic workloads where per-request pricing becomes prohibitive. Custom key stores bridge these worlds for organizations needing dedicated hardware with KMS convenience, accepting the trade-offs around asymmetric keys and automatic rotation.
As AWS continues evolving both services, the gap between them narrows while their distinct architectural philosophies remain. Organizations should revisit this decision periodically, particularly when compliance requirements change or workload volumes shift significantly. The right choice today may warrant reconsideration as your security posture matures and AWS introduces new capabilities.
Start by documenting your specific compliance requirements, estimating cryptographic operation volumes, and assessing your team’s HSM administration expertise. These three factors will guide you toward the architecture that balances security, operability, and cost for your unique situation.
