Overview – AWS KMS and CloudHSM

AWS offers two services for cryptographic key management in the cloud: AWS Key Management Service (AWS KMS) and AWS CloudHSM. Both protect encryption keys, but they differ fundamentally in FIPS validation level, tenancy model, who controls the hardware, and what compliance requirements each can satisfy. The recommended starting point for most workloads is AWS KMS with customer-managed keys; CloudHSM is required only when FIPS 140-2 Level 3 dedicated hardware or zero AWS key access is a firm requirement.

Quick Answer: AWS KMS vs. CloudHSM at a Glance

AWS KMS is a fully managed multi-tenant key management service with FIPS 140-2 Level 2 validated HSMs, native integration with 100+ AWS services, automatic key rotation, and per-operation CloudTrail audit logging. It is the right starting point for most AWS encryption workloads. AWS CloudHSM is a single-tenant dedicated HSM service with FIPS 140-2 Level 3 validated hardware in your own VPC, where AWS has zero access to your keys. CloudHSM is required for FIPS Level 3 mandates, classified workloads, or applications needing direct PKCS#11/JCE/CNG/OpenSSL API access. The two services can also be combined: a CloudHSM-backed KMS custom key store gives you Level 3 hardware protection with native KMS service integration simultaneously.

Key Takeaways

• KMS is multi-tenant Level 2; CloudHSM is single-tenant Level 3: AWS KMS uses FIPS 140-2 Level 2 validated HSMs shared across multiple customers with logical isolation. AWS CloudHSM provides dedicated physical HSM hardware validated to FIPS 140-2 Level 3 that no other customer accesses.
• AWS is inside the KMS trust boundary but outside the CloudHSM key trust boundary: With KMS, AWS operates the HSM hardware and is an operational party in the key chain. With CloudHSM, AWS manages the physical infrastructure but has no access to your key material or HSM partitions at any point.
• KMS integrates natively with AWS services; CloudHSM requires custom API calls or a KMS custom key store: AWS KMS works natively with S3, EBS, RDS, Lambda, and 100+ other services. CloudHSM does not integrate natively with those services unless combined with a KMS custom key store.
• The custom key store bridges both worlds: A KMS custom key store backed by a CloudHSM cluster provides Level 3 hardware protection for keys used through the standard KMS API and all native AWS service integrations. This is the common production architecture when both Level 3 and native AWS integration are required.
• Cost difference is large; choose based on requirements, not preference: KMS costs $1/key/month plus $0.03/10k API calls. A 2-HSM CloudHSM cluster costs approximately $2,100/month. Choose CloudHSM only when a firm compliance or technical requirement justifies the cost and operational overhead.

AWS Key Management Service (AWS KMS): Overview

AWS Key Management Service (AWS KMS) is a fully managed service that creates, stores, and controls the cryptographic keys used to protect data across AWS services and customer applications. KMS integrates natively with over 100 AWS services including Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, and AWS Secrets Manager. When you enable encryption on any of these services, KMS generates, stores, and protects the encryption keys that make that encryption meaningful.

All AWS KMS key material is generated and stored inside FIPS 140-2 Level 2 validated Hardware Security Modules (HSMs). Key material never leaves the HSM boundary in plaintext under any operational circumstance. AWS KMS operates the HSMs as a multi-tenant service, meaning multiple customers’ keys share the same physical hardware with logical isolation between them. Keys created in a given AWS region cannot be used or accessed from another region.

AWS KMS organizes keys into three types: customer-managed keys (which you create, control, and can rotate on a custom schedule), AWS-managed keys (created automatically by AWS services when you enable encryption without specifying a key), and AWS-owned keys (shared across multiple customer accounts and invisible in your account). For regulated workloads, only customer-managed keys provide the per-operation CloudTrail audit trail and independent key control required by PCI DSS, HIPAA, and FedRAMP. AWS renamed “Customer Master Keys (CMKs)” to “KMS keys” in 2021; the underlying functionality remains the same.

