1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Getting started with AWS CloudHSM

What is CloudHSM?


What is CloudHSM?

The course is part of these learning paths

Solutions Architect – Professional Certification Preparation for AWS
Security - Specialty Certification Preparation for AWS
AWS Security Services
AWS Access & Key Management Security
more_horizSee 1 more
What is CloudHSM?


AWS CloudHSM is the name of Amazon’s original encryption key solution. HSM stands for Hardware Security Module and in the solution provided by AWS, it is a Safenet Luna appliance hosted at AWS. The appliance is single tenant and exclusive to each customer. AWS only manages the hardware and base operation but does not manage the keys or even have the ability to access the key management system within the HSM.

Intended Audience:

  • Anyone that needs to know more about the Amazon Hardware Security Module branded CloudHSM that is provided as a dedicated hardware appliance.
  • Anyone preparing for an Amazon Certifications as well as security officers that have a responsibility to ensure data is protected in an environment at Amazon Web Services.


  • Due to the advanced nature of the CloudHSM topic, this course is not designed to be your first course about Amazon Web Services. 
  • It is a very good idea to complete the Key Management Service course if you are trying to make a decision between the two encryption offerings.

Learning Objectives:

  • To teach you the basics of AWS CloudHSM
  • What it will cost to implement
  • Comparison of KMS to AWS CloudHSM
  • How to implement a key and encrypt data
  • Which services can be used with CloudHSM
  • Why you might use AWS CloudHSM
  • Other uses for AWS CloudHSM

What you'll learn:

  • CloudHSM Basics: An overview of CloudHSM basics, along with terminally, and use cases.
  • What is CloudHSM: In this very detailed lesson, the presentation includes information about performance, scalability, availability, costs, and best practices.
  • CloudHSM Operations: How to set-up the HSM controller as well as how to provision and de-provision HSM.


Now we've covered the basics. Let's get into some more detail. What is CloudHSM? Cloud HSM is a FIPS 140 level two validated hardware device for secure cryptographic key storage. I can't stress this enough, CloudHSM is a hardware appliance, it is not a virtualized service. It is a SafeNetLuna 7000 appliance with 5.3.13 preloaded. There are two firmware versions and which one you pick is really based on your exact needs. One is for FIPS 140-2 compliance and there was a newer version that can be used. If your implementation requires FIPS 140-2, make sure you have the right firmware installed, version 6.10.9 is FIPS validated. In addition to the older firmware, you have to only use certain encryption algorithms that are part of the FIP 140-2 certification. Please note if your solution requires FIPS 140-2 compliance there is more to it than just the right firmware.

You will need to review the SafeNet Luna documentation for what is deemed compliant and how it was configured. Since this is your hardware appliance, it is your responsibility to keep the firmware updated to your requirements. Amazon web service admins will not be updating the firmware or any other functions other than base hardware monitoring. If you have specific needs for a different version of the firmware other than 6.10.9 for FIPS or the latest 6.20.2, you will need to contact AWS support prior to installing the firmware to make sure it is compatible.

The unusual feature of CloudHSM is that it is a physical device, and thus it is not shared with other customers, or as it is commonly termed, multi-tenant. It is dedicated single tenant appliance exclusively made available to your workloads. CloudHSM only operates in a VPC, so if you are still using AWS classic, you will need to migrate those instances to a VPC prior to connecting with the CloudHSM. CloudHSM is a device only available in the following 11 regions at this time. US-east-1, us-east-2, us-west-2, ca-central-1, us-gov-west-1, eu-west-1, eu-central-1, ap-northeast-1, ap-southeast-1, ap-southeast-2. Now, of course, this list will change as new regions become available, so if you have a solution in a region that is not listed, check with AWS for when CloudHSM will become available.

Now, what exactly does AWS provide? AWS provides the hardware device with two user functions, security officer and auditor. You are not the administrator of the appliance, but don't get too concerned. The administrator can only provision the appliance. The administrator in this case cannot make encryption keys, read, write, or manage the encryption keys, or even see the activity that goes on inside the encryption container within the SafeNet Luna appliance. The administrator, and in this case Amazon Web Service admins, can only provision the device, provide additional login information and wipe the device clean for the next person, and since this is a dedicated piece of hardware, if someone ever actually tampers with the appliance, it will erase itself and reset to a secure state that no longer has your encryption key stored in any form.

