Hello and welcome to this lecture where I want to provide an overview of the architecture of CloudHSM and the general steps of implementation to help you understand its deployment.  

Let me start with the CloudHSM Cluster.  When you implement CloudHSM, you will begin by creating a cluster.  This cluster is simply a grouping of different HSMs which will act as a single unit when configured and deployed.  Having multiple HSMs provides an element of high availability as you are able to select multiple different subnets, one from each availability zone that your VPC operates in, to deploy an HSM into.  Any requests to your CloudHSM cluster are then automatically load-balanced between the HSMs in the cluster, and if one HSM fails, AWS will automatically deploy another one within your cluster.  As a result, running a VPC is a prerequisite of implementing your cluster.

During the deployment of your HSMs, it’s actually an Elastic Network Interface (ENI) that is placed within the subnet that you select of your VPC.  The HSM itself actually resides in a different AWS-owned VPC, and located in the same AZ as you select during its deployment.  So it’s the ENI that is deployed in your VPC which acts as an interface between your network and the HSM residing in an AWS-owned VPC.

When you create the cluster, CloudHSM will do 2 things. Firstly, a new service-linked role will be created ‘AWSServiceRoleForCloudHSM’ which gives CloudHSM the permission to send log data to CloudWatch Logs log groups and log streams on your behalf. For those familiar with IAM policies, the policy looks as shown.

Secondly, CloudHSM will also create a new security group for the cluster (cloudhsm-cluster-clusterID-sg). This is an important security group as it controls which resources can communicate with the HSMs.  The security group itself will allow both inbound and outbound connectivity over TCP ports 2223-2225, which enables each of your HSMs within your cluster to communicate with each other.  When this security group is created by CloudHSM, no other resources are associated with it. 

Once your cluster has been defined and created in the different subnets and availability zones that you have selected, it will have been provisioned in an ‘uninitialized state’. From this point, you can create your HSMs in each availability zone that you selected and ‘initialize’ the cluster.  As this is a beginner course, I will not dive into this initialization process, however, if you would like a detailed technical understanding of how to perform this step, please refer to the AWS documentation here.

When your cluster is initialized you can then connect to your cluster HSM network interfaces, and one of the easiest ways to do this is via an EC2 instance provisioned in the same VPC. There are 2 steps which must be carried out for your EC2 instances to interact with the HSMs. Firstly, you must configure a security group. And secondly, you need to install the AWS CloudHSM client software on your instance.

So, firstly, the security group.  You must add your instance to the cloudhsm-cluster-clusterID-sg security group.  As we already know, this security group allows your HSMs to communicate with each other, but this same security group is also used to define which EC2 instances can communicate with your CloudHSMs, which must be manually added to the security group.  If you want to connect to your CloudHSM using a Windows EC2 instance then you must add a rule to this SG using RDP with port 3389, if using a Linux instance then you must select SSH using port 22.

Next, you must install the client and command-line tools.  To do this, connect to your instance that you added to the security group as I just mentioned. 

If using a Linux instance, then you need to run a command, and this command will be different depending on the OS you are running.  For a list of commands relating to the following OS’s please refer to this AWS resource.

Once you have installed the client and tools, you need to modify the client configuration to enable you to connect to your cluster.  Firstly you need to copy your issuing certificate (created when you initialize your cluster) to /opt/cloudhsm/etc/customerCA.crt

You must also run the following command, replacing the red text with your HSMs IP address 

sudo /opt/cloudhsm/bin/configure -a <IP address>

If you are using a Windows instance, then you will need to download the installation from here.

After running the MSI file, you will need to copy the self-signed issuing certificate to the following.

And then finally, you need to run the following command to configure the client software replacing the text in red with your own HSM details.

C:\Program Files\Amazon\CloudHSM\configure.exe -a <HSM IP address>

So let’s take a quick logical look at how the infrastructure would look like at this stage.

So as you can see, we have the customer VPC split across 3 different availability zones and subnets, each with an EC2 client containing the HSM client software and an HSM ENI. Each EC2 client can communicate with ANY of the HSM ENI across the different subnets within the cluster using the cloudhsm-cluster security group.  These ENIs then communicate with the HSMs located in an AWS-owned VPC.

We also have the IAM role that has been created allowing HSM to send log data to CloudWatch Logs log groups and log streams on your behalf.  

Once your infrastructure is in place and you have configured your CloudHSM connectivity, you simply need to activate your HSM cluster before use.