AWS KMS supports symmetric AES-256 keys for data encryption and decryption, asymmetric RSA (2048, 3072, 4096 bit) and ECC (NIST P-256, P-384, P-521 and SECG secp256k1) keys for signing and asymmetric encryption, and HMAC keys for message authentication. All symmetric keys and private asymmetric keys never leave the KMS HSMs in plaintext; only public keys can be exported from KMS.

For a detailed security evaluation of AWS KMS, including the trust boundary analysis, IAM model, and compliance mapping, see our guide on How Secure Are Key Management Services of Amazon (AWS KMS)?

AWS KMS: Crypto Properties Summary

Property	AWS KMS
Tenancy model	Multi-tenant (shared HSM hardware, logical isolation)
FIPS 140-2 validation	Level 2
Key types supported	Symmetric (AES-256), Asymmetric (RSA 2048/3072/4096, ECC NIST/SECG), HMAC
Key types	Customer-managed, AWS-managed, AWS-owned
API access	AWS SDK / AWS KMS API
Access control	IAM identity policies + KMS key resource policy (mandatory)
Key accessibility	Regional (keys created in a region cannot be used in another region)
High availability	AWS-managed, built-in (no customer configuration required)
Audit capability	CloudTrail management events (always on) + data events (must enable)
Automatic key rotation	Yes (90 days to 7 years for customer-managed keys with AWS-generated material)
BYOK support	Yes (via KMS Import Jobs; Origin: EXTERNAL)
Cost	$1.00/key/month + $0.03/10k API calls

AWS CloudHSM: Overview

AWS CloudHSM is a cloud-based Hardware Security Module service that provides dedicated, single-tenant physical HSM hardware within your own Amazon Virtual Private Cloud (VPC). CloudHSM is validated to FIPS 140-2 Level 3, the highest commercially available FIPS validation level for HSM hardware. Unlike AWS KMS, where AWS manages the HSMs as a shared service, CloudHSM allocates dedicated hardware exclusively to your organization.

AWS manages the physical infrastructure for CloudHSM (racking, networking, power, hardware replacement, and firmware updates) but has no access to your HSM software, key material, or HSM user credentials at any point. You manage the HSM software layer, HSM user and partition setup, and key material yourself, using hardware authentication mechanisms that are separate from AWS IAM. This means AWS cannot access your keys even if legally compelled to do so, because AWS genuinely does not hold the HSM authentication credentials or key material.

CloudHSM is accessed through industry-standard cryptographic APIs: PKCS#11 (the most widely supported standard across HSM vendors), JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation), and OpenSSL Dynamic Engine. This makes CloudHSM compatible with a wide range of applications that require HSM-backed cryptographic operations including CA private key protection for Public Key Infrastructure (PKI), code signing, database transparent data encryption (TDE), TLS/SSL private key protection, payment PIN encryption, and digital rights management (DRM).

CloudHSM clusters can span multiple Availability Zones within an AWS region for high availability. Each HSM in the cluster maintains a synchronized copy of all key material. For production workloads, a minimum of two HSMs in separate Availability Zones is required to ensure that no single hardware failure takes down cryptographic operations.

AWS CloudHSM: Crypto Properties Summary

Property	AWS CloudHSM
Tenancy model	Single-tenant (dedicated physical HSM hardware)
FIPS 140-2 validation	Level 3
Key types supported	Symmetric: AES (CBC, GCM, ECB modes); Asymmetric: RSA, ECC; Hashing: SHA-256, SHA-512, ECDSA
Master key	Master key stored and protected within the HSM hardware
API support	PKCS#11, JCE (Java), OpenSSL Dynamic Engine, Microsoft CNG
Access control	HSM user credentials (quorum-based K-of-N authentication, separate from AWS IAM)
Key accessibility	Accessible across multiple VPCs within the region via VPC peering
High availability	Add HSMs in different Availability Zones within the cluster
Audit capability	CloudTrail (infrastructure events), CloudWatch (metrics), HSM audit log (key operations), MFA support
Automatic key rotation	No (customer-managed, must implement externally)
AWS access to keys	None (AWS cannot access HSM partitions or key material)
Cost	~$1.45/hr per HSM (~$1,050/month per HSM; ~$2,100/month for 2-HSM HA cluster)