The encryption key administration is performed by the security officer. The security officer is the privileged account that manages the encryption keys. Since this is a single tenant device and only one customer, you need to plan your encryption needs and calculate the throughput required to determine how your scaling will be required. This device does not auto-scale or do any on-demand functions. It is a piece of hardware dedicated to you. It has a finite capacity and a finite availability. If your encryption key workloads exceed the hardware appliance capacity, you'll need to add a second or third device. Now, please note AWS currently does not offer SLA on the CloudHSM and does not ensure capacity in an availability zone.

Typically, a device is available within 15 minutes assuming there is capacity, but if the AZ is out of capacity it can take two weeks or more to acquire additional capacity. Accessibility, availability, reliability, and scalability. These are all things that you need to be concerned with. Remember that CloudHSM is only available within a VPC. A single CloudHSM can be shared across multiple VPCs if there is an IP path between the VPC, or between the VPC and an on-premise networks. VPC peering setups and VPN links would be required, but it can be done and you can have a few CloudHSM appliances provide encryption keys to many resources and other VPCs. So, when you put this device into production you need at least two appliances, but more than likely three for a single region to have high availability.

Remember, you must assume availability zones will go down, so you need to have the device highly available within that region. Now I'm going to compare a CloudHSM to Amazon's other encryption offering, Key Management Service. It is a really good idea to complete the Key Management Service course first. This table below shows you the differences between CloudHSM and Key Management Service. I'll give you a minute to read this over before continuing, but please take a look at this as we're gonna get into the details on all the items on this table. Key storage. In CloudHSM, the keys are stored in a dedicated appliance with its own hardware tamper-resistant key storage. KMS storage, your customer master keys on the same key storage hardware with other clients' customer master keys.

One area that CloudHSM and Key Management Service compare fairly well is in their usage. Both are available to you at AWS and both are integrated with your apps at AWS. Since this is a physical device dedicated to you, the keys are stored on the device. Keys need to either be replicated to another device, backed up to offline storage, or exported to a standby appliance. This device is not backed by S3 or any other service at AWS like KMS. Scalability. In CloudHSM, you have to scale the service yourself. You have to provision enough CloudHSM devices to handle whatever your encryption needs are based on the encryption algorithms you have chosen to implement for your solution.

Key Management Service scaling is performed by AWS and automatically scales on demand, so as your use grows, so might the number of CloudHSM appliances that are required. Keep this in mind as you scale your solution and if your solution has auto-scaling, make sure your maximum scale is accounted for with enough CloudHSM appliances to service the solution. Performance. Just like scaling, performance is up to you with CloudHSM. Performance varies based on which encryption algorithm is used and on how often you need to access or retrieve the keys to encrypt the data. Key management service performance is handled by Amazon and automatically scales as demand requires it. CloudHSM's performance is achieved by adding more appliances and if you need more performance you either add devices or alter the encryption method to the algorithm that is faster.

Switching to a different algorithm needs to be carefully evaluated. This may not comply with either company standards or the governing standards for your solution. High availability. With CloudHSM you are responsible for availability and you will need to deploy multiple appliances to achieve high availability with the appliance. With Key Management Service high availability is built in across the region. You do not need to be concerned with the service being available within your region. KMS as multi-region isn't possible. Multi-region results in multiple customer master keys. The most common solution is to have multiple CloudHSM appliances in multiple availability zones within a region.

If your solution is multi-region, you should add several CloudHSM appliances in the second region and work out the cross-region connectivity with a private VPN connection or some method to ensure the traffic is always protected between the appliance at every layer of the connection. Multi-region and CloudHSM. If you have a multi-region solution you need to think about how to replicate keys and set up additional CloudHSM devices in the regions where you operate. You can very quickly get into a scenario where you have six or eight devices spread across multiple regions, enabling full redundancy of your encryption keys.

This is very important to think about as you plan how you are going to deploy and roll out CloudHSM, since loss of encryption keys means loss of access to data. If you lose the device, you've lost the data. No matter how hard you try, the data is gone unless you have an encryption key. The concept of multi-region is more of an infrastructure project with specific instances and services running in each region with communication paths between the resources and in this case, between multiple CloudHSM appliances. Adding a VPN link between multi-region VPCs is normally considered best practice. I would recommend always encrypting traffic between regions just to be sure nothing happens to the traffic between regions. Integration. With CloudHSM, you must integrate the service with your applications. There are a few services that are integrated at this time.

