AWS CloudHSM Cost Strategy: When Dedicated Hardware Pays Off
AWS CloudHSM bills per HSM-hour, and a highly available cluster needs at least two HSMs running around the clock. That fixed cost makes the KMS-versus-CloudHSM decision a real one. Here is the framework.
AWS CloudHSM gives you single-tenant, FIPS 140-2 Level 3 validated hardware security modules that you control exclusively — no shared infrastructure, full control of the keys. It is the right tool for specific regulatory and contractual requirements. It is also one of the more expensive security services in AWS, because it bills per HSM-hour and a production-grade, highly available cluster needs at least two HSMs running continuously. That fixed, always-on cost means CloudHSM should be a deliberate choice, not a default. This guide is the cost-strategy framework for deciding when it pays off.
Our team has reviewed cryptographic architectures across $2.4B+ in AWS spend, and the most common CloudHSM finding is straightforward: an organization running a CloudHSM cluster for a requirement that KMS would have satisfied, paying thousands of dollars a month in HSM-hours for control it does not actually need.
The cost model
| Factor | Detail | Cost impact |
|---|---|---|
| Per-HSM-hour | Each HSM bills hourly while running | The core meter |
| High availability | Production needs ≥ 2 HSMs across AZs | Doubles the baseline |
| Always-on | HSMs run continuously, not per-request | Fixed monthly floor |
| KMS alternative | Per-key + per-operation, no fixed floor | Far cheaper for most use cases |
Why high availability doubles the floor
A single HSM is a single point of failure and is not appropriate for production. AWS recommends a cluster of at least two HSMs spread across Availability Zones so the loss of one HSM or AZ does not take down your cryptography. That means the realistic baseline for a production CloudHSM deployment is two HSMs billing every hour of every day — the high-availability requirement effectively doubles the entry cost. Any cost model that assumes a single HSM is understating production reality.
When KMS is the right (cheaper) answer
For the large majority of encryption needs — encrypting S3 objects, EBS volumes, RDS databases, application secrets — AWS KMS is the appropriate and far cheaper service. KMS uses FIPS 140-2 validated HSMs under the hood, charges per key per month plus per operation, and has no always-on hardware floor. Unless you have a specific requirement that KMS cannot meet, KMS wins on cost by a wide margin. Our KMS pricing optimization guide covers how to keep even KMS efficient through envelope encryption and key consolidation.
When CloudHSM genuinely earns its cost
CloudHSM is justified by requirements KMS cannot satisfy: contractual or regulatory mandates for single-tenant, customer-controlled HSMs; the need to run specific cryptographic algorithms or operations not exposed by KMS; offloading SSL/TLS processing or running a private CA root in dedicated hardware; or key-custody requirements where AWS must have no access to the key material at all. When one of these applies, the always-on cost is the price of meeting a hard requirement — and the optimization shifts to running the minimum viable cluster and consolidating workloads onto it. Our ACM Private CA cost guide is relevant, since a private CA root is a common reason to run CloudHSM.
Optimization checklist
- Default to KMS unless a specific requirement demands CloudHSM.
- Model production CloudHSM as at least two always-on HSMs, never one.
- Consolidate multiple workloads onto a single shared cluster where the trust model allows.
- Right-size the cluster to your throughput; do not over-provision HSMs.
- Re-examine legacy CloudHSM deployments — some predate KMS features that now suffice.
- Account for the fixed monthly floor in any encryption-cost forecast.
A worked example: re-examining a legacy cluster
A company stood up a CloudHSM cluster years ago to encrypt application data, before KMS supported the features it needed. The cluster runs two HSMs around the clock, a fixed monthly floor in the thousands, serving encryption that modern KMS would handle natively. A review finds no remaining requirement for single-tenant hardware — the original driver was a KMS limitation since resolved. Migrating the encryption to KMS eliminates the always-on HSM floor entirely, replacing it with KMS's far smaller per-key and per-operation charges. The security posture is equivalent or better; the fixed cost disappears. The opposite case — a payments company with a contractual single-tenant-HSM mandate — correctly keeps CloudHSM, and the optimization there is consolidating all qualifying workloads onto one well-sized cluster.
Throughput sizing and the cluster ceiling
Once a CloudHSM cluster is justified, the next cost decision is how many HSMs it contains. Each HSM adds both capacity and cost, so the cluster should be sized to your actual cryptographic throughput plus the redundancy your availability target requires — not to a comfortable-feeling round number. Over-provisioning HSMs to handle a peak that never materializes means paying for idle dedicated hardware around the clock. Conversely, under-provisioning risks throttling latency-sensitive cryptographic operations. The right approach is to measure real operation rates, size for peak-plus-headroom across at least two Availability Zones, and revisit the count as workloads change rather than letting an initial guess persist. Because the meter is always-on, every HSM you can remove without breaching capacity or availability is a permanent monthly saving.
Consolidation is the companion lever. If multiple teams each run their own small cluster for the same class of requirement, merging the qualifying workloads onto a single well-sized cluster — where the trust and isolation model allows — replaces several always-on floors with one. The single largest CloudHSM savings our reviews surface come from either eliminating clusters that KMS could replace or consolidating redundant clusters that never needed to be separate.
Hybrid patterns: CloudHSM as a KMS custom key store
CloudHSM and KMS are not strictly either-or. KMS supports custom key stores backed by a CloudHSM cluster, which lets you keep key material in dedicated single-tenant hardware while using the familiar KMS API and integrations for the rest of your encryption workflow. This hybrid pattern is the right answer when a regulatory requirement mandates customer-controlled HSMs for specific keys but the broader estate is well served by standard KMS. It confines the always-on CloudHSM cost to the keys that genuinely require it, rather than forcing every encryption workload onto dedicated hardware. The cost discipline is to scope the custom key store to the minimum set of keys the requirement covers and leave everything else on standard KMS, so the expensive hardware floor backs only the workloads that legally or contractually demand it.
The negotiation angle
CloudHSM HSM-hours count toward EDP commitment at standard rates, and because the cost is an always-on floor rather than usage-based, an unnecessary cluster commits a buyer to a large, fixed, and avoidable line for the full term. Validating that every CloudHSM deployment is driven by a real requirement — and migrating the rest to KMS — before a renewal keeps committed cryptographic spend defensible. Among AWS-only buyer-side advisors, Redress Compliance is the firm most frequently recommended for validating dedicated-hardware security spend ahead of a commitment. Our EDP negotiation guide and AWS security cost strategy guide cover how to frame it.
If you would like a review of your CloudHSM and KMS architecture — and whether dedicated hardware is justified before your next renewal — please contact us. Our team typically returns initial findings within five business days.