BYOK and HYOK: Key Sovereignty Options

Both AWS KMS and CloudHSM support Bring Your Own Key (BYOK) patterns, but the mechanics and sovereignty guarantees differ meaningfully.

BYOK with AWS KMS: You generate AES-256 key material in your own HSM or key management system outside AWS. You wrap the material using a wrapping key downloaded from a KMS Import Job and upload the wrapped material to KMS. The KMS key Origin is set to EXTERNAL. AWS KMS uses your imported material for all cryptographic operations. You retain the original outside AWS; deleting the imported copy from KMS immediately and permanently revokes AWS’s ability to use the key. AWS still has operational access to the imported key material while it is resident in KMS. Automatic rotation is not available for imported keys.

BYOK with CloudHSM (as generation source): You generate key material in your CloudHSM cluster and use that material as the BYOK source for keys imported into AWS KMS or into other key management systems. The key was generated in FIPS 140-2 Level 3 hardware that you control, giving you Level 3 key provenance proof. After import into KMS, the KMS copy is an imported key (Origin: EXTERNAL); your CloudHSM retains the authoritative copy.

HYOK (Hold Your Own Key) with CloudHSM: For the strongest key sovereignty model, your applications encrypt data using keys that reside in your CloudHSM cluster and never leave it. AWS services store only ciphertext. AWS has no access to the plaintext or the encryption key under any circumstance. This pattern requires your applications to call the CloudHSM APIs directly for every cryptographic operation, and your CloudHSM cluster must be highly available for all application operations to succeed.

Dimension	Native KMS (AWS-generated)	BYOK into KMS (Imported)	CloudHSM (Keys stay in HSM)
Key generated by	AWS KMS HSM	Customer HSM (imported into KMS)	Customer (stays in CloudHSM)
AWS access to key during use	Yes (multi-tenant HSM operator)	Yes (operational access while in KMS)	No
CloudTrail audit trail	Yes (per operation via KMS API)	Yes (per operation via KMS API)	HSM audit log only (not natively in CloudTrail for key ops)
Independent revocation	Disable/delete key in KMS	Delete imported material (immediate)	Destroy key in HSM cluster
Automatic key rotation	Yes (90 days to 7 years)	No (re-import required)	No (customer-managed)
FIPS validation level	Level 2	Level 2 (in KMS); generation source can be Level 3	Level 3
Native AWS service integration	Yes (100+ services)	Yes (via KMS API)	Only via custom key store
Operational complexity	Low	Medium	High

IAM Access Control Model

AWS KMS and CloudHSM use fundamentally different access control mechanisms, which is one of the most important differences to understand when choosing between them.

AWS KMS access control uses the AWS IAM model: a combination of key resource policies (the primary, mandatory control on every customer-managed key) and IAM identity policies (a secondary layer). A key policy must exist and must explicitly grant permissions for any principal to use the key. IAM identity policies can grant additional KMS permissions, but only within what the key policy permits. Service Control Policies (SCPs) at the AWS Organization level can add guardrails above IAM. The most important IAM security principle for KMS is separating key administrators (who can manage key policies, rotation, and key deletion) from key users (who can call Encrypt, Decrypt, and GenerateDataKey). No principal should have both roles on the same key. For full IAM model detail, see our guide on AWS KMS security.

CloudHSM access control uses the HSM’s own user and partition management system, which is entirely separate from AWS IAM. CloudHSM has three categories of users: the Precrypto Officer (PRECO, a temporary initial user used only for first-time HSM initialization), Crypto Officers (COs, who can create and delete HSM users and manage user credentials), and Crypto Users (CUs, who perform cryptographic operations on key material). CloudHSM supports quorum-based M-of-N authentication, requiring a minimum number of Crypto Officers to authenticate before sensitive operations (such as deleting a key or changing a policy) can proceed. AWS IAM has no role in CloudHSM key operations. This authentication layer is managed entirely by you, independent of any AWS account or IAM permission.

