This chapter provides a comprehensive comparison between AWS Key Management Service (KMS) and AWS CloudHSM, two crucial services for cryptographic key management in AWS. Understanding their differences is essential for the SAA-C03 exam, as questions on secure key storage, compliance, and encryption architecture appear in roughly 10–15% of exam questions. By the end of this chapter, you will be able to determine which service is appropriate for various compliance and security requirements, and you will know the exact exam scenarios that test your ability to choose between KMS and CloudHSM.
Jump to a section
AWS KMS is like a bank vault: you bring your valuables (data) and the bank stores them inside the vault using their own high-security locks. You can request the bank to put items in or take them out, but you never handle the vault's master key—the bank controls it entirely. You get a token (encrypted data key) that lets you access your items only when the bank authorizes it. The vault is managed, scalable, and you pay per use. AWS CloudHSM is like your own safety deposit box inside the bank: you hold the only key to your box. The bank provides the secure room and physical security, but you are responsible for the key. You can come and go to access your box directly, performing cryptographic operations with your key that never leaves your possession. The bank cannot open your box without your key. CloudHSM gives you sole control over your cryptographic keys within a tamper-resistant hardware device that you manage. The analogy highlights: KMS is managed, shared responsibility with AWS; CloudHSM is dedicated, customer-managed hardware with exclusive key control.
What Are AWS KMS and AWS CloudHSM?
AWS KMS (Key Management Service) is a managed service that allows you to create, control, and rotate encryption keys used to encrypt your data. It integrates with over 50 AWS services, such as S3, EBS, RDS, and Lambda, to provide envelope encryption. KMS uses FIPS 140-2 Level 2 validated hardware security modules (HSMs) in a shared multi-tenant environment. AWS manages the underlying HSM infrastructure, including key backups, software updates, and high availability. You never have direct access to the HSM; all operations are performed via the KMS API.
AWS CloudHSM is a dedicated hardware security module (HSM) that you own and manage within your AWS VPC. It provides FIPS 140-2 Level 3 validated HSMs, offering a higher level of physical security and tamper resistance. With CloudHSM, you have full control over the cryptographic keys and the HSM itself, including user management, key creation, and deletion. AWS manages the hardware and network connectivity but does not have access to your keys. You interact with the HSM using industry-standard APIs like PKCS#11, Java JCE, and Microsoft CNG.
How They Work Internally
KMS Mechanism: - KMS uses envelope encryption: you create a Customer Master Key (CMK) in KMS. When you encrypt data, KMS generates a data key (DEK) that is encrypted under the CMK. The encrypted data key is stored alongside the ciphertext. To decrypt, you send the encrypted data key to KMS, which decrypts it using the CMK and returns the plaintext data key. - KMS CMKs are stored in HSMs that are clustered across multiple Availability Zones. AWS manages key rotation (automatic yearly rotation for AWS managed keys, optional for customer managed keys). - Access control is via IAM policies and key policies. You can also use grants to allow AWS services to use your CMK on your behalf. - KMS supports cryptographic operations up to 10 KB of data directly (symmetric encryption). For larger data, you must use envelope encryption.
CloudHSM Mechanism: - CloudHSM provides a dedicated HSM appliance (hardware) that you manage via the CloudHSM client software. You define CU (Crypto User) and CO (Crypto Officer) users. COs manage users and the HSM configuration; CUs perform cryptographic operations. - Keys are generated and stored within the HSM. They never leave the device in plaintext. You can back up keys to encrypted files (with a password) or to a second HSM cluster. - CloudHSM supports symmetric and asymmetric algorithms, including RSA, ECC, AES, and HMAC. It can perform signing, verification, and key wrapping. - The HSM is deployed in an AWS-managed VPC, but you control network security groups and must ensure your application can reach the HSM endpoint (IP address).
Key Components, Values, and Defaults
KMS: - CMK types: AWS managed (aws/service-name), Customer managed (you create), Custom key store (CloudHSM-backed). - Key rotation: AWS managed keys rotate automatically every year (365 days). Customer managed keys can be rotated annually (optional). Manual rotation requires creating a new CMK and updating aliases. - Key policies: JSON documents that define who can use the key. You can also use IAM policies with the kms:ViaService condition. - Envelope encryption: Use GenerateDataKey API to get a plaintext data key and an encrypted copy. Use Decrypt API to decrypt the encrypted data key. - Limits: KMS can handle up to 5,500 requests per second per Region for symmetric CMKs (default quota, adjustable).
CloudHSM: - HSM type: Currently, CloudHSM uses FIPS 140-2 Level 3 validated HSMs (previously Level 2, but Level 3 as of 2025). - Users: CO (Crypto Officer) – manages users and HSM; CU (Crypto User) – performs crypto operations; AU (Appliance User) – AWS management (cannot access keys). - Key storage: Keys are stored within the HSM. Backups are encrypted with a password you provide. - High availability: You can create a cluster of up to 6 HSMs across multiple AZs. Load balancing and failover are automatic via the CloudHSM client. - Performance: CloudHSM can handle thousands of cryptographic operations per second per HSM, depending on algorithm and key size.
Configuration and Verification
KMS Configuration: - Create a CMK via AWS Management Console, CLI, or SDK. - Example CLI to create a symmetric CMK:
aws kms create-key --description "My key" --key-usage ENCRYPT_DECRYPT --origin AWS_KMSTo encrypt a small file:
aws kms encrypt --key-id <key-id> --plaintext fileb://plaintext.txt --output text --query CiphertextBlob | base64 --decode > encrypted.txtTo decrypt:
aws kms decrypt --ciphertext-blob fileb://encrypted.txt --output text --query Plaintext | base64 --decode > decrypted.txtCloudHSM Configuration: - Create a CloudHSM cluster via AWS Console or CLI. - Initialize the cluster, then download the cluster certificate and sign it with your own CA. - Install the CloudHSM client on your EC2 instance. - Activate the HSM by setting a password for the PRECO (pre-Crypto Officer) user. - Create users (CO, CU) and then generate keys using PKCS#11 tools. - Example using pkcs11-tool:
pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so --login --login-type user --keypairgen --key-type rsa:2048 --label my-keyTo verify keys:
pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so --login --list-objectsInteractions with Related Technologies
KMS Integrations: - S3: Server-Side Encryption with KMS (SSE-KMS) – S3 uses a CMK to generate data keys for each object. Supports bucket policies with kms:ViaService. - EBS: Encrypt volumes using a CMK. Snapshots are also encrypted. - RDS: Encrypt databases at rest using KMS. Oracle TDE uses KMS. - Lambda: Environment variables can be encrypted with KMS. - Secrets Manager: Uses KMS to encrypt secrets.
CloudHSM Integrations: - CloudHSM is used for applications requiring direct access to HSM for custom cryptographic operations, such as SQL Server TDE, Oracle TDE, or custom PKI. - It integrates with AWS services via custom key stores in KMS: you can create a CMK backed by CloudHSM, combining KMS ease of use with CloudHSM key control. - CloudHSM also works with AWS Certificate Manager Private CA for issuing private certificates.
Key Differences in Exam Context
Compliance: KMS is FIPS 140-2 Level 2; CloudHSM is Level 3. For regulatory requirements like PCI DSS or HIPAA that demand dedicated HSM, CloudHSM is required.
Control: KMS is managed by AWS; you cannot extract keys. CloudHSM gives you full control; you can export keys (with proper authorization).
Cost: KMS is pay-per-use ($1 per CMK per month + $0.03 per 10,000 requests). CloudHSM has an hourly cost (approx. $1.50 per HSM per hour) plus a monthly fee.
Scalability: KMS scales automatically. CloudHSM requires manual scaling by adding more HSMs to the cluster.
Performance: For high-volume cryptographic operations, CloudHSM can provide lower latency and higher throughput because it's dedicated. KMS has request rate limits.
Common Exam Traps
Trap 1: Thinking CloudHSM is always more secure. While Level 3 is physically more secure, KMS is often sufficient for most workloads. The exam tests whether you know the compliance levels.
Trap 2: Assuming KMS keys can be exported. They cannot. CloudHSM keys can be exported (with proper procedures).
Trap 3: Mixing up envelope encryption: KMS uses data keys, not the CMK directly for large data. The exam expects you to know that KMS encrypts up to 10 KB directly; larger data requires GenerateDataKey.
Trap 4: CloudHSM is not a managed service in the same sense as KMS. You must manage users, keys, and backups. AWS only manages hardware and network.
Summary
Choose KMS when you need integrated encryption with AWS services, automatic key rotation, and a fully managed service. Choose CloudHSM when you require dedicated HSM hardware, FIPS 140-2 Level 3 compliance, or direct control over cryptographic keys and operations. The exam will present scenarios with compliance requirements, performance needs, and integration with AWS services—your task is to match the scenario to the correct service.
Identify Encryption Requirements
Examine the workload's compliance needs (PCI DSS, HIPAA, SOC) and regulatory standards. If FIPS 140-2 Level 3 or dedicated HSM is required, CloudHSM is the choice. If Level 2 is sufficient and you want integration with AWS services, KMS is appropriate. Also consider whether you need to export keys or have full control over key lifecycle.
Assess Integration with AWS Services
If the workload uses S3, EBS, RDS, Lambda, or Secrets Manager with server-side encryption, KMS integrates natively with minimal configuration. CloudHSM requires custom key stores in KMS for integration, adding complexity. For applications that need direct PKCS#11 or JCE access, CloudHSM is necessary.
Evaluate Performance and Scalability Needs
KMS has default request rate limits (5,500 req/s per Region). For high-throughput encryption (e.g., thousands of transactions per second), CloudHSM provides dedicated performance. CloudHSM clusters can be scaled horizontally, but you must manage capacity. KMS scales automatically but may require a quota increase.
Consider Key Management Control
KMS automatically rotates AWS managed keys yearly; customer managed keys can be rotated optionally. You cannot extract the plaintext CMK. CloudHSM gives you full control: you create, rotate, export, and delete keys. You manage user permissions (CO, CU) and can back up keys. The exam tests your understanding of these control differences.
Analyze Cost Implications
KMS is cost-effective for low-volume use: $1/CMK/month plus $0.03 per 10,000 requests. CloudHSM has a fixed hourly cost (~$1.50/HSM/hour) plus monthly fees, making it expensive for low usage but cost-effective at high volumes. The exam may present a scenario with budget constraints; you must calculate which service is cheaper.
Make the Final Decision
Based on the above factors, choose KMS for most general-purpose encryption with AWS services. Choose CloudHSM for compliance requiring Level 3, dedicated HSM, or full key control. Remember that you can also use KMS custom key stores backed by CloudHSM to get the best of both: KMS integration with CloudHSM key control.
Scenario 1: Financial Services Compliance (PCI DSS) A payment processing company must store credit card numbers encrypted with a dedicated HSM that meets PCI DSS requirements. They deploy CloudHSM within a VPC, creating a cluster of two HSMs across two AZs for high availability. They use the CloudHSM client on EC2 instances running their payment application. The application uses PKCS#11 to generate and use encryption keys. They back up keys to an encrypted file stored in S3 with restricted IAM policies. A common mistake is failing to properly initialize the cluster and download the certificate, causing connectivity issues. They also learned that they must manage user passwords securely; losing the CO password means losing access to the HSM.
Scenario 2: Healthcare Data Encryption (HIPAA) A healthcare startup needs to encrypt patient records in S3 and RDS. They choose KMS because it integrates directly with these services and HIPAA allows FIPS 140-2 Level 2. They create a customer managed CMK with automatic yearly rotation. They use IAM policies to restrict access to the CMK based on the kms:ViaService condition to ensure only S3 and RDS can use it. They enable CloudTrail to log every KMS API call. The challenge was setting up key policies correctly to allow the RDS service to use the CMK for encryption. They also discovered that KMS request rate limits can be hit during peak loads, so they requested a quota increase.
Scenario 3: Custom PKI with Private CA An enterprise needs to issue private certificates for internal applications. They use AWS Certificate Manager Private CA with a CloudHSM-backed key store. This allows them to store the CA private key in a dedicated HSM (FIPS 140-2 Level 3) while using ACM to manage certificate lifecycle. They create a custom key store in KMS linked to their CloudHSM cluster. The CA private key never leaves the HSM. They experienced an issue where the custom key store became unavailable because the CloudHSM cluster was down due to a network misconfiguration; they learned to monitor HSM health and enable automatic failover.
SAA-C03 Objective 1.2: This objective covers designing secure access to AWS resources, including encryption and key management. Questions on KMS vs CloudHSM typically appear in scenarios where you must choose the right service based on compliance, control, or integration needs.
Common Wrong Answers and Why Candidates Choose Them: 1. Choosing KMS when the scenario requires FIPS 140-2 Level 3 – Candidates see 'encryption' and pick KMS without checking the compliance level. The exam explicitly states 'dedicated HSM' or 'FIPS 140-2 Level 3' as a requirement. Always look for these keywords. 2. Choosing CloudHSM when the integration is with S3 or RDS – Candidates think CloudHSM is always better because it's 'more secure'. But if the scenario mentions 'server-side encryption' with S3 or RDS, KMS is the appropriate choice because of native integration. CloudHSM would require additional setup (custom key store). 3. Thinking KMS keys can be exported – Candidates confuse KMS with CloudHSM. KMS CMKs are non-exportable. If the scenario requires key exportability, CloudHSM is the answer. 4. Assuming CloudHSM is fully managed – Candidates think because it's an AWS service, AWS manages everything. In reality, you manage users, keys, and backups. AWS only manages hardware and network.
Specific Numbers and Terms That Appear on the Exam: - FIPS 140-2 Level 2 (KMS) vs Level 3 (CloudHSM) - Envelope encryption: GenerateDataKey, Decrypt - CMK types: AWS managed, customer managed, custom key store - CloudHSM users: CO, CU, AU - CloudHSM cluster: up to 6 HSMs - KMS request rate limit: 5,500 requests per second (default)
Edge Cases: - When the scenario requires both KMS integration and dedicated HSM, the answer is a custom key store (CloudHSM-backed KMS). - If the scenario mentions 'offline key storage' or 'key backup', CloudHSM allows key export; KMS does not. - If the scenario requires high-performance cryptographic operations (e.g., thousands of TPS), CloudHSM is preferred over KMS.
How to Eliminate Wrong Answers: 1. Identify compliance requirement: Level 2 vs Level 3. 2. Identify integration: If the service is S3, RDS, etc., KMS is likely the answer unless compliance demands Level 3. 3. Identify control: If the scenario says 'customer managed keys' or 'full control', CloudHSM. 4. Identify cost: If budget is a concern and usage is low, KMS is cheaper.
KMS is FIPS 140-2 Level 2; CloudHSM is Level 3 — exam questions hinge on this difference.
KMS uses envelope encryption; you must use GenerateDataKey for data >10 KB.
CloudHSM requires you to manage users (CO, CU) and key backups — AWS only manages hardware.
KMS integrates directly with S3, EBS, RDS, Lambda, and Secrets Manager for server-side encryption.
CloudHSM can be used as a custom key store for KMS to combine integration with dedicated HSM control.
KMS has a default request rate limit of 5,500 requests per second per Region.
CloudHSM clusters support up to 6 HSMs across multiple AZs for high availability.
KMS CMKs are non-exportable; CloudHSM keys can be exported with a password.
For compliance requiring dedicated HSM (e.g., PCI DSS), choose CloudHSM or KMS with custom key store.
Cost: KMS is cheaper for low-volume use; CloudHSM is cost-effective at high volumes.
These come up on the exam all the time. Here's how to tell them apart.
AWS KMS
FIPS 140-2 Level 2 validated
Fully managed by AWS
Keys are non-exportable
Integrates natively with 50+ AWS services
Pay per use: $1/CMK/month + $0.03 per 10,000 requests
AWS CloudHSM
FIPS 140-2 Level 3 validated
Customer-managed HSM (AWS manages hardware)
Keys can be exported (encrypted)
Requires custom key store for AWS service integration
Hourly cost: ~$1.50/HSM/hour + monthly fee
Mistake
AWS KMS is FIPS 140-2 Level 3 validated.
Correct
KMS is FIPS 140-2 Level 2 validated. CloudHSM provides Level 3 validation. The exam tests this distinction.
Mistake
CloudHSM is a fully managed service like KMS.
Correct
CloudHSM is a dedicated HSM you manage. AWS manages hardware and network, but you are responsible for user management, key creation, rotation, and backups.
Mistake
You can export your KMS CMK in plaintext.
Correct
KMS CMKs are non-exportable. Only CloudHSM allows key export (encrypted with a password).
Mistake
KMS can encrypt data larger than 10 KB directly.
Correct
KMS can encrypt up to 10 KB directly. For larger data, you must use envelope encryption (GenerateDataKey).
Mistake
CloudHSM provides automatic key rotation.
Correct
CloudHSM does not provide automatic key rotation. You must manually rotate keys or implement a custom solution. KMS offers automatic yearly rotation for customer managed keys.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The main difference is the level of control and compliance. KMS is a fully managed service with FIPS 140-2 Level 2 validation, integrated with many AWS services, and keys are non-exportable. CloudHSM provides a dedicated HSM with Level 3 validation, full control over keys (including export), but requires you to manage users and keys. Choose KMS for ease of use and integration; choose CloudHSM for strict compliance or custom cryptographic operations.
Yes, via custom key stores. You can create a CMK in KMS that is backed by your CloudHSM cluster. This allows you to use KMS's integration with AWS services while storing the key in your dedicated HSM. The key never leaves the HSM, and you retain control. This is a common exam scenario for combining both services.
For PCI DSS, you may need a dedicated HSM that meets Level 3 requirements. CloudHSM is FIPS 140-2 Level 3, so it is suitable. Alternatively, you can use KMS with a custom key store backed by CloudHSM. Always check the specific PCI DSS requirement; if it mandates a dedicated HSM, CloudHSM is required.
No, KMS CMKs are non-exportable. The key material never leaves the KMS service. If you need to export keys (e.g., for backup or migration), you must use CloudHSM, which allows exporting keys encrypted with a password.
KMS offers automatic yearly rotation for AWS managed keys. For customer managed keys, you can enable automatic rotation (also yearly) or manually rotate by creating a new CMK and updating aliases. CloudHSM does not provide automatic rotation; you must implement it yourself.
Envelope encryption is the practice of encrypting data with a data key (DEK) and then encrypting the DEK with a master key (CMK). KMS uses this for data larger than 10 KB. You call GenerateDataKey to get a plaintext DEK and an encrypted DEK. Use the plaintext DEK to encrypt your data locally, then discard it. Store the encrypted DEK with the ciphertext. To decrypt, send the encrypted DEK to KMS to get the plaintext DEK.
You've just covered AWS CloudHSM vs AWS KMS — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?