Redshift is one and the other is RDS when used with Oracle 11g and Microsoft SQL Server if the feature of transparent data encryption is enabled and configured. For OS level encryption services such as encrypting a drive, a block volume, or a limited set of directories, you may use SafeNet ProtectV manager and clients. There are other third party options that you may want to consider. Just know that additional software is needed and charges and licenses might have to be evaluated. KMS on the other hand has broad adoption within AWS and is integrated into most of the services that have storage, and within these services KMS will provide encryption and decryption transparently. For example, properly configured encrypted EBS volumes encrypt data to disk and decrypt data without any additional work other than setting up the EBS volumes KMS encryption keys. Monitoring.

Compliance is at the heart of CloudHSM. For this reason, CloudHSM's audit trail is integrated with AWS's CloudFare monitoring auditing service. There are two kinds of logging when it comes to CloudHSM. CloudHSM API, pertaining to administrative functions of CloudHSM, create, delete-hsm, allocate HSM client, modifying CloudHSM HA setup. It's described in the detail in the API operations manual, and Luna's native SysLog. All CloudHSM API calls are logged to CloudTrail with timestamps, IM user identity, and action performed. CloudHSM's internal activity is logged to a SysLog IP end point. You can capture the SysLog with a SIM tool, so that's just ELK or Splunk.

Do note that you can add additional SysLog IP end points to CloudHSM later, but you cannot delete the existing SysLog IP end point for security reasons. What this means is that you get CloudHSM provisioning information and setup information in CloudTrail. To get information on what is actually done with the appliance, you have to work with the SysLog feature of the appliance. We'll likely want to set up a third party solution to retrieve and receive the SysLogs and provide alerting on log events. Stored key types.

CloudHSM is an enterprise class service for secured key storage and can be used as a root of trust for an enterprise. It can store private keys in PKI and certificate authority keys in X509 implementations. In addition to symmetric keys used in symmetric algorithms such as AES, KMS stores and physically protects symmetric keys only, so if you need to store PKI and CA keys a CloudHSM or two or three could be your solution. Pricing. CloudHSM is considerably more expensive than Key Management Service. CloudHSM is a hardware appliance so you have fix costs to provision the CloudHSM device, then an hourly cost to run the appliance. The cost is multiplied by as many CloudHSM appliances that are required to achieve your specific requirements.

Additionally, cross consideration must be made in the purchase of third party software such as SafeNet ProtectV software suites and integration time and effort. Key Management Service is a usage based and depends on the number of keys you have and the input and output operations. As key management provides seamless integration with many AWS services, integration costs should be significantly lower. Costs should be considered secondary factor in encryption solutions. Encryption is typically used for security and compliance.

The cost of the solution is simply part of the required components in the overall solution. Access. A key difference is who has access to the keys. With CloudHSM only you have access to the keys and without going into too much detail, with CloudHSM you manage your own keys. With KMS, you and Amazon co-manage your keys. AWS does have many policy safeguards against abuse and still cannot access your keys in either solution. The main distinction is compliance as it pertains to key ownership and management, and with CloudHSM, this is a hardware appliance that you manage and maintain with exclusive access to you and only you.

So, now that we've covered the details and compared CloudHSM to KMS, I want to go over some of the best practices for using CloudHSM.

One, always deploy CloudHSM in an HA setup with at least two appliances in separate availability zones, and if possible, deploy a third either on premise or in another region at AWS.

Two, be careful when initializing a CloudHSM. This action will destroy the keys, so either have another copy of the keys or be absolutely sure you do not and never, ever will need these keys to decrypt any data.

Three, CloudHSM only supports certain versions of firmware and software. Before performing any update, make sure the firmware and or software is supported by AWS. You can always contact AWS support to verify if the upgrade guide is unclear.

Four, the network configuration should never be changed. Remember, it'sin a AWS data center and AWS is monitoring base hardware for you. This means that if the hardware fails, they will replace it for you, but only if they know it failed.

Five, the SysLog forward should not be removed or changed. You can always add a SysLog forwarder to direct the logs to your own collection tool.

Six, the SNMP configuration has the same basic restrictions as the network and SysLog folder. This should not be changed or removed. An additional SNMP configuration is fine, just make sure you do not change the one that is already on the appliance.