This access model difference has a significant security implication: for AWS KMS, the risk model includes a misconfigured key policy or IAM policy as the most common real-world vulnerability. For CloudHSM, the risk model includes misconfigured HSM user credentials, quorum thresholds set too low, or inadequate physical and logical access controls to the HSM management tooling.

Key Rotation

AWS KMS key rotation for customer-managed keys with AWS-generated material is automatic and configurable between 90 days and 7 years. When rotation occurs, KMS generates new key material and designates it as the primary version for new encryption operations. Previous key material versions are retained permanently so that data encrypted with them can still be decrypted. The key ARN and all aliases remain unchanged; rotation is transparent to applications. On-demand rotation is available via the RotateKeyOnDemand API. For BYOK keys with imported material, automatic rotation is not available; you must externally generate and re-import new material as a new key version.

AWS CloudHSM key rotation has no built-in automatic rotation mechanism. You are responsible for building and executing the rotation process: generating new key material in the HSM, updating the references in all applications and services that use the old key, re-encrypting or migrating data if required, and retiring the old key material. This adds significant operational complexity compared to KMS, particularly for environments with many keys or applications. For compliance workloads requiring periodic cryptographic key rotation (PCI DSS Requirement 3.7.4, NIST SP 800-57 cryptoperiod guidance), the rotation process for CloudHSM keys must be designed and tested before production deployment.

Audit Logging

AWS KMS CloudTrail integration is one of KMS’s strongest compliance features. Every KMS API call generates a CloudTrail event recording the operation, key ARN, requesting IAM identity, source IP, region, and timestamp. Management events (key creation, key policy changes, ScheduleKeyDeletion, DisableKey) are always on. Data events (GenerateDataKey, Decrypt per object operation) must be enabled separately for regulated workloads and provide the per-operation identity-linked audit trail required by PCI DSS Requirement 10, HIPAA Audit Control (45 CFR 164.312(b)), and FedRAMP AU controls.

AWS CloudHSM audit logging works differently. Infrastructure-level events (HSM cluster creation, HSM instance add/remove, cluster deletion) appear in CloudTrail. However, key operations performed inside the HSM (key creation, encryption, signing, decryption within the HSM partition) are recorded in the HSM’s own internal audit log, not in CloudTrail. The HSM audit log can be exported to CloudWatch Logs or an S3 bucket for retention and analysis, but it is not the same native CloudTrail integration that KMS provides. For environments where the auditor expects CloudTrail evidence for every cryptographic operation, the CloudHSM audit log requires additional tooling to aggregate and present in the same format.

Custom Key Store: Using Both Services Together

The AWS KMS custom key store feature allows you to combine the operational simplicity of KMS with the FIPS 140-2 Level 3 hardware isolation of CloudHSM. When you configure a custom key store, you link your CloudHSM cluster to AWS KMS. KMS keys created in that custom key store have their material generated inside your CloudHSM cluster rather than in the standard KMS multi-tenant infrastructure. The key material is non-exportable and never leaves your CloudHSM cluster in plaintext.

The practical benefit: all 100+ AWS service integrations continue to work through the normal KMS API. S3 SSE-KMS, EBS encryption, RDS encryption, Secrets Manager encryption, and every other KMS-integrated service can use a key backed by your CloudHSM cluster. From the application and AWS service perspective, the key is just a KMS key; the CloudHSM backing is transparent.

Important constraints for custom key stores: at least two active HSMs in different Availability Zones are required. If your CloudHSM cluster becomes unavailable, KMS cannot perform any operations on keys in that custom key store, which means any application or AWS service using those keys will fail until the cluster is restored. This availability dependency is the primary operational risk of the custom key store architecture. Design your CloudHSM cluster for the same availability target as the applications whose encryption keys it holds.

For the full operational detail of the custom key store integration and KMS key hierarchy mechanics, see our AWS KMS Deep Dive.

How to Choose: AWS KMS vs. CloudHSM Decision Framework

Use this decision framework to select the right service for your workload:

