CloudHSM vs KMS

By the end of this lesson you will be able to

• Explain what AWS CloudHSM is: dedicated, single-tenant hardware security modules in your own VPC, where AWS manages the hardware and you alone manage the users and keys.
• Split the responsibilities correctly: what AWS does, what IAM controls, what only HSM users can do, and why AWS cannot recover your keys if you lose your credentials.
• State the FIPS 140 facts the exam asks about, the current ones (CloudHSM hsm2m.medium and KMS are both FIPS 140-3 Level 3) and how to answer older questions that still say “KMS = Level 2”.
• Make CloudHSM highly available with a cluster of HSMs across Availability Zones, and say what goes wrong with a single HSM.
• Use your HSMs with S3, EBS, RDS and other services through a KMS custom key store, know its requirements and limits, and know when an external key store fits instead.
• Recognise the workloads that need CloudHSM directly (PKCS#11, JCE, CNG, SSL/TLS offload, TDE, a CA’s private key) and choose between KMS and CloudHSM from a scenario’s keywords.

#Why CloudHSM: when KMS is not enough

In lesson 21.2 you met AWS KMS: AWS creates and protects your keys in its own hardware security modules, every AWS service can use them, and you pay a dollar a month per key. For most workloads that is the right answer. This lesson is about the cases where it is not, because a rule, an auditor or an old application demands more control than a shared, fully managed service can give. The exam loves to put KMS and CloudHSM side by side and ask you to pick one, so the whole lesson ends in a comparison.

#What an HSM is

A hardware security module (HSM) is a dedicated computer built for one job: to generate, store and use cryptographic keys so that the keys never leave it in plain form. Applications send it data and get back the result (ciphertext, plaintext, a signature), never the key. It is tamper-resistant: opening the case, drilling or probing it makes it wipe its keys. Banks, card networks, certificate authorities and governments have used HSMs for decades. KMS itself runs on HSMs; the difference is who owns and controls them.

#What CloudHSM gives you

AWS CloudHSM rents you HSMs in the AWS cloud:

• Dedicated, single-tenant hardware. Each HSM is yours alone; no other customer’s keys share it. KMS, by contrast, is multi-tenant: many customers’ keys live in the same fleet of AWS HSMs, kept apart by software.
• In your VPC. Each HSM appears in a subnet you choose as an elastic network interface with a private IP address. Your applications reach it over your own network.
• AWS manages the hardware, you manage the keys. AWS provisions the device, patches firmware, monitors health, replaces failed hardware and takes encrypted backups. You create the HSM users and the keys, and only you can use them: AWS has no login on your HSMs. The slides put it in one line each: KMS means AWS manages the encryption software; CloudHSM means AWS provisions the encryption hardware.
• Standard crypto interfaces. Your software talks to the HSM through the CloudHSM client SDK: a PKCS#11 library, a JCE provider for Java, CNG and key storage provider support for Windows, and an OpenSSL engine. Software already written for an on-premises HSM moves with few changes.
• Symmetric and asymmetric keys: AES keys, RSA and ECC key pairs, HMAC keys, signing and hashing, random numbers. KMS also has these key types, but CloudHSM gives you the full set of algorithms and key lengths that its HSMs support, not a predetermined list.
• Billing per HSM per hour, with no upfront cost and no free tier (about 1.60 USD per HSM-hour in us-east-1, more in some Regions; two HSMs for high availability come to well over 2,000 USD a month). KMS has a free tier and costs cents for most workloads.

#Who does what

The most useful picture of CloudHSM is a list of who may touch what.

Three consequences:

• Two separate permission systems. IAM decides who can manage the cluster through the AWS API. HSM users, which exist only inside the HSMs, decide who can use keys. An IAM administrator with full CloudHSM permissions still cannot decrypt anything; but she can delete HSMs, so IAM must be tight too.
• AWS cannot recover your keys. AWS keeps no copy of HSM passwords and has no back door. If you lose every admin and crypto user credential, the keys, and everything encrypted with them, are lost for good. Keep at least two admins, store credentials offline in separate places, and turn on quorum authentication (M of N officers must approve sensitive actions). Admins can also use multi-factor authentication.
• The channel is end-to-end encrypted. The client SDK talks to the HSM over a channel that AWS cannot read (TLS with certificates you control). The HSM’s security group must allow the client on ports 2223 to 2225.

#FIPS 140: what the levels mean and what the exam expects

FIPS 140 is the US government standard for cryptographic modules, checked by accredited labs under NIST’s validation program. It has four security levels; the two that matter here:

• Level 2: tamper evidence (seals that show if someone opened the box) and role-based authentication.
• Level 3: tamper resistance (the module detects an attack and wipes its keys), identity-based authentication, and physical separation of the interfaces that carry keys.

FIPS 140-3 replaced FIPS 140-2 for new validations in 2021; the levels mean much the same.

The facts today:

• CloudHSM: the current HSM type, hsm2m.medium (since 2024), is FIPS 140-3 Level 3 validated. The old hsm1.medium was FIPS 140-2 Level 3; new clusters cannot use it since April 2025, and it reached end of support on 31 March 2026, with existing clusters migrated to hsm2m.medium. A cluster is created in FIPS mode (only FIPS-approved algorithms) or non-FIPS mode (more algorithms, hsm2m.medium only), and the mode cannot be changed later.
• KMS: its HSMs were validated at FIPS 140-2 Level 3 in 2023 and are now FIPS 140-3 Level 3. Before 2023 they were Level 2, which is where the notes’ and many courses’ “KMS = Level 2” comes from.

#High availability: clusters across Availability Zones

An HSM is one device in one Availability Zone. If your only HSM fails, every operation that needs a key fails with it, and the data encrypted under those keys cannot be decrypted until a new HSM is running. CloudHSM is therefore not highly available unless you make it so.

The unit you create is a cluster:

• A cluster holds 1 to 28 HSMs (the default quota is 6 HSMs per account per Region), placed in subnets in different AZs of one Region.
• CloudHSM keeps the HSMs in sync: a key or user created on one HSM is copied to the others automatically. You never copy keys between HSMs yourself.
• The client SDK load-balances across all HSMs and stops using one that fails, so more HSMs also mean more throughput.
• CloudHSM takes encrypted backups of the cluster at least once every 24 hours and stores them for you in the same Region. A backup can only be restored to CloudHSM hardware; AWS cannot read it. You can copy a backup to another Region and create a cluster from it there for disaster recovery.
• When an HSM fails, CloudHSM replaces it, and the new HSM is filled from the cluster (or, if it was the only one, from the latest backup, so keys created after that backup are lost).

For production, AWS recommends at least two HSMs in different AZs, and three or more when the workload cannot tolerate running on a single HSM during a replacement. A cluster can also be reached from other VPCs (for example over VPC peering, lesson 22.1), as long as the network path and the security group allow the client.

#Using AWS services with your HSMs: KMS custom key store

S3, EBS, RDS, DynamoDB, Lambda and the rest integrate with KMS, not with CloudHSM. They have no setting called “use my HSM”. If a rule says the keys that protect your S3 buckets and EBS volumes must live in dedicated hardware, the bridge is a KMS custom key store backed by your CloudHSM cluster (KMS calls it an AWS CloudHSM key store):

1. Prepare the cluster

   An active cluster in the same account and Region, with at least two active HSMs in different AZs. Create a dedicated crypto user named kmsuser in it.

2. Create and connect the key store

   In KMS, create a custom key store that points to the cluster (with the cluster’s trust anchor certificate and the kmsuser password), then connect it. KMS builds the network path to the cluster, logs in as kmsuser and rotates its password.

3. Create KMS keys in it

   Create a symmetric KMS key with the key store as its origin. KMS generates a 256-bit AES key inside your HSMs; it is non-exportable and never leaves them in plain form.

4. Use it like any customer managed key

   Choose that key for S3 default encryption, an EBS volume, an RDS database, a Secrets Manager secret. The service calls KMS as usual; KMS checks the key policy and IAM, then runs the cryptographic operation on your HSMs.

What you get: the integration and the key policy model of KMS, CloudTrail logs of every key use (with the key store ID), and the HSM audit logs on your side. You can disconnect the key store at any time; while it is disconnected nobody can use its keys, which is a kill switch the bank controls.

The limits, which make good exam distractors:

• Symmetric encryption keys only. No asymmetric, HMAC or multi-Region keys in a custom key store, and no imported key material.
• No automatic key rotation. To rotate, create a new KMS key and point the alias to it (KMS keeps decrypting old data with the old key).
• Creating keys needs two active HSMs in different AZs; all other operations work with one. Each cluster can back only one key store, and an account can have up to 10 custom key stores per Region.
• Your availability is now KMS’s availability. If the cluster loses its HSMs, the key store is disconnected or the kmsuser password is changed, every service using those keys stops being able to decrypt.
• Cost: the usual KMS key price (1 USD per key per month plus requests) and the HSM hours.

#CloudHSM with SSE-C and Redshift

The slides add two older integrations:

• S3 SSE-C (lesson 10.8): S3 encrypts with a key you send on every request and forgets it. Your application can keep those keys in CloudHSM. Note the trade-off: to send the key to S3 it must leave the HSM, so this protects the keys at rest but not in use. Today a custom key store with SSE-KMS keeps the key inside the HSM and is the cleaner design.
• Amazon Redshift (lesson 17.2) has an option to keep its cluster encryption key in an HSM. If a question asks which service lets Redshift keep its key in a hardware module you control, the answer is CloudHSM. In new designs, Redshift is usually encrypted with a KMS key, and that key can live in a CloudHSM key store.

#Workloads that use CloudHSM directly

Some software talks to an HSM itself, not to KMS. These are CloudHSM’s home ground:

• SSL/TLS offload. Web servers on EC2 (nginx, Apache with OpenSSL, or IIS on Windows) keep the TLS private key in CloudHSM. The server asks the HSM to perform the private-key step of each handshake; the key never sits on the server’s disk. A stolen disk copy holds only a reference to the key. If your TLS ends on an ALB, CloudFront or API Gateway, you use ACM certificates instead (lesson 21.4).
• Transparent Data Encryption (TDE). Oracle databases and SQL Server keep their TDE master key in CloudHSM (Oracle through PKCS#11, SQL Server through CNG). This applies to databases you run on EC2; RDS has its own TDE options (lesson 7.4).
• Your own certificate authority. The private key that signs every certificate your CA issues is the most valuable key you own; it lives in the HSM, and signing happens there.
• Signing and verification: code signing, document signing, payment message authentication with HMACs.
• Custom applications written against PKCS#11, JCE or CNG, often moved from an on-premises HSM.

#CloudHSM vs KMS

Try the decision yourself: tick a workload’s requirements and see which option wins, which requirement decided it, and which requirements clash.

#What goes wrong

• A single HSM fails. Every operation stops until a replacement runs, and keys created since the last backup are lost. Run two or more HSMs in different AZs.
• Lost HSM credentials. AWS cannot reset them or recover keys. Keep at least two admins, store credentials offline, and use quorum authentication.
• Client cannot connect. The cluster’s security group does not allow ports 2223 to 2225 from the client, the client is in a VPC with no route to the HSM subnets, or the client SDK version is too old for hsm2m.medium (Client SDK 5 is required).
• Custom key store cannot create keys. Fewer than two active HSMs in different AZs, or the store is disconnected.
• Everything under a custom key store fails to decrypt. The store was disconnected, the cluster has no active HSM, or someone changed the kmsuser password. Monitor the connection state and keep kmsuser for KMS only.
• Someone expects automatic rotation or multi-Region keys in a custom key store. Neither is supported; plan manual rotation and one key store per Region.
• An IAM user deletes the cluster. IAM permissions on the CloudHSM API can destroy the infrastructure even though they cannot use keys. Restrict them, and keep backups (copied to another Region for DR).
• A wrong cluster mode. A cluster created in FIPS mode cannot use non-FIPS algorithms, and the mode cannot be changed; backups only restore to a cluster of the same mode.
• A large surprise bill. HSMs bill every hour they exist, used or not. Delete test HSMs, and choose KMS when nothing requires dedicated hardware.

#CloudHSM in system design

• Regulated core systems: a bank, a payment switch or a government ID system that must hold keys in dedicated hardware uses a three-AZ cluster, a custom key store for AWS services, and direct PKCS#11 or JCE access for its own payment and signing software.
• Private PKI: the root or issuing CA keys of an internal certificate authority stay in CloudHSM. For a managed private CA without running HSMs yourself, AWS Private CA is the alternative (lesson 21.4).
• Migration from on premises: an application that already talks PKCS#11 to an on-premises HSM moves to EC2 and talks to CloudHSM with few code changes.
• Defence in depth with KMS: most data uses ordinary KMS keys; only the systems a regulator names use the custom key store. This keeps the bill and the operational load small.

#Try it yourself

CloudHSM costs real money per HSM-hour, so delete everything at the end. These commands use the AWS CLI v2 and the CloudHSM CLI from Client SDK 5. Passwords are placeholders: never put real ones in scripts.

# 1. Create a cluster in FIPS mode across two private subnets in different AZs
aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium --mode FIPS \
  --subnet-ids subnet-0a1b2c3d4e5f60001 subnet-0a1b2c3d4e5f60002
# { "Cluster": { "ClusterId": "cluster-1a23b4cdefg", "State": "CREATE_IN_PROGRESS", "HsmType": "hsm2m.medium", "Mode": "FIPS", ... } }

# 2. Add the first HSM, then read the cluster's certificate signing request
aws cloudhsmv2 create-hsm --cluster-id cluster-1a23b4cdefg --availability-zone ap-southeast-1a
aws cloudhsmv2 describe-clusters --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Clusters[0].[State,Certificates.ClusterCsr]' --output text > cluster.csr
# UNINITIALIZED  -----BEGIN CERTIFICATE REQUEST----- ...

# 3. Sign it with your own CA (openssl here), then initialize the cluster
openssl x509 -req -days 3652 -in cluster.csr -CA customerCA.crt -CAkey customerCA.key \
  -CAcreateserial -out cluster.crt
aws cloudhsmv2 initialize-cluster --cluster-id cluster-1a23b4cdefg \
  --signed-cert file://cluster.crt --trust-anchor file://customerCA.crt

# 4. On an EC2 client with Client SDK 5: activate the cluster and create users
sudo /opt/cloudhsm/bin/configure-cli -a 10.0.1.25        # the HSM's private IP
/opt/cloudhsm/bin/cloudhsm-cli interactive
#   aws-cloudhsm > cluster activate                         (set the admin password)
#   aws-cloudhsm > login --username admin --role admin
#   aws-cloudhsm > user create --username kmsuser --role crypto-user
#   aws-cloudhsm > user create --username payments --role crypto-user

# 5. Add a second HSM in another AZ (needed for HA and for a custom key store)
aws cloudhsmv2 create-hsm --cluster-id cluster-1a23b4cdefg --availability-zone ap-southeast-1b
aws cloudhsmv2 describe-clusters --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Clusters[0].Hsms[].[HsmId,AvailabilityZone,State]' --output table
# |  hsm-111aaa222bbb  |  ap-southeast-1a  |  ACTIVE  |
# |  hsm-333ccc444ddd  |  ap-southeast-1b  |  ACTIVE  |

# 6. Create and connect a KMS custom key store on the cluster
aws kms create-custom-key-store --custom-key-store-name bank-hsm-store \
  --cloud-hsm-cluster-id cluster-1a23b4cdefg \
  --trust-anchor-certificate file://customerCA.crt \
  --key-store-password '<kmsuser-password>'
# { "CustomKeyStoreId": "cks-1234567890abcdef0" }
aws kms connect-custom-key-store --custom-key-store-id cks-1234567890abcdef0
aws kms describe-custom-key-stores --custom-key-store-id cks-1234567890abcdef0 \
  --query 'CustomKeyStores[0].ConnectionState'
# "CONNECTED"

# 7. Create a KMS key whose material lives in your HSMs, and use it with S3
aws kms create-key --origin AWS_CLOUDHSM --custom-key-store-id cks-1234567890abcdef0 \
  --description "loan documents" --query 'KeyMetadata.[KeyId,Origin]'
# [ "1234abcd-12ab-34cd-56ef-1234567890ab", "AWS_CLOUDHSM" ]
aws s3 cp loan-2026-0042.pdf s3://bank-loans-example/ --sse aws:kms \
  --sse-kms-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 8. Copy the latest backup to another Region for DR
aws cloudhsmv2 describe-backups --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Backups[-1].BackupId' --output text
# backup-abcdefghijk
aws cloudhsmv2 copy-backup-to-region --destination-region ap-south-1 --backup-id backup-abcdefghijk

# 9. Clean up (keys in the store first, then the store, the HSMs and the cluster)
aws kms schedule-key-deletion --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --pending-window-in-days 7
aws kms disconnect-custom-key-store --custom-key-store-id cks-1234567890abcdef0
aws cloudhsmv2 delete-hsm --cluster-id cluster-1a23b4cdefg --hsm-id hsm-333ccc444ddd
aws cloudhsmv2 delete-hsm --cluster-id cluster-1a23b4cdefg --hsm-id hsm-111aaa222bbb
aws cloudhsmv2 delete-cluster --cluster-id cluster-1a23b4cdefg

Also try in the console: open the CloudWatch Logs group of the cluster and look at the HSM audit log entries for your logins and key creation, then find the same key’s KMS calls in CloudTrail. The custom key store can only be deleted after its keys are gone (after the waiting period).

#Summary

Key takeaways

• CloudHSM = dedicated, single-tenant HSMs in your VPC. AWS manages the hardware; you alone manage users and keys. AWS cannot use your keys, and cannot recover them if you lose your credentials.
• IAM manages the cluster (API); HSM users (admin, crypto user) control the keys. Logs: CloudTrail for API calls, HSM audit logs in CloudWatch Logs.
• FIPS: CloudHSM hsm2m.medium is FIPS 140-3 Level 3; KMS is also Level 3 now (Level 2 before 2023). Old questions may still say “KMS = Level 2”; prefer the discriminators single-tenant, exclusive control, PKCS#11/JCE/CNG, SSL/TLS offload, TDE.
• High availability: a cluster of HSMs in multiple AZs, kept in sync automatically and load-balanced by the client SDK; one HSM is a single point of failure. Backups at least daily, copyable to another Region.
• AWS services use CloudHSM only through a KMS custom key store (symmetric keys only, no automatic rotation, no multi-Region keys, two active HSMs in different AZs to create keys). Keys outside AWS altogether → external key store (XKS).
• KMS: multi-tenant, integrated with almost every service, automatic rotation, free tier, cheap. CloudHSM: per HSM-hour, no free tier, you run it.

Self-check: CloudHSM vs KMS30 questions