What are the Differences Between AWS CloudHSM and AWS KMS
Encryption is an essential part of security in the cloud to protect sensitive data and meet compliance requirements. AWS provides two major services for managing encryption keys: AWS CloudHSM and AWS Key Management Service (KMS). But what are the differences between AWS CloudHSM vs AWS KMS, and when should you use each one?
Both CloudHSM and KMS generate and manage cryptographic keys, which are used to encrypt and decrypt data. However, they are built for different use cases based on the level of control and ease of use required.
CloudHSM provides dedicated Hardware Security Module (HSM) appliances within the AWS cloud, where you have full control over your keys. KMS is a multi-tenant managed service where AWS generates keys for you and handles key management operations through a simple API.
Key Takeaways
- AWS CloudHSM and AWS KMS are both services for managing encryption keys, but they have different use cases. CloudHSM is intended for keys that require total control, while KMS focuses on ease of use.
- CloudHSM allows you to generate and store keys in your HSMs for full control. KMS generates keys for you and stores them securely, requiring less operational effort.
- CloudHSM meets regulatory compliance needs that require full control over keys like FIPS 140-2 Level 3. KMS is more flexible and integrates with more AWS services.
- CloudHSM is single-tenant, while KMS uses multi-tenant HSMs with logical separation of keys. CloudHSM provides dedicated computing resources, while KMS is serverless.
- CloudHSM has higher costs but gives you full control. KMS has lower costs but less flexibility. The choice depends on your security needs and operational overhead.
- For most general encryption uses like EBS and S3 encryption, KMS is likely the best choice. For specialized needs like PKI or regulatory compliance, CloudHSM makes sense.
Head-to-Head Comparison Between AWS CloudHSM vs AWS KMS
| Feature | CloudHSM | KMS |
| Key Ownership | You fully own and manage keys | AWS owns and manages keys |
| Hardware Type | Dedicated FIPS 140-2 Level 3 HSMs | Shared multi-tenant FIPS 140-2 Level 2 |
| High Availability | HA across HSM instances you manage | Managed HA by AWS internally |
| Key Isolation | Single-tenant HSMs with full isolation | Logical isolation on shared infrastructure |
| Key Backup | Your responsibility through HSM backup | Automated by AWS internally |
| AWS Integration | Requires custom integration work | Integrated encryption services |
| Key Access Control | Network ACLs, security groups, SSL | IAM policies and grants |
| HSM Resources | Dedicated HSM compute per instance | Shared serverless compute pool |
| Encryption Offload | Within HSM appliances | Handled by AWS managed servers |
| Auditing | Through HSM logs you manage | CloudTrail and internal AWS audits |
| Import/Export | Can export with proper config | AWS manages key isolation |
| Pricing | Hourly HSM instances, data egress | Requests, encrypted data usage |
How AWS CloudHSM and KMS Work
Before diving into the comparisons, let’s briefly explain how CloudHSM and KMS work at a high level:
Overview of CloudHSM
AWS CloudHSM provides dedicated HSM appliances within AWS data centers that you manage yourself. HSMs are hardware devices designed to store cryptographic keys securely and perform encrypt/decrypt operations quickly.
With CloudHSM:
- You purchase HSM instances that AWS already provisions. Currently, Cavium and Thales are supported by HSM vendors.
- CloudHSM instances are connected to your VPC, like EC2 instances. You can make them highly available by placing them in multiple availability zones.
- You generate and import encryption keys, which are stored securely inside your HSMs. The private keys never leave the HSM boundary.
- You can integrate your applications with the HSM using the CloudHSM client software SDK to perform cryptographic operations like encryption/decryption.
- You have full control over the encryption keys and all access to the HSM. AWS has no access to your keys.
- CloudHSM handles the physical security, hardware maintenance, and software patching of the HSM, so you don’t have to.
Overview of KMS
AWS Key Management Service (KMS) is a managed encryption key service that handles secret key generation, storage, and management.
With KMS:
- Encryption keys are generated within KMS and stored in secure, highly available HSMs. AWS manages the HSM fleet.
- You access the keys through the KMS API and CLI to encrypt or decrypt data, relying on KMS to handle key usage securely.
- Access to keys can be controlled through IAM policies and grants that allow authorized users and AWS services to use keys only.
- AWS services like EBS, S3, and Redshift are integrated with KMS to encrypt stored data transparently.
- You pay only for API calls to KMS and the encrypted data storage. AWS manages the underlying HSM infrastructure.
- Access policies, auditing, and secure HSM storage protect keys. However, unlike CloudHSM, AWS can access the keys to manage the service.
Key Management Models Comparison between AWS CloudHSM vs AWS KMS
The biggest difference between CloudHSM and KMS comes down to who manages the keys:
- CloudHSM: You fully manage the keys. You generate, store, and control access to the keys.
- KMS: AWS generates and manages the keys for you. You control key access via IAM but can’t fully manage keys.
This leads to very different models for key control, security, integration, and use cases between the two services.
Key Generation
With CloudHSM, you have full control over generating keys:
- You generate or import your encryption keys within your HSM instances using the CloudHSM software.
- You choose the type of algorithm and key strength to meet your security needs. For example, you can generate 2048-bit RSA asymmetric key pairs.
- You decide when to generate new keys and can create multiple encryption keys within the HSM.
- Your keys are always stored and encrypted within the physical HSM boundary, and you never leave them unencrypted.
With KMS, AWS generates and manages the encryption keys:
- KMS handles generating the encryption keys securely inside its HSM infrastructure.
- You don’t choose algorithms or key strengths, as KMS determines the appropriate standard to use. Keys are either RSA 2048-bit or ECC 256-bit.
- Key generation happens transparently when you enable a KMS customer master key (CMK). It would help if you found out the actual key value.
- AWS generates and rotates the underlying keys periodically. You don’t control key creation but can turn CMKs on/off.
Key Storage
For CloudHSM, you know exactly where your keys are stored:
- The keys only exist inside your provisioned HSM instances that you manage and are connected to your VPC.
- A CloudHSM cluster has dedicated, single-tenant HSMs that store only your keys. No other customer shares the same HSM instances.
- If you disable or delete a CloudHSM instance, the keys are wiped after a short period if not backed up externally. Keys always remain encrypted.
With KMS, AWS abstracts away the underlying HSM storage:
- Your KMS keys are stored within HSMs managed by AWS as part of the KMS service. AWS doesn’t expose details of the HSMs.
- The HSMs are multi-tenant, storing keys for multiple customers with logical separation. AWS admins can access the HSM.
- Disabling or deleting a CMK key makes it unusable, but AWS may retain encrypted key material for recovery and auditing purposes.
Key Management
You have complete control when managing keys with CloudHSM:
- Only you, as the CloudHSM customer, have access to your HSM instances and can manage the keys stored in them.
- You perform all key management operations like rotating keys, enabling/disabling keys, and creating key policies through the CloudHSM software.
- AWS does not have access to your HSM instances or encryption keys. It would help if you backed up keys externally.
- You can integrate with the CloudHSM SDK/API to build custom applications that leverage your HSM keys.
For KMS, AWS handles the ongoing key management:
- AWS manages the keys internally on your behalf after they are created, including encrypting them for storage, rotating them periodically, etc.
- You have no direct access to the underlying HSMs. AWS administrators can access the HSMs to manage the service but not customer keys.
- You manage key access via IAM policies, grants, and retiring/deleting CMKs. But you can’t only export keys or partially manage them.
- AWS integrates KMS directly into many services to leverage your CMKs for transparent data encryption.
Key Access
CloudHSM gives you full control over who can access keys:
- You control how CloudHSM users and applications are authenticated to use HSM keys, like using SSL/TLS certificates.
- Within AWS, you manage network access through VPC endpoints, security groups, and NACLs to restrict HSM access.
- Outside AWS, cryptographic operations never expose the plaintext key value. But you control access to make calls.
- Keys inside the HSM can’t be exported in plaintext. Even AWS can’t extract your keys from a CloudHSM.
With KMS, you manage access through IAM policies and grants:
- Authentication is handled automatically through IAM roles/security tokens when accessing KMS to use keys.
- You authorize the use of CMKs by creating IAM key policies that specify who can access the keys and what operations they can perform.
- Users and services can be granted more granular access to encrypt/decrypt data through KMS grants without giving full key access.
- When you enable encryption using AWS services (e.g., EBS encryption), you automatically grant access to your CMKs.
- While AWS admins can access the HSMs, all KMS keys are encrypted and logically isolated from other customers.
- AWS manages the underlying key access, so you don’t have to authenticate HSMs directly.
Key Backups
CloudHSM gives you full responsibility over key backups:
- Keys within CloudHSM are only stored in the HSM instances you provision and manage.
- To protect against key loss, such as when replacing an HSM, you must back them up externally using CloudHSM backup features.
- Backups can be stored encrypted in S3 for disaster recovery. You manage the backup lifecycle.
- Without backups, deleting or disabling HSM instances will result in permanent key loss. AWS can’t help recovering keys stored only in the HSM.
For KMS, AWS automatically backs up your keys:
- AWS handles backups of your KMS keys within the service for disaster recovery, so you don’t have to manage them.
- You can’t export full backups of your KMS keys. However, KMS keys have features like CMK material replication across regions.
- If a KMS CMK is disabled or deleted, AWS retains the encrypted key material, allowing recovery if it is enabled later.
- AWS manages encryption, storage, and replication of your key material within KMS. Key backups are not exposed to customers.
Hardware & Architecture Comparison Between AWS KMS and AWS CloudHSM
The underlying hardware architecture and HSMs are very different between CloudHSM and KMS:
HSM Types
CloudHSM uses dedicated, single-tenant HSM appliances:
- You get full HSM instances provisioned on FIPS 140-2 Level 3 validated hardware from Cavium and Thales.
- A CloudHSM “cluster” contains multiple appliances across AZs that act as a single logical HSM for high availability.
- Each CloudHSM cluster is single-tenant, and you only use it. Other customers access different dedicated HSM instances.
KMS uses multi-tenant HSMs managed by AWS:
- The KMS service uses an internal fleet of HSMs to protect keys for all customers. Customers don’t need to learn the models.
- Multiple customers share these HSMs with logical separation between encryption keys. You don’t need to get dedicated HSMs.
- AWS operates the HSM infrastructure and validates that it meets security standards compliant with FIPS 140-2 level 2.
High Availability
CloudHSM can be made highly available across AZs:
- A CloudHSM cluster contains HSM instances spread across multiple AZs that act as a unified logical device.
- If an HSM goes down, keys remain accessible from the other HSM instances to maintain redundancy.
- You pay for each additional HSM appliance added for high availability. A minimum of two HSMs are recommended.
KMS provides HA through AWS-managed infrastructure:
- KMS handles deploying key material across multiple HSMs and AZs for high availability. The customer is not exposed to details.
- High availability of keys is built-in by AWS, so you don’t have to architect HA across HSM instances like CloudHSM.
- Making keys highly available is free of charge. AWS manages it internally as part of the service.
HSM Resources
With CloudHSM, dedicated HSM compute is allocated per instance:
- Each CloudHSM device you deploy comes with dedicated compute resources, such as 25 GB RAM, dedicated Intel Xeon processors, and flash storage.
- You pay for the required dedicated HSM resources. More keys require more HSMs and computing.
- If you exceed HSM storage or compute, you’ll need to add larger instances. CloudHSM supports scaling up from small to large cases.
KMS operates as a multi-tenant serverless service:
- AWS manages a shared pool of HSM resources that are dynamically allocated when you use KMS.
- You don’t have to provision HSM computing like CloudHSM. KMS operates as a serverless, on-demand service.
- AWS handles scaling the service and adding HSM capacity as needed. You only pay for what you use.
Encryption Offload
CloudHSM keeps encryption operations within the HSM:
- With CloudHSM, cryptographic operations are performed inside the HSM appliances without exposing keys.
- This removes the computing burden from application servers for better performance when encrypting/decrypting large volumes of data.
- You pay for dedicated HSM resources to handle encryption, but it is offloaded from your main computer.
For KMS, AWS handles encryption offload transparently:
- When using KMS for encryption, the actual encryption using keys happens within AWS servers connected to the HSM fleet.
- This allows compute-intensive encryption to scale transparently without you needing to deploy HSM appliances.
- AWS pricing for KMS includes the infrastructure costs, so you only pay for API calls and data storage.
Key Control & Security Comparison Between AWS CloudHSM and AWS KMS
Control over keys and securing them is implemented very differently between the services:
Key Ownership
CloudHSM gives you full key ownership:
- You generate and own the key material entirely. AWS has no access to your plaintext keys stored in the HSM.
- You can add any style of keys supported by the HSMs, like symmetric keys, private keys, etc., with full control.
- CloudHSM keys are your property. If you delete an HSM, AWS destroys the keys after a short period.
With KMS, AWS owns the underlying keys:
- AWS generates the actual key material. You reference keys using the KMS customer master key ID.
- AWS manages the style of keys generated and algorithms used. You can’t fully own keys.
- AWS retains encoded key material even if you delete/disable a CMK if you want to re-enable it later.
Key Isolation
CloudHSM provides dedicated key storage isolated from other customers:
- Each CloudHSM cluster instance is single tenant, with your keys stored securely and isolated from other customers.
- Keys are only stored in the encrypted HSM appliances you manage. Other AWS systems have no access.
- AWS has no access to your plaintext keys in CloudHSM due to the dedicated HSM boundary.
KMS relies on logical isolation on shared infrastructure:
- Customer keys are stored in shared AWS-managed HSM pools with keys from other customers.
- Encryption and logical separation provide security between customers sharing KMS HSMs.
- AWS administrators can access the HSMs to manage the service, but keys are encrypted.
Key Access
You fully manage key access with CloudHSM:
- You control how users authenticate to access the HSM, such as local access credentials, LDAP, or SSL certificates.
- Inside AWS, you manage network security using VPC, subnet routing, and security groups. Outside AWS, you control access to make API calls and encrypt transmissions.
- AWS does not have access to your keys or the ability to extract them from the HSM. But you can lock yourself out if you misconfigure access.
KMS provides managed access control through IAM:
- You don’t directly authenticate to HSMs; instead, you use IAM permissions to authorize your API calls to KMS.
- Access policies on each customer master key manage which users, roles, and services can use a key.
- AWS administrators can access the HSMs to manage the service, but keys are encrypted using separate AWS keys.
- AWS owns the HSM infrastructure, so they can recover access but won’t disclose or improperly use your keys.
Auditing
CloudHSM auditing is managed through the HSM appliances:
- You can review audit logs directly through the CloudHSM software to see key usage, logins, configurations, etc., specific to your HSM cluster.
- Logs are stored locally but can be centralized by integrating with AWS CloudTrail, S3, etc.
- You control auditing and log storage based on your internal compliance needs. However, AWS is not independently audited.
KMS has robust integrated logging and auditing:
- CloudTrail logs provide records of all key usage. CloudWatch integration monitors metrics.
- AWS undergoes regular independent audits of its security, including KMS. Audit reports are made publicly available.
- You can still use CloudTrail to centralize logs, but there is less operational overhead.
AWS Integration Comparison Between AWS CloudHSM vs AWS KMS
CloudHSM and KMS integrate with AWS and on-premises environments very differently:
AWS Service Integration
CloudHSM requires custom integration work to use with AWS:
- CloudHSM can encrypt data in other AWS services like S3 or EBS, but you have.
- CloudHSM can encrypt data in other AWS services like S3 or EBS, but you have to build the integration yourself. There is no turnkey encryption.
- You can use CloudHSM keys from EC2 instances or Lambda functions by leveraging the SDK, but not transparently.
- Requires engineering effort to encrypt AWS data using CloudHSM. Services don’t natively integrate with CloudHSM.
KMS provides turnkey encryption integration with AWS:
- Many AWS services, such as S3, EBS, and Redshift, are integrated with KMS for encryption/decryption using your keys.
- Enabling encryption with KMS on a resource will automatically encrypt data using your CMKs without custom coding.
- Native KMS integration makes encryption easy and transparent in many AWS services.
On-premises Integration
Using CloudHSM keys from on-prem requires hosting an HSM locally:
- To use CloudHSM keys from on-premises, you need your own HSM installed on-premises synced with AWS CloudHSM via Sync Groups.
- This allows hybrid environments but requires you to deploy HSMs in both AWS and on-premises data centers.
- On-prem integration is possible but requires the operational overhead of maintaining your own HSM fleet.
KMS can be accessed from on-premises through the API:
- From on-prem, you can access the same KMS keys using the API and CLI over the internet, like from AWS.
- No need to deploy HSMs in your data centers. KMS provides encryption as a service.
- Easy to use one set of keys between AWS and on-prem. But you must open access through firewalls.
Network Access
CloudHSM instances are directly accessed within your VPC:
- CloudHSM instances are provisioned inside your VPC with direct network access from EC2 and Lambda inside the VPC.
- Access is controlled via security groups, NACL rules, and VPC endpoints like traditional instances.
- External to AWS requires opening TCP ports or setting up Direct Connect and IPSec VPN. More complex access control.
KMS is accessed through external API calls:
- KMS is used through the AWS API and CLI. Your network needs HTTPS access to AWS endpoints.
- IAM policies authorize access instead of network ACLs. Easier access management but less isolation.
- KMS can be accessed from AWS, on-prem, and external networks with proper IAM roles. Access is defined logically.
Key Importing and Exporting
CloudHSM allows importing/exporting keys if properly configured:
- Keys can be imported or exported from CloudHSM if you enable the import/export feature.
- It requires configuring an import token to encrypt keys for import/export temporarily.
- It can allow strong two-person controls on export with an authorization key requiring two admin credentials.
KMS manages and isolates keys within the service:
- KMS keys can’t be exported from the service. You can only use them through the API/CLI.
- Importing keys is limited. For key rotation, KMS can generate new keys encrypted by existing keys.
- AWS manages keys and encryption internally. You don’t have to handle direct import/export responsibly.
Use Case Comparison Between CloudHSM vs KMS
CloudHSM and KMS are suited for different use cases:
CloudHSM Use Cases
CloudHSM is designed for specialized scenarios requiring dedicated HSM control, including:
- Public Key Infrastructure (PKI): CloudHSM can act as a root of trust for certificate authority (CA) keys and issuing certificates. Having dedicated HSMs provides uncompromised security.
- Regulatory Compliance: Adhering to standards like FIPS 140-2 level 3, which validate full-lifecycle key management processes, is easier and more robust with CloudHSM ownership.
- Key Management Offload: Offloading key management from application servers under your control can meet the performance and security needs of transaction processing or cryptocurrency wallets.
- Existing HSM Replacement: For those with on-premises HSMs today, CloudHSM provides similar models with AWS benefits like scalability and reduced hardware management.
KMS Use Cases
KMS is designed for general encryption key management use cases, including:
- Default AWS Encryption: KMS provides turnkey encryption for many AWS services. It’s the easiest way to encrypt stored data across AWS.
- Application Encryption: KMS keys can encrypt application data, credentials, and secrets. APIs make integration straightforward.
- Securing PII Data: For sensitive customer data like healthcare info, KMS can make encrypting data easy, even with frequent key rotation.
- Sharing Encryption Across Accounts: KMS enables inter-account key access through IAM, unlike isolated CloudHSM instances.
For most general encryption needs in AWS, KMS tends to be the best choice, requiring less operational overhead. However, for full-lifecycle key ownership or regulatory compliance, CloudHSM is likely a better choice despite its higher complexity.
Pricing Comparison of CloudHSM and KMS
The pricing model for CloudHSM and KMS differs quite a bit:
CloudHSM Pricing
CloudHSM pricing includes:
- Hourly charges for each provisioned HSM instance are based on instance size, e.g., $1.453 per hour for a crypto2.medium or $2.907/hour for a crypto2.xlarge instance.
- Data transfer charges per GB for traffic leaving the HSMs to reach other networks.
- No additional charges for API calls or encrypt/decrypt requests like KMS.
- Volume discounts are available, including 30-70% savings or 3—year—terms with All Upfront or Partial Upfront payments.
- You pay for dedicated HSM instances and network egress bandwidth. More keys and traffic require more instances.
KMS Pricing
KMS pricing consists of the following:
- Per API call charges: $0.03 per 10,000 API calls.
- Per GB charges for data encrypted/decrypted using KMS keys: $0.02 per GB.
- No HSM instance charges. AWS manages resources dynamically.
- The free tier provides 20,000 requests and 25 GB of encryption usage per month.
- Savings plans up to 70% off on-demand pricing.
Final Thoughts
In summary, AWS CloudHSM and KMS both provide robust encryption key management but are suited for different use cases. CloudHSM offers dedicated HSM appliances for complete control, meeting strict compliance requirements. KMS integrates encryption seamlessly across AWS with minimal operational overhead.
Choosing between the two services depends primarily on your needs for control, regulatory requirements, integration with AWS services, and operational responsibilities. For most general encryption uses on AWS, KMS provides the simplest management. While CloudHSM involves more effort, it provides the strongest isolation and control for high-security applications.
By evaluating the differences across key management, hardware architecture, security controls, AWS integration, use cases, and pricing models, you can determine the best option for managing cryptographic keys on AWS. Both services have benefits for certain workloads and can complement each other as part of a comprehensive encryption strategy.
Frequently Asked Questions
Which is more secure: CloudHSM or KMS?
CloudHSM provides the most secure model, requiring dedicated HSMs that are fully isolated and have control of keys. However, KMS is highly safe for most general uses, protecting keys in compliance with FIPS 140-2 and managed by AWS’s strict policies and procedures.
When should I use CloudHSM vs KMS?
Use CloudHSM for maximum control over keys, strong regulatory compliance needs, or existing on-premises HSMs. Use KMS for easier encryption across AWS services or if you want AWS to manage keys without operational overhead.
Can I migrate keys between CloudHSM and KMS?
No, there is no direct migration path between CloudHSM and KMS keys. CloudHSM keys can’t be exported from the HSM in a form that is compatible with KMS. You’d need to rewrite applications to use the key services separately.
Does KMS meet regulatory compliance requirements?
KMS keys can help meet compliance requirements like HIPAA and PCI DSS, but CloudHSM is better suited for stricter controls like FIPS 140-2 Level 3. Evaluate your compliance criteria to choose the right service.
Can I use CloudHSM and KMS keys together?
Yes, CloudHSM and KMS are complementary services. You can use CloudHSM for the most sensitive keys and KMS for general encryption of data across broader AWS services. This provides a balance of strong controls and ease of integration.
Is CloudHSM or KMS more cost-effective?
KMS is generally more cost-effective, requiring less operational overhead. CloudHSM has high fixed HSM instance costs but no call charges, so it may have lower TCO at extremely high usage volumes. Evaluate costs based on your call volumes.
How are keys secured in CloudHSM vs KMS?
CloudHSM keeps keys isolated in single-tenant HSMs that are fully under your control. KMS encrypts and stores keys in shared HSMs managed by AWS with logical isolation between customers. Both meet high security standards.
Can I use CloudHSM from on-premises?
Yes, through CloudHSM’s Sync Groups, you can synchronize your CloudHSM with an on-premises HSM to access keys. This requires deploying certified HSMs on-premises. KMS is accessible through APIs anywhere.
Do I need to backup keys in KMS?
No, AWS handles redundantly backing up your KMS keys. With CloudHSM, you are responsible for backups to avoid permanent key loss if HSMs fail.
What AWS services integrate with CloudHSM and KMS?
Many AWS services, such as EBS, S3, and Redshift, integrate directly with KMS for encryption. CloudHSM requires custom integration work to encrypt data in other services.
Can I manage access to KMS keys?
Yes, you control KMS key access through IAM policies and grants, as well as by disabling/deleting keys. With CloudHSM, network controls, firewalls, and HSM access policies manage access.
Does CloudHSM or KMS offer key rotation?
Both services support rotating your cryptographic keys for enhanced security. You can manage them directly on CloudHSM or via AWS APIs for KMS.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