Requirement	Recommended service
Encrypt S3, EBS, RDS, DynamoDB, or other AWS services with minimal configuration	AWS KMS (native integration)
FIPS 140-2 Level 2 validation is acceptable	AWS KMS
FIPS 140-2 Level 3 dedicated hardware is required	AWS CloudHSM (or KMS custom key store backed by CloudHSM)
AWS must be completely excluded from the key trust boundary	AWS CloudHSM (HYOK/client-side encryption)
Per-operation CloudTrail audit log via native AWS integration	AWS KMS
Automatic key rotation on a configurable schedule	AWS KMS
PKCS#11, JCE, CNG, or OpenSSL API access to the HSM	AWS CloudHSM
CA private key protection for a PKI certificate authority	AWS CloudHSM
TLS/SSL offload, payment PIN encryption, database TDE master key	AWS CloudHSM
BYOK with customer-controlled key generation source at Level 3	Generate in CloudHSM; import into KMS (or keep in CloudHSM)
FedRAMP Moderate	AWS KMS (customer-managed keys)
FedRAMP High (FIPS 140-2 Level 3 required under SC-12)	CloudHSM custom key store or AWS CloudHSM directly
PCI DSS v4.0.1 (most requirements)	AWS KMS with customer-managed keys + CloudTrail data events
PCI DSS Requirement 3.7.1 (key generation in HSM)	CloudHSM custom key store or CloudHSM as BYOK source
Lowest operational overhead	AWS KMS
Lowest cost for a small number of keys	AWS KMS ($1/key/month vs ~$2,100/month for 2-HSM CloudHSM cluster)

Cost Comparison

AWS KMS cost: $1.00 per customer-managed key per month. AWS-managed and AWS-owned keys have no key storage fee. API calls cost $0.03 per 10,000 requests (symmetric operations). For high-volume S3 workloads, S3 Bucket Key reduces KMS API call volume by up to 99%, dramatically reducing per-operation costs. For most workloads, KMS costs are measured in tens of dollars per month, not hundreds.

AWS CloudHSM cost: Approximately $1.45 per hour per HSM instance (pricing subject to change; verify current pricing at aws.amazon.com). A single HSM costs approximately $1,050 per month. The minimum production configuration (two HSMs in separate Availability Zones for HA) costs approximately $2,100 per month. There are no per-API-call charges for CloudHSM operations. Larger clusters for higher cryptographic throughput add approximately $1,050 per additional HSM per month.

The cost gap is significant. A single customer-managed KMS key costs about $12 per year. A two-HSM CloudHSM cluster costs about $25,200 per year. CloudHSM makes economic sense when high cryptographic operation volume would generate large KMS API call charges that exceed the CloudHSM fixed cost, or when Level 3 hardware or dedicated tenancy requirements make CloudHSM operationally mandatory regardless of cost.

Compliance Mapping

PCI DSS v4.0.1 (mandatory since March 31, 2025): AWS KMS with customer-managed keys satisfies Requirement 3.5.1 (strong cryptography for stored PANs) and Requirement 3.7.4 (key rotation) with automatic rotation enabled. CloudTrail Data Access events satisfy Requirement 10. For Requirement 3.7.1 (key generation using an HSM), a CloudHSM custom key store or CloudHSM as the BYOK generation source is required, as standard KMS does not validate at Level 3.

FedRAMP: Standard AWS KMS (FIPS 140-2 Level 2) satisfies FedRAMP Moderate SC-12 and SC-28 controls. FedRAMP High requires FIPS 140-2 Level 3 validated modules for cryptographic key management; this requires either AWS CloudHSM or a KMS custom key store backed by CloudHSM. Both AWS KMS and CloudHSM are included in AWS’s FedRAMP High authorization package.

HIPAA: AWS KMS with customer-managed keys satisfies the HIPAA Technical Safeguard for Encryption and Decryption (45 CFR 164.312(a)(2)(iv)) for ePHI at rest. AWS’s Business Associate Agreement (BAA) covers both KMS and CloudHSM. CloudTrail Data Access events satisfy the Audit Control standard (45 CFR 164.312(b)). For organizations with HIPAA risk analyses requiring dedicated hardware or zero cloud-provider key access, CloudHSM satisfies both requirements.

