AWS CloudHSM

• AWS CloudHSM is a cloud-based hardware security module (HSM) that provides secure cryptographic key storage and enables you to easily generate and use your own encryption keys on the AWS Cloud.
• CloudHSM helps manage your own encryption keys using FIPS 140-2 Level 3 validated HSMs (hsm1.medium) or FIPS 140-3 Level 3 validated HSMs (hsm2m.medium).
• AWS CloudHSM helps meet corporate, contractual and regulatory compliance requirements for data security by using dedicated HSM appliances within the AWS cloud.
• A hardware security module (HSM)
  • is a hardware appliance that provides secure key storage and cryptographic operations within a tamper-resistant hardware module.
  • are designed with physical and logical mechanisms, to securely store cryptographic key material and use the key material without exposing it outside the cryptographic boundary of the appliance.
  • physical protections include tamper detection and tamper response. When a tampering event is detected, the HSM is designed to securely destroy the keys rather than risk compromise.
  • logical protections include role-based access controls that provide separation of duties
• CloudHSM allows encryption key protection within HSMs, designed and validated to government standards for secure key management.
• CloudHSM helps comply with strict key management requirements within the AWS cloud without sacrificing application performance
• HSMs are located in AWS data centres, managed and monitored by AWS, but AWS does not have access to the keys.
• CloudHSM makes periodic backups of the users, keys, and policies in the cluster.
• CloudHSM is a fully-managed service that automates time-consuming administrative tasks, such as hardware provisioning, software patching, high availability, and backups.
• CloudHSM also enables you to scale quickly by adding and removing HSM capacity on-demand, with no up-front costs.
• CloudHSM automatically load balances requests and securely duplicates keys stored in any HSM to all of the other HSMs in the cluster.
• Only you have access to the keys and operations to generate, store and manage the keys.
• AWS can’t help recover the key material if the credentials are lost
• CloudHSM provides single tenant dedicated access to each HSM appliance
• HSMs are inside your VPC and isolated from the rest of the network
• Placing HSM appliances near the EC2 instances decreases network latency, which can improve application performance
• Integrated with Amazon Redshift and Amazon RDS for Oracle
• Integrated with AWS KMS through Custom Key Store feature, enabling KMS keys backed by CloudHSM hardware
• Other use cases like EBS volume encryption and S3 object encryption and key management can be handled by writing custom applications and integrating them with CloudHSM
• CloudHSM can perform a variety of cryptographic tasks:
  • Generate, store, import, export, and manage cryptographic keys, including symmetric keys and asymmetric key pairs.
  • Use symmetric and asymmetric algorithms to encrypt and decrypt data.
  • Use cryptographic hash functions to compute message digests and hash-based message authentication codes (HMACs).
  • Cryptographically sign data (including code signing) and verify signatures.
  • Generate cryptographically secure random data.
• CloudHSM supports standard cryptographic APIs including PKCS#11, Java JCE (Java Cryptography Extensions), OpenSSL Dynamic Engine, and Microsoft KSP/CNG.

CloudHSM HSM Instance Types

• hsm1.medium (Legacy)
  • Original CloudHSM instance type
  • FIPS 140-2 Level 3 validated
  • Maximum key storage: 3,300 keys
  • End-of-support: March 31, 2026
  • New cluster creation disabled since April 2025
• hsm2m.medium (Current)
  • Launched August 20, 2024 (GA)
  • FIPS 140-3 Level 3 validated
  • Increased key storage: 16,666 total keys (asymmetric keys max 3,333 per cluster)
  • Supports both FIPS mode and non-FIPS mode clusters
  • Supports mutual TLS (mTLS) between client SDK and CloudHSM
  • Higher elliptic curve performance
  • Compatible with backups from hsm1.medium clusters
  • Requires Client SDK 5.9.0 or later

CloudHSM Cluster Modes

• FIPS Mode (default)
  • Enforces FIPS 140-3 approved algorithms only
  • Required for PCI-PIN, PCI-3DS, PCI-DSS, and SOC2 compliance
  • Triple DES (3DES) key generation and encryption disallowed since January 1, 2024
  • RSA key wrap/unwrap with PKCS#1 v1.5 padding disallowed since January 1, 2024
