AWS CloudHSM
A service that provides dedicated FIPS 140-2 Level 3 certified hardware security modules for generating, storing, and performing cryptographic operations with encryption keys in the cloud
Overview
AWS CloudHSM provides dedicated hardware security modules (HSMs) in the cloud. It deploys FIPS 140-2 Level 3 certified Cavium/Marvell HSM appliances within your VPC, enabling key generation, storage, signing, and encryption/decryption entirely within the hardware. Key material cannot be extracted from the tamper-resistant HSM hardware, and no one - including AWS - can access it. It supports standard interfaces including PKCS#11, JCE (Java Cryptography Extension), and Microsoft CNG, allowing integration with existing application code with minimal changes.
Fundamental Differences from KMS and Selection Criteria
CloudHSM and KMS can both manage encryption keys, but they differ fundamentally in their control model and compliance requirements. KMS operates on a multi-tenant shared HSM infrastructure where AWS manages the key lifecycle on your behalf. Its API is AWS-proprietary, and encryption/decryption/signing operations are performed through the KMS API. At roughly 1 USD per key per month plus API call charges, KMS is sufficient for the majority of workloads. CloudHSM provides single-tenant dedicated HSMs where all key management responsibility lies with the user. AWS handles only the hardware operations and has zero access to key material. Because it uses industry-standard interfaces like PKCS#11 and JCE, migration from on-premises HSMs is straightforward. You should choose CloudHSM when regulations explicitly require FIPS 140-2 Level 3, when you need complete exclusive control over keys, when migrating existing applications that use PKCS#11 or JCE, or when performing SSL/TLS offloading on HSMs. In all other cases, KMS is the more rational choice in terms of both operational overhead and cost.
Cluster Architecture and High Availability Design
CloudHSM is managed at the cluster level, with up to 28 HSMs per cluster. For high availability, place at least one HSM in each of at least two Availability Zones. HSMs within a cluster automatically synchronize keys, so if one HSM fails, others continue processing. The client SDK distributes requests across HSMs in a round-robin fashion and automatically fails over to healthy HSMs upon detecting a failure. During initial setup, securely storing the Crypto Officer (CO) credentials generated at cluster initialization is critically important. If these credentials are lost, there is no way to access the keys inside the HSM. AWS does not retain these credentials, making recovery impossible. Backups are automatically taken by CloudHSM and stored encrypted in S3. Restoration can be performed to a new cluster within the same region, but since backup encryption keys are cluster-specific, you cannot restore one cluster's backup to a different cluster. Pricing is approximately 1.60 USD per HSM per hour (roughly 1,150 USD/month), so even a minimum two-HSM configuration costs about 2,300 USD per month.
SSL/TLS Offloading and Database Encryption Implementation
One of CloudHSM's most common use cases is SSL/TLS offloading. You store the web server's (Nginx, Apache) private key in CloudHSM and execute TLS handshake signing operations within the HSM. Since the private key never exists in the server's memory or on disk, it cannot be leaked even if the server is compromised. Integration with web servers is achieved through the OpenSSL engine or PKCS#11 provider. Patterns for managing database encryption keys with CloudHSM are also used in practice, including Oracle TDE (Transparent Data Encryption) and Microsoft SQL Server's EKM (Extensible Key Management). With Oracle TDE, the master encryption key is stored in CloudHSM while tablespace encryption keys are encrypted with the master key and stored within the database. This means that even if a database backup is leaked, the data cannot be decrypted without the master key in CloudHSM. For a systematic study of encryption and key management, books on the topic (Amazon) are a great resource. Using KMS's custom key store feature, you can maintain the convenience of the KMS API while storing keys in CloudHSM. When you call encrypt/decrypt through the KMS API, CloudHSM performs the cryptographic operations behind the scenes, combining KMS's ease of use with CloudHSM's security level.