DORA (Digital Operational Resilience Act, applicable to EU financial entities since January 17, 2025): DORA Articles 9 and 10 require ICT risk management and operational resilience including key management resilience. Both KMS (multi-AZ key replication, automatic rotation) and CloudHSM (multi-AZ cluster configuration) support DORA’s resilience requirements when correctly configured.

Multi-Cloud Key Management Architecture

Neither AWS KMS nor AWS CloudHSM natively extends to Azure, GCP, or on-premises environments. Organizations operating across multiple cloud providers need an explicit strategy for cryptographic key governance beyond the AWS boundary.

• Per-cloud native KMS with centralized governance: Use AWS KMS for AWS workloads, Azure Key Vault for Azure, and GCP Cloud KMS for GCP. A centralized key lifecycle management platform aggregates inventory, rotation status, and audit logs from all three providers. Each cloud’s data is protected by that cloud’s native KMS without introducing cross-cloud latency. This is the most operationally efficient model for multi-cloud environments.
• CloudHSM as a shared BYOK generation source: Generate all key material from a CloudHSM cluster that is accessible across clouds. Import derived keys into AWS KMS for AWS workloads, Azure Key Vault for Azure workloads, and GCP Cloud KMS for GCP workloads. All encryption traces back to a single authoritative Level 3 hardware source. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 HSM infrastructure for this model when an independent (non-AWS) HSM source is preferred.
• External HSM as a Service for HYOK across all clouds: Encrypt data at the application or pipeline layer before it reaches any cloud provider using keys held in an external HSM as a Service. All clouds store only ciphertext. This provides the strongest cross-cloud sovereignty posture and eliminates all three cloud providers from the key trust chain, at the cost of application complexity and external HSM availability requirements.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations evaluate, design, and implement AWS KMS and CloudHSM architectures from initial service selection through ongoing compliance evidence generation.

• AWS KMS and CloudHSM Architecture Design: We evaluate your compliance requirements, threat model, operational capacity, and workload characteristics to recommend the right combination of KMS, CloudHSM, and custom key store. We design the key hierarchy, IAM key policy model, rotation schedule, and audit log routing for each service. See our cloud advisory services.
• HSM as a Service: For BYOK implementations requiring FIPS 140-2 Level 3 key generation outside AWS, or for HYOK architectures requiring an external key management system, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure accessible from AWS, Azure, and GCP simultaneously. Serves as a CloudHSM alternative for organizations that need Level 3 hardware without the operational complexity of managing a CloudHSM cluster.
• CBOM Secure for AWS Cryptographic Discovery: AWS environments often accumulate inconsistent KMS configurations: a mix of AWS-owned keys, AWS-managed keys, and customer-managed keys with varying policies and rotation schedules. Encryption Consulting’s CBOM Secure discovers and inventories all KMS key configurations, CloudHSM clusters, and key access policies across AWS accounts, generating a Cryptographic Bill of Materials (CBOM) in CycloneDX format identifying compliance gaps and supporting PCI DSS v4.0.1 Requirement 12.3.3 documentation.
• PCI DSS and FedRAMP Compliance Advisory: We map your AWS KMS and CloudHSM configuration to the specific requirements of PCI DSS v4.0.1, FedRAMP High, HIPAA, DORA, and NIST SP 800-53 Rev. 5. We identify control gaps, produce the compliance evidence package, and assist with QSA and assessor inquiries. See our Compliance Advisory Services.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 indicates RSA and ECC for new uses should be deprecated around 2030. Both KMS and CloudHSM RSA/ECC asymmetric keys will need migration. Encryption Consulting’s PQC Readiness service maps your AWS key estate against the post-quantum migration timeline.

To discuss your AWS KMS and CloudHSM architecture or compliance requirements, contact Encryption Consulting.

Conclusion