• Non-FIPS Mode (new with hsm2m.medium)
  • Supports all keys and algorithms available in CloudHSM regardless of FIPS approval
  • Allows continued use of 3DES and other non-FIPS approved algorithms
  • Suitable for workloads that don’t require FIPS compliance

CloudHSM Use Cases

• Offload SSL/TLS processing for the web servers.
• Store the Transparent Data Encryption (TDE) master encryption key for Oracle database servers that support TDE.
• Store private keys and sign certificate requests acting as an issuing CA to issue certificates for your organization (PKI).
• Database encryption for sensitive data at rest.
• Digital Rights Management (DRM).
• Authentication and authorization.
• Document signing and code signing.
• Transaction processing.
• Custom key store for AWS KMS (KMS keys backed by CloudHSM hardware).

CloudHSM Clusters

• CloudHSM Cluster is a collection of individual HSMs kept in sync.
• HSMs can be placed in different AZs to provide high availability. Spreading clusters across AZs provides redundancy and high availability.
• Cluster can be added with more HSMs for scalability and performance.
• Cluster with more than one HSM is automatically load balanced.
• CloudHSM helps keep the cluster synchronized, redundant, and highly available.
• A single CloudHSM Cluster can contain up to 28 HSMs.
• AWS strongly recommends at least two HSMs in two different AZs for production workloads.
• For mission-critical workloads, at least three HSMs in at least two separate AZs are recommended.
• CloudHSM makes automatic encrypted backups daily and during cluster lifecycle events.
• Backups can be copied across regions for disaster recovery.

CloudHSM Multi-Cluster Configuration

• Client SDK 5 supports multi-cluster configuration, allowing a single client instance to communicate with multiple CloudHSM clusters.
• Supported for CloudHSM CLI, JCE, and PKCS#11 libraries.
• Enables blue/green deployment strategies for migrations.
• Supports key replication between cloned clusters using the key replicate command.
• Enables cross-region disaster recovery by cloning clusters from backups.
• Cost-saving feature for workloads that can share a client instance across clusters.

HSM Instance Type Migration (hsm1 → hsm2)

• Timeline:
  • April 2025: New hsm1.medium cluster creation disabled
  • January 2026: Automatic migration of existing hsm1 clusters to hsm2m.medium began
  • March 31, 2026: hsm1.medium end-of-support
• Migration Options:
  • Customer-triggered migration: Trigger via Console or CLI; AWS manages the process. Cluster enters limited-write mode during migration. Rollback available within 24 hours.
  • Customer-managed migration: Create new hsm2 cluster from hsm1 backup, reconfigure client SDKs, redirect applications. Supports blue/green deployment strategy.
  • Automatic migration: AWS automatically migrates remaining hsm1 clusters starting January 2026.
• Prerequisites:
  • Upgrade to Client SDK version 5.9.0 or later
  • Ensure no deprecated algorithms (3DES in FIPS mode) are in use
  • Verify cluster meets migration validation checks

CloudHSM Client SDK

• Client SDK 5 is the current and primary SDK with active feature development.
• Client SDK 3 reached end-of-support; documentation for versions 3.4.4 and earlier unavailable after March 31, 2025.
• Client SDK 5 features:
  • Multi-cluster configuration support
  • Key availability quorum (keys must exist on 2 HSMs before use)
  • Fully automatic key synchronization
  • Key replication between cloned clusters
  • mTLS support (with hsm2m.medium)
  • OpenSSL Provider support (added in v5.17.0, January 2026)
• Latest version: 5.17.1 (March 2026)
• SDK version support policy: Up to 3 prior minor versions and one year from release date.

CloudHSM Custom Key Store for AWS KMS

• AWS KMS can be configured with a CloudHSM Custom Key Store, where KMS keys are generated and stored in your CloudHSM cluster.
• Combines the convenience and AWS service integration of KMS with the added control of single-tenant HSMs.
• When using a KMS key in a CloudHSM key store, cryptographic operations are performed in the HSMs in your cluster.
• Key material never leaves the HSMs unencrypted.
• Enables AWS services that integrate with KMS (S3, EBS, RDS, etc.) to benefit from CloudHSM hardware security.
• Note: mTLS is not supported for CloudHSM key stores used with KMS.

CloudHSM vs KMS

AWS Payment Cryptography

