How to lower expenses by deleting and recreating HSMs automatically
You should use AWS CloudHSM to greatly help manage your encryption keys on FIPS 140-2 Level 3 validated hardware security modules (HSMs). AWS recommends owning a high-availability production architecture with at the very least two CloudHSM HSMs in various Availability Zones. Although some workloads should be available 24/7, quality assurance or development environments don’t have this requirement typically.
In this article, we show you how exactly to automate the deletion and recreation of HSMs once you don’t have a requirement of high availability. By using this approach of deleting HSMs and restoring them from backups on a predefined schedule might help decrease your monthly CloudHSM costs. To find out more on the CloudHSM backup process, start to see the CloudHSM cluster backup documentation.
For this solution, you utilize the next AWS services to automate the procedure of deleting and restoring HSMs running non-production workloads:
Here’s the way the process works, as shown in Figure 1:
- At the scheduled time (we have been using 7:30 PM UTC in this example), a CloudWatch Events rule triggers the DeleteHSM Lambda function.
- The DeleteHSM Lambda function stores the HSM metadata, such as for example IP Availability and address Zone, in a DynamoDB table, deletes the HSMs from the cluster, and sends a contact notification.
- At the scheduled time (we have been using 7:30 AM UTC in this example), another CloudWatch Events rule triggers the AddHSM Lambda function.
- The AddHSM Lambda function retrieves the HSM metadata in the DynamoDB table, creates the HSMs in to the cluster with exactly the same IP Availability and address Zone, and sends a contact notification.
Note: In this solution, we utilize the same IP address when making a new HSM, which means you don’t have to modify the configuration files for the CloudHSM client instance connecting to the HSM.
open the CloudFormation template
- To, choose the Launch Stack button below.
- Give your stack a genuine name.
- Under Parameters, enter values for the next parameters based on the needs you have:
- ClusterId: The ID of the prevailing CloudHSM cluster that you intend to use.
- CreateTime: The time whenever your HSMs ought to be created in UTC. This parameter should be a valid cron expression. The CreateTime shown in Figure 2 is 7:30 UTC Mon-Fri.
- DeleteTime: The time whenever your HSMs ought to be deleted in UTC. This parameter should be a valid cron expression. The DeleteTime shown in Figure 2 is 19:30 UTC Mon-Fri.
- EmailAddress: The e-mail address which will be subscribed to the SNS topic for creation and deletion events for the HSMs.
- On the Specify stack details page, select Next, and, on the Configure stack options page, select Next.
- On the Review page, check the box that says I acknowledge that AWS CloudFormation might create IAM resources with custom names, and choose Create stack then, as shown in Figure 3.
- After the stack is established by you, the CloudFormation template automatically creates an SNS topic that notifies you when HSMs are deleted or created in your cluster. You need to sign up to this topic therefore the alerts could be received by you. Select Confirm subscription, as shown in Figure 4.
AWS resources deployed by the CloudFormation stack
When stack creation is complete, the template could have deployed the next AWS resources:
- An AWS Identity and Access Management (IAM) role named ClusterExecutionRole for the Lambda functions to utilize on each invocation. The IAM role uses the managed policy AWSLambdaBasicExecutionRole and an inline policy called CloudHSMPermissions. The managed policy supplies the Lambda execution role permission to create CloudWatch Logs. The inline policy grants the role permission to delete an HSM, create an HSM, publish to an SNS topic, develop a DynamoDB table, put items in to the table, and retrieve items from the table. For more information about CloudHSM permissions, see Predefined AWS Managed Policies for AWS CloudHSM. The CloudHSMPermissions inline policy is shown below.
Note: The resource names in the policy shown here are examples. The template shall update them to complement resources in your account once the solution is deployed.
- Two CloudWatch Events rules: one rule for creating the HSMs and something rule for deleting the HSMs. These rules are triggered at the proper times that you specified during creation of the stack.
- Two Lambda functions: AddHSM and DeleteHSM. You’ll find out about what each function does in the next section.
- An SNS topic that notifies you when HSMs have already been deleted or created.
Detailed walkthrough of the Lambda functions
We’ll walk you through the code in the Lambda functions that get triggered to delete and recreate the HSMs at scheduled intervals.
Delete CloudHSMs Lambda function
At the scheduled time (7:30 PM UTC in this example), the ScheduledRuleDeleteHSM CloudWatch Events event is triggered.
As shown below, the code for the DeleteHSM Lambda function passes the cluster ID first, table name, and region as environment variables in line with the parameters you entered when making the CloudFormation stack. At the scheduled time, the CloudWatch Events rule triggers the Lambda function, which creates a DynamoDB table the very first time the DeleteHSM Lambda function is triggered.
The code then makes a Describe API call with the cluster ID provided in the CloudFormation stack to retrieve the HSM details, like the HSM Availability and IP Zones. These things are saved to the DynamoDB table for use later, and the HSMs in the cluster are deleted. All recipients subscribed to the SNS topic receive an SNS notification showing the facts of the HSMs deleted from the cluster.
Create CloudHSMs Lambda function
At the scheduled time (7:30 AM UTC in this example), the AddHSM Lambda function is set off by the CloudWatch Events rule ScheduledRuleAddHSM to include the HSMs back again to the cluster. The code shown below retrieves the CloudHSM details, like the CloudHSM Availability and IP Zone, from the DynamoDB table. Next, the CloudHSMs are manufactured with the same Ip in to the same Availability Zone. This saves you your time and effort of having to create configuration changes on the CloudHSM client instances connecting to the HSM as the same IPs are employed. The CloudHSM daemon installed on your client instance reconnects to the HSMs immediately because they become active automatically. All recipients subscribed to an SNS be received by the SNS topic notification showing the facts of the HSMs created.
Note: If you opt to schedule the stop and begin of one’s client instances as described above, you need to make sure that the CloudHSM client daemon automatically starts running once the instance(s) boot up therefore the link with your CloudHSM cluster will resume.
In this post, a strategy was learned by one to help decrease your monthly CloudHSM charges for environments that don’t have to be running 24/7. You learned how exactly to achieve this cost benefits through the use of scheduled CloudWatch Events rules to trigger Lambda functions that delete and recreate the CloudHSMs in your cluster on a specified schedule without modifying client configuration files.
When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread on the AWS CloudHSM forum or contact AWS Support.
Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter.