AWS CloudHSM FAQs

You will be charged an hourly fee for each hour (or partial hour) that an HSM is provisioned to an AWS CloudHSM cluster. A cluster with no HSMs in it is not billed, nor are you billed for our automatic storage of encrypted backups. For more information, please visit the AMS CloudHSM pricing page. Note that network data transfers to and from your HSMs are charged separately. For more information please review data transfer pricing for EC2.

No, there is no free tier available for AWS CloudHSM.

No, the hourly fee, which varies by region, does not depend on how much you use your HSM.

No, we do not offer reserved instance pricing for AWS CloudHSM.

Yes. To start using AWS CloudHSM, a few prerequisites are needed, including a Virtual Private Cloud (VPC) in the region where you want the AWS CloudHSM service. Refer to the AWS CloudHSM User Guide for more details.

No. AWS manages the firmware on the hardware. Firmware is maintained by a third-party, and every firmware must be evaluated by NIST for FIPS 140-2 Level 3 compliance. Only firmware that has been cryptographically signed by the FIPS key (which AWS does not have access to) can be installed.

AWS strongly recommends that you use at least two HSMs in two different Availability Zones for any production workload. For mission-critical workloads, we recommend at least three HSMs in at least two separate AZs. The CloudHSM client will automatically handle any HSM failures and load balance across two or more HSMs transparently to your application.

AWS takes automatic encrypted backups of your CloudHSM Cluster on a daily basis. AWS takes additional backups when cluster lifecycle events occur (such as adding or removing an HSM).For the 24-hour period between backups, you are solely responsible for the durability of key material created or imported to your cluster. We strongly recommend ensuring that any keys created are synchronized to at least two HSMs in two different Availability Zones to ensure the durability of your keys. See the AWS CloudHSM User Guide for more detail on verifying key synchronization.

High availability is provided automatically when you have at least two HSMs spread across two Availability Zones in your CloudHSM Cluster. No additional configuration is required. In the event an HSM in your cluster fails, it will be replaced automatically, and all clients will be updated to reflect the new configuration without interrupting any processing. Additional HSMs can be added to the cluster via the AWS API or SDK, increasing availability without interrupting your application.

A single CloudHSM Cluster can contain up to 28 HSMs, subject to account service limits. Learn more about service limits and how to request a limit increase in our online documentation.

Your CloudHSM Cluster is backed up on a daily basis by AWS. Keys can also be exported (“wrapped”) out of your cluster and stored on-premises as long as they were not generated as “non-exportable."

Yes, you can find the service level agreement (SLA) for AWS CloudHSM here.

No. As part of the service you receive single-tenant access to the HSM. Underlying hardware may be shared with other customers, but the HSM is accessible only to you.

Separation of duties and role-based access control is inherent in the design of AWS CloudHSM. AWS has a limited credential to the HSM that permits us to monitor and maintain the health and availability of the HSM, take encrypted backups, and to extract and publish audit logs to your CloudWatch Logs AWS has no access to any keys or data inside your CloudHSM Cluster and cannot perform any operations other than those allowed for an HSM appliance user.

Please see the AWS CloudHSM User Guide for more information on the separation of duties, and the capabilities each class of user has on the HSM.

Yes. AWS CloudHSM publishes multiple Amazon CloudWatch metrics for CloudHSM Clusters and for individual HSMs. You can use the Amazon CloudWatch console, API or SDK to obtain and alarm on these metrics.

Each HSM has a FIPS-validated Deterministic Random Bit Generator (DRBG) that is seeded by a True Random Number Generator (TRNG) within the HSM hardware module that conforms to SP800-90B.

AWS CloudHSM has both physical and logical tamper detection and response mechanisms that trigger key deletion (zeroization) of the hardware. The hardware is designed to detect tampering if its physical barrier is breached. HSMs are also protected against brute-force login attacks. After a fixed number of unsuccessful attempts to access an HSM with admin or crypto officer (CO) credentials, the HSM will lock the admin/CO out. Similarly, after a fixed number of unsuccessful attempts to access an HSM with crypto user (CU) credentials, the user will be locked out and must be unlocked by a CO or admin.

Amazon monitors and maintains the HSM and network for availability and error conditions. If an HSM fails or loses network connectivity, the HSM will be automatically replaced. You can check the health of an individual HSM using theAWS CloudHSM's APIs, SDKs, or CLI Tools, and you can check the overall health of the service at any time using the AWS Service Health Dashboard.

If your AWS CloudHSM Cluster only has a single HSM, yes it is possible to lose keys that were created since the most recent daily backup. AWS CloudHSM Clusters with two or more HSMs, ideally in separate Availability Zones, will not lose keys if a single HSM fails. See our best practices for more information.

No. Amazon does not have access to your keys or credentials and therefore has no way to recover your keys if you lose your credentials.

AWS CloudHSM is built on hardware that is validated at Federal Information Processing Standard (FIPS) 140-2 Level 3. You can find information about the FIPS 140-2 Security Profile for the hardware used by CloudHSM, and the firmware it runs, at our compliance page.

Yes, CloudHSM provides FIPS 140-2 Level 3 validated HSMs. You can follow the procedure in the CloudHSM User Guide under Verify the Authenticity of Your HSM to confirm that you have an authentic HSM on the same model hardware specified in the NIST Security Policy described in the previous question.

AWS CloudHSM is always in FIPS 140-2 mode. This can be verified by using the CLI tools as documented in the CloudHSM User Guide and running the getHsmInfo command, which will indicate the FIPS mode status.