• For payment-specific cryptographic operations (PIN generation/validation, card security codes), AWS launched AWS Payment Cryptography (June 2023) as a managed alternative to on-premises payment HSMs.
• CloudHSM provides general-purpose HSMs; AWS Payment Cryptography is purpose-built for payment processing use cases.
• AWS Payment Cryptography is designed to meet PCI-PIN, PCI-P2PE, and PCI-DSS compliance requirements.
• Fully managed, elastic, pay-as-you-go service with no HSM provisioning required.

FIPS 140 Compliance Updates

• FIPS 140-3 Level 3: hsm2m.medium instances are validated under the newer FIPS 140-3 standard (supersedes FIPS 140-2).
• 2024 Mechanism Deprecation (FIPS mode only):
  • Triple DES (3DES) key generation and encryption: disallowed since January 1, 2024
  • RSA key wrap/unwrap/encrypt/decrypt with PKCS#1 v1.5 padding: disallowed since January 1, 2024
  • These operations remain available in non-FIPS mode clusters
• CloudHSM meets PCI-DSS, PCI-PIN, PCI-3DS, and SOC2 compliance requirements.

AWS Certification Exam Practice Questions

• • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

1. With which AWS services CloudHSM can be used (select 2)
   1. S3
   2. DynamoDb
   3. RDS
   4. ElastiCache
   5. Amazon Redshift
2. An AWS customer is deploying a web application that is composed of a front-end running on Amazon EC2 and of confidential data that is stored on Amazon S3. The customer security policy that all access operations to this sensitive data must be authenticated and authorized by a centralized access management system that is operated by a separate security team. In addition, the web application team that owns and administers the EC2 web front-end instances is prohibited from having any ability to access the data that circumvents this centralized access management system. Which of the following configurations will support these requirements:
   1. Encrypt the data on Amazon S3 using a CloudHSM that is operated by the separate security team. Configure the web application to integrate with the CloudHSM for decrypting approved data access operations for trusted end-users. (S3 doesn’t integrate directly with CloudHSM, also there is no centralized access management system control)
   2. Configure the web application to authenticate end-users against the centralized access management system. Have the web application provision trusted users STS tokens entitling the download of approved data directly from Amazon S3 (Controlled access and admins cannot access the data as it needs authentication)
   3. Have the separate security team create and IAM role that is entitled to access the data on Amazon S3. Have the web application team provision their instances with this role while denying their IAM users access to the data on Amazon S3 (Web team would have access to the data)
   4. Configure the web application to authenticate end-users against the centralized access management system using SAML. Have the end-users authenticate to IAM using their SAML token and download the approved data directly from S3. (not the way SAML auth works and not sure if the centralized access management system is SAML complaint)
3. A company requires FIPS 140-3 Level 3 compliance for its cryptographic key management. Which AWS CloudHSM instance type should they use?
   1. hsm1.medium
   2. hsm2m.medium
   3. Any CloudHSM instance type
   4. AWS KMS with custom key store
4. A company is using AWS CloudHSM with hsm1.medium instances. They need to continue using Triple DES (3DES) encryption. What is the recommended approach?
   1. Continue using hsm1.medium in FIPS mode
   2. Migrate to hsm2m.medium in non-FIPS mode
   3. Use AWS KMS instead
   4. 3DES is still supported in all CloudHSM modes
5. A company wants to use AWS KMS for service integration while maintaining full control of HSM hardware. Which approach should they use?
   1. Use AWS KMS with AWS managed keys
   2. Use CloudHSM directly with each AWS service
   3. Configure AWS KMS with a CloudHSM Custom Key Store
   4. Use AWS Payment Cryptography
6. What is the maximum number of keys that can be stored in an hsm2m.medium CloudHSM cluster?
   1. 3,300 keys
   2. 10,000 keys
   3. 16,666 keys
   4. Unlimited keys
7. Which feature is unique to hsm2m.medium and NOT available on hsm1.medium? (Select 2)
   1. FIPS 140-2 Level 3 validation
   2. Non-FIPS mode clusters
   3. Cross-region backup copying
   4. Mutual TLS (mTLS) between client and CloudHSM
   5. Multi-AZ high availability

• References
• AWS CloudHSM User Guide
• CloudHSM HSM Types
• CloudHSM Deprecation Notifications
• Migrating from hsm1 to hsm2
• AWS KMS Custom Key Store (CloudHSM)
• CloudHSM FIPS Validation
• AWS CloudHSM FAQs