AWS Storage Blog
Validate your disaster recovery solution and simplify compliance reporting on AWS
Data protection is a key element of compliancy, and organizations must deploy controls to manage the protection of their data and handle operational disruptions. With ongoing configuration and resource changes within IT infrastructure, it can be challenging to continuously and efficiently validate, maintain, and report on compliance to ensure that internal policies and regulatory standards are met.
Organizations use CloudEndure Disaster Recovery to minimize downtime and data loss by providing recovery of physical, virtual, and cloud-based servers into AWS. AWS Config enables you to assess, audit, and evaluate the configurations of your AWS resources, including their data protection status. AWS Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. AWS Systems Manager gives you visibility and control of your infrastructure on AWS or on-premises. Systems Manager provides a unified user interface so you can view operational data from multiple AWS services, and it allows you to automate operational tasks across your AWS resources. Systems Manager integrates with AWS Config to extend compliance validation to the operating system level.
In this blog post, we demonstrate how to write and deploy an AWS Config custom rule to validate CloudEndure Disaster Recovery replication for an Amazon EC2 instance or an on-premises server. You can develop AWS Config custom rules that are associated with an AWS Lambda function, and evaluate whether your AWS resources comply with those rules. You can also add the rules as a compliance check to AWS Audit Manager. This solution simplifies the process of providing evidence of data protection to compliance auditors by using a centralized framework within the AWS Management Console.
- AWS account.
- CloudEndure Disaster Recovery account.
- AWS Config must be enabled on the Region where you deploy the rule. More information, read the documentation on turning on AWS Config.
- For on-premises servers, you must install the AWS Systems Manager agent on the target server and have AWS Systems Manager Inventory For information on how to manage on-premises resources using AWS Systems Manager, check out the documentation.
- AWS administrator account or an account with enough permission to create IAM resources, Lambda functions, and the AWS Config rule.
- A generated CloudEndure Disaster Recovery API token.
- An Amazon S3 bucket to state the Lambda package.
How does this solution work?
The sample code provided in this blog helps you integrate CloudEndure Disaster Recovery with AWS Config so you can validate that EC2 instances or on-premises servers are replicating and properly protected. The code can be used to validate resources on-premises by using the AWS Systems Manager features. An AWS CloudFormation template will create the resources required for the AWS Config custom rule.
CloudEndure Disaster Recovery provides an easy-to-use RESTful API. This rule uses the CloudEndure API to validate if a server is properly configured in CloudEndure Disaster Recovery. It also checks that there is no lag in replication and that the server has been recently tested. The Lambda function that powers the custom rule receives as a parameter the following three values:
- The API token needed to interact with the CloudEndure API.
Note: In the sample code, this value is being passed as a parameter. This exposes the API token in the AWS Config rule definition. A more robust implementation of this code should read this value from an encrypted Parameter Store value in the code of the Lambda function.
- The name of the CloudEndure Disaster Recovery project that the machine is part of.
- The EC2 instance ID, or the managed resource ID of the on-premises server, that should be validated in CloudEndure Disaster Recovery.
The code first determines if the resource being evaluated is an EC2 instance or an on-premises resource that has the AWS Systems Manager agent installed. It then queries the CloudEndure API to check if the machine exists in the configuration. It then extracts the value of the BackLoggedBytes, the LastConsistencyDate, and lastTestLaunchDateTime properties. If any of these values are outside of what is expected for replication to be operational, then the resource is flagged as not compliant. The results are then returned to AWS Config.
The solution referenced in this blog can be found here.
Creating the package for the Lambda function
To deploy the AWS Lambda function for the custom rule, we create the function package, which has a dependency in the requests python library. The requests library simplifies the process sending HTTP/1.1 requests to API endpoints. This library is required to interact with the CloudEndure API. To create the function package, follow these steps:
- Download the sample code to your local computer:
git clone https://github.com/aws-samples/aws-management-and-governance-samples.git # then change directory into the solution directory with the following command cd aws-management-and-governance-samples/AWSConfig/CloudEndureCheckReplication/
- Package the python code and the dependencies to get them ready for deployment. Install the requests library so it can be packaged with the Lambda function:
cd lambda_function pip install requests -t ./
- Create the Lambda package to be uploaded when the function is created:
zip -r ../CloudEndureReplicationCheck.zip .
- Copy the package to an s3 bucket:
aws s3 cp CloudEndureReplicationCheck.zip s3://your-deployment-bucket/
Deploy the AWS CloudFormation template
The AWS CloudFormation template creates the additional resources required to deploy the custom rule. That includes the rule, IAM role, Lambda Function. To create these resources, use the AWS Management Console or AWS CLI. Following is an explanation of the parameters required.
||Description of the AWS Config rule||Checks replication status of a machine in CloudEndure|
||Name of the S3 bucket that you have stored the rule zip files in. For example: example-bucket||See the package step and use that bucket name|
||Path to the s3 bucket and location where you have stored the rule zip files. For example: /myrulefolder/mylambdacode.zip|
||This is the runtime setting to define the handler for the Lambda function. It’s a combination of the name of the file and the name of the function that should be invoked when the function is launched. More info here. In this case use the default name provided.||
||AWS Config resource types that will trigger the evaluation of this rule. On this case EC2 instances and SSM-managed instances on-premise||
||The timeout for the Lambda function to run.||300|
||Name of the AWS Config rule||
||Name of the Lambda function||
||Enter the CloudEndure project name and API token. This is for demo purposes. The API token should be stored encrypted in a credential platform like Parameter Store or AWS Secrets Manager|
Deploy the CloudFormation template using the AWS Management Console or the CLI. Once you do, you will be able to see your new AWS Config rule. The rule detects any resources that exist in CloudEndure Disaster Recovery and validate that they are set up properly and replicating.
In the following example, two resources are found to be non-compliant.
To remove the resources created with this blog, delete the CloudFormation template. If you enabled AWS Config for this exercise, make sure to disable it using the instructions found here.
In this post, we used AWS Config with a Lambda function to validate the compliance status of EC2 instances and on-premises machines protected by CloudEndure Disaster Recovery. The custom rule validated the replication and test status of machines protected by CloudEndure Disaster Recovery. By monitoring and evaluating AWS resource configurations with such a solution, you can simplify compliance auditing and operational troubleshooting of your protected workloads. Doing so ensures that your organization is meeting your required internal and regulatory guidelines for protection of data and operational resiliency.
Thanks for reading this blog post. If you have any comments or questions, you can add them to the comment section.