Yes. AWS CloudTrail records AWS API calls for your account. The AWS API call history produced by AWS CloudTrail lets you perform security analysis, resource change tracking, and compliance auditing. Learn more about AWS CloudTrail at the CloudTrail home page, and turn it on through CloudTrail's AWS Management Console.

AWS CloudTrail does not include any of the HSM device or access logs. These are provided directly to your AWS account via AWS CloudWatch Logs. See the AWS CloudHSM User Guide for more details.

Please refer to the AWS Compliance site for more information about which compliance programs cover CloudHSM. Unlike other AWS services, compliance requirements regarding AWS CloudHSM are often met directly by the FIPS 140-2 Level 3 validation of the hardware itself, rather than as part of a separate audit program.

FIPS 140-2 Level 3 is a requirement of certain use cases, including document signing, payments, or operating as a public Certificate Authority for SSL certificates.

To see what compliance reports are in scope for AWS CloudHSM, review the data on AWS Services in Scope by Compliance Program. To create free, self-service, on-demand compliance reports, use AWS Artifact.

If you’re only interested in the FIPS validation for HSMs provided by AWS CloudHSM, see FIPS Validation.

Performance can vary based on configuration, data size, and additional application load on your EC2 instances. To increase performance, you can add additional HSM instances to your clusters. We encourage load testing your application to determine scaling needs.

For more details, refer to the performance page in the AWS CloudHSM user guide.

For details on key storage and cluster capacity, see AWS CloudHSM quotas.

Not directly. You should use AWS Key Management Service with Custom Key Store to secure Amazon RDS data using keys generated and stored in your CloudHSM Cluster.

Several third-party vendors support AWS CloudHSM as a root of trust. This means that you can utilize a software solution of your choice while creating and storing the underlying keys in your CloudHSM Cluster.

The AWS CloudHSM Client Library is a software package supplied by AWS that allows you and your applications to interact with CloudHSM Clusters.

No. All communication between the client and your HSM is encrypted end to end. AWS cannot see or intercept this communication, and has no visibility into your cluster access credentials.

You’ll find instructions in the CloudHSM User Guide.

No. The CloudHSM Tools communicate directly with your CloudHSM Cluster via the CloudHSM Client Library over a secured, mutually authenticated channel. AWS cannot observe any communication between the client, tools, and HSM. It is encrypted end-to-end.

A complete list of supported operating systems is provided in our online documentation.

The host on which you are running the CloudHSM Client Library and/or using the CLI tools must have network reachability to all of the HSMs in your CloudHSM Cluster.

You can create, modify, delete, and get the status of CloudHSM Clusters and HSMs. What you can do with the AWS CloudHSM API is limited to operations that AWS can perform with its restricted access. The API cannot access the contents of the HSM or modify any users, policies, or other settings. To learn more, please see the CloudHSM Documentation for information about the API, or the Tools for Amazon Web Services page for more information about the SDK.

Start by ensuring that the algorithms and modes you require are supported by AWS CloudHSM. Your account manager can submit feature requests to us if needed. Next, determine your key rotation strategy. We have also published an in-depth migration guide for AWS CloudHSM. You're now ready to get started with AWS CloudHSM.

Your rotation strategy will depend on your type of application. Common examples are below.

• Private keys for signing: Generally, the private key on the HSM corresponds to an intermediate certificate, which is in turn signed by an offline enterprise root. You will rotate keys by issuing a new intermediate certificate. Create a new private key and generate the corresponding CSR using OpenSSL on AWS CloudHSM. Next, sign the CSR with the same offline enterprise root. You may have to register this new certificate with any partners who do not automatically verify the entire certificate chain. Moving forward, you would sign all new requests (such as for documents, code, or other certificates) with the new private key, corresponding to the new certificate. You can continue to verify signatures from the original private key using the corresponding public key. No revocation is necessary. This process is analogous to the process you would follow to retire or archive a signing key.
• Oracle Transparent Data Encryption: You can transfer your wallet by first switching from a hardware keystore (your original HSM) to a software keystore, and then back to a hardware keystore (AWS CloudHSM). Note: If you are using Amazon RDS, see the above FAQ “Does AWS CloudHSM support Amazon RDS Oracle TDE?”
• Symmetric key for envelope encryption: Envelope encryption refers to the key architecture where one key on the HSM encrypts/decrypts many data keys on the application host. You likely already have a key rotation process in place to go through and decrypt the data keys with the old wrapping key and re-encrypt them with the new wrapping key. The only difference during migration will be that the new wrapping key will be created and used on AWS CloudHSM instead of your original HSM. If you do not already have a key rotation tool and process in place, you will need to create one.

Each application and use case is different. Solutions to common scenarios are discussed in the migration guide for CloudHSM. For additional questions, open a support case with details of your application, the type of HSM you are using today, the type of keys you are using, and whether these keys are exportable or not. We will help you determine an appropriate migration path.

No, but AWS may need to conduct maintenance in the event of necessary upgrades or faulty hardware. We will make every effort to notify you in advance using the Personal Health Dashboard if any impact is expected.

Please note it is your responsibility to architect your cluster for high availability. AWS strongly recommends that you use CloudHSM Clusters with two or more HSMs in separate Availability Zones. You can learn more about recommended best practices in our online documentation.

You can find solutions to common problems in our troubleshooting guide. If you are still experiencing issues, contact AWS Support.