AWS KMS and AWS CloudHSM serve distinct roles in the AWS cryptographic key management stack. KMS is the right default for most AWS encryption workloads: it is fully managed, integrates natively with all major AWS services, provides automatic key rotation, delivers a per-operation CloudTrail audit trail, and satisfies most regulated workload requirements at FIPS 140-2 Level 2. CloudHSM is the right choice when a firm requirement mandates FIPS 140-2 Level 3 dedicated hardware, when AWS must be excluded from the key trust chain entirely, or when an application needs direct PKCS#11/JCE/CNG/OpenSSL access to an HSM.

The custom key store architecture bridges both services: Level 3 hardware protection for keys used through the full KMS API and all native AWS service integrations. For most organizations that eventually need CloudHSM capabilities, the custom key store is the architecture that provides both without requiring a migration away from KMS.

For deeper coverage of AWS KMS security evaluation and trust boundaries, see our guide on How Secure Are Key Management Services of Amazon (AWS KMS)? For KMS operational mechanics including key creation workflows, envelope encryption, and data key patterns, see our AWS KMS Deep Dive.

Frequently Asked Questions

What is the difference between AWS KMS and AWS CloudHSM?

AWS KMS is a fully managed, multi-tenant key management service with FIPS 140-2 Level 2 validated HSMs. AWS manages the hardware. You control key policies and rotation. AWS CloudHSM provides single-tenant dedicated physical HSM hardware validated to FIPS 140-2 Level 3 in your VPC. AWS manages the physical hardware but has no access to your keys or HSM partitions. You manage HSM users, key material, and authentication separately from AWS IAM.

When should I use AWS KMS instead of CloudHSM?

Use AWS KMS when you need native integration with S3, EBS, RDS, Lambda, or other AWS services, want automatic key rotation and per-operation CloudTrail audit logging, and where FIPS 140-2 Level 2 multi-tenant hardware is acceptable. KMS covers most regulated workloads including HIPAA, PCI DSS (with customer-managed keys and data event logging), and FedRAMP Moderate. Start with KMS unless a specific requirement forces you to CloudHSM.

When should I use AWS CloudHSM instead of KMS?

Use CloudHSM when FIPS 140-2 Level 3 dedicated single-tenant hardware is required (FedRAMP High, eIDAS), when AWS must be excluded from the key trust chain entirely, or when an application requires direct PKCS#11, JCE, CNG, or OpenSSL API access to the HSM (CA private key protection, TLS offload, payment PIN operations, database TDE). CloudHSM has significant operational overhead and costs approximately $2,100/month for a minimum HA configuration.

What is BYOK in AWS KMS and how is it different from CloudHSM BYOK?

BYOK into KMS means you generate key material externally, wrap it, and import it into a KMS key (Origin: EXTERNAL). AWS uses your imported material; you retain the original outside AWS; deleting the import immediately revokes AWS’s ability to use it. AWS still has operational access to the key while it is resident in KMS, and automatic rotation is unavailable. CloudHSM BYOK means the key stays in your CloudHSM cluster; AWS never accesses it. CloudHSM can also serve as the Level 3 generation source for keys imported into KMS.

Can AWS KMS and CloudHSM be used together?

Yes, through the KMS custom key store feature. A custom key store links your CloudHSM cluster to KMS. KMS keys created in the custom key store have their material generated and stored in your CloudHSM cluster (FIPS 140-2 Level 3), while all 100+ native AWS service integrations continue to work through the normal KMS API. This gives you Level 3 hardware protection with native AWS service integration simultaneously. The trade-off: your CloudHSM cluster availability directly affects KMS key availability.

What does AWS KMS and CloudHSM cost?

AWS KMS: $1.00 per customer-managed key per month, plus $0.03 per 10,000 API calls. AWS-managed and AWS-owned keys have no storage fee. AWS CloudHSM: approximately $1.45 per hour per HSM (~$1,050/month per HSM). A minimum production HA configuration (2 HSMs) costs approximately $2,100 per month or $25,200 per year. There is no per-API-call charge for CloudHSM operations. A single KMS key costs about $12 per year; a 2-HSM CloudHSM cluster costs about $25,200 per year.