Seven, another interesting best practice from AWS is not to change the NTP configuration. It is not clear what would happen if you did, so keep in mind that if you don't use the same NTP configuration for the rest of your solution then you could have two time sources. Just be aware of this and know that the CloudHSM has to stay with the existing NTP source.

So, what does it cost to use a CloudHSM? So, now that we have seen how to use a CloudHSM and compared this to AWS's Key Management Service, reviewed the best practices, you may want to know what it costs to use a CloudHSM. To use CloudHSM there is an initial charge. The initial launch charge for CloudHSM is $5,000 to allocate the hardware appliance dedicated for your use, then there is an hourly charge associated with running CloudHSM that is currently at $1.88 per hour of operation, or approximately $1,373 per month. There are no charges for input or output or the number of keys, or to use any particular algorithm that is supported by the device. Every CloudHSM that you require, you will need to pay these one time charges and the continued operational charge at $1.88 per hour. An example cost for one appliance is for the first year, it will cost you approximately $21,500 to operate, and subsequent years are reduced by the initial $5,000 upfront charge for approximately $16,500 per year.

So, why would you implement CloudHSM? Now that you know the difference between CloudHSM and Key Management Service, you may be asking yourself why would anyone use CloudHSM? There are a number of reasons that you need to use CloudHSM over some of the other encryption offerings. The most common reason to use CloudHSM is compliance standards that you must meet for regulatory reasons. Often complex compliant regulations around encryption are not supported by KMS, or are not accepted by standards set forth by the regulations.

In my experience, the decision often hinges on the ownership and protected level of keys. With KMS, technically AWS and you own your keys. With CloudHSM, your organization owns the keys. With CloudHSM, you have FIPS 1, god, I can't read tonight. I can't read this one slide. Why would you implement CloudHSM? Now that you know the difference between CloudHSM and Key Management Service you may be asking yourself why would anyone use CloudHSM? There are a number of reasons that you need to use CloudHSM over some of the other encryption offerings.

The most common reason to use CloudHSM is compliance standards that you must meet for regulatory reasons. Often complex compliance regulations around encryption are not supported by KMS or are not accepted by standards set forth by regulations. In my experience, the decision often hinges on the ownership and protection level of keys. With KMS, technically AWS and you own your keys. With CloudHSM, your organization owns the keys. With CloudHSM, you have a FIPS 140-2 level two validated hardware module for key storage. Some of these compliance standards are PCI DSS, SOC 1, SOC 2, and SOC 3, or government encryption requirements for FIPS 140-2 validation. If you solution must comply with any of these standards, then you will need to consider using CloudHSM. Besides the compliance requirements, CloudHSM offers some functional advantages over KMS. If you completed the KMS course, you may recall that KMS stores the customer master key. The customer master key in turn will generate the data encryption key to encrypt and decrypt data in an EBS volume or S3, for example.

The data keys are symmetric keys and KMS uses AES symmetric algorithms to perform the encryption. KMS does not offer data support for asymmetric keys. CloudHSM does let you store asymmetric keys securely. Now let's explore some more use cases for CloudHSM. Database encryption. CloudHSM is natively integrated with Redshift data warehouse solution, Oracle RDS, and Microsoft SQL Server 2008 and 2012 with transparent data encryption. PKI and certificate management. CloudHSM can securely store certificate signing keys, private keys, root certificates, and intermediate certificates, making it a key component of public key infrastructure. Identity and auditing. CloudHSM serves as root trust for PKCS 11, Java JCA/JCE, or Microsoft Cryptographic API, commonly called CAPI, useful for implementing secure single sign on and cryptographic token solutions. Digital content. Encrypting digital documents to meet contractual requirements or a strong protection of encryption keys. These are just some of the use cases for CloudHSM. There are others. You may have a new use case that works best with CloudHSM over the other options.

About the Author

Tom an active AWS Consultant creating and deploying AWS solutions for over five years. He has worked on numerous projects that involve everything from small lean startups on a tight budget to massive commercial Enterprises that have large-scale budgets with large-scale requirements that must be met even no matter the cost. Tom has worked for several of our United States government agencies taking the agencies to the cloud by migrating solutions from on-premise data centers to the AWS cloud in a secure solution while reducing their overall cost to operate and maintain the solution.

Personally Tom spends his available time riding his bicycle, sampling a good wine or two, enjoying a good meal and watching Formula One races.