everythingpossible - Fotolia
Editor's note: This article is the second in a two-part series on maintaining compliance with AWS Config. Check out the first part, which explains how AWS Config works and how to implement continuous compliance with predefined AWS Config managed rules.
There's more to AWS Config than just out-of-box rules.
Most organizations have specific compliance needs and must tailor their cloud compliance rules to meet those challenges -- demands that AWS Config can accommodate. In this AWS Config tutorial, we'll walk through the different ways to customize Config rules.
The first approach is to alter active predefined rules in the AWS Config console. You can assign these managed rules unique names, tailor them to report on the scope of configuration changes, set periodic triggers to your desired frequency and alter these rules' parameters. Again, this is all done through the console and fairly straightforward. In this AWS Config tutorial, we'll focus on the more advanced Config customization techniques, though this first approach is still useful.
The second approach is to tailor AWS Config rules using AWS CloudFormation templates, which we'll cover below.
The third approach is to create custom rules for AWS Config and associate those rules with AWS Lambda. In this case, the Lambda function determines whether an AWS resource adheres to the custom rule.
Customize AWS Config rules with CloudFormation
Developers use AWS CloudFormation templates to model and deploy AWS infrastructure as code in a YAML text file. A template can provision resources individually or work with a collection of related resources that you can provision and update as a cohesive unit, called a stack.
To create and apply an AWS Config managed rule to a resource or workload stack, associate an AWS Config managed rule with an AWS CloudFormation template. The easiest way to do this is to browse the list of AWS Config managed rules and select the rules to apply.
Let's go over an example to illustrate this as part of our AWS Config tutorial. Navigate to the list and select the ec2-volume-inuse-check rule, which checks whether Amazon Elastic Block Store (EBS) volumes are connected to EC2 instances. The rule is triggered anytime a configuration is created or changed, and EBS volumes can be set for deletion when the EC2 instance is terminated, which saves storage costs. At the bottom of the selected rule description, select View to download the CloudFormation template for customization, or select Launch Stack to apply the managed rule directly.
If you select View, access the AWS CloudFormation console to create a new stack, against which the rule will be applied. The template can then be uploaded to an Amazon S3 bucket and launched later.
If you opt for Launch Stack, select the desired template and specify details for the AWS Config rule. In the case of the ec2-volume-inuse-check rule, name it and set the deleteOnTermination parameter. Additional tags and options may also be available, depending on the particular rule. Once the rule details are set, review and create the CloudFormation template. You've now created a customized AWS managed rule that will appear in the AWS Config console.
With AWS CodePipeline, a managed service for CI/CD, software developers can model, configure and automate the various stages of the software release pipeline. With AWS Config, admins and developers can track changes to the pipeline, such as actions and the location of components. As with any deployment process on AWS, users will need to provision and configure an assortment of resources to host the software, as well as supporting services, such as storage and load balancing.
Such orchestration is well suited to CloudFormation template stacks composed from AWS Config managed rules. The deployment steps of a CodePipeline project can invoke CloudFormation templates that include AWS Config managed rules in order to establish stacks that can be reused to create repeatable environments for hosting the software build being deployed.
How to get the most from compliance on AWS
Compliance rules require careful development, implementation and follow-through. Here are some best practices to consider when creating a compliance rule:
- Only apply rules that are required to ensure the necessary level of governance and compliance for the business.
- Involve business leaders to determine the value of such rules in the cloud infrastructure.
- Create rules that are specific and limited. A rule should affect one resource or perform one task, and that's it.
- Consider the workflow needed to actually address Amazon SNS notifications when violations are reported so remediations can be implemented quickly and clearly.
How to create AWS Config rules with AWS Lambda
AWS Config managed rules can often be used directly in the console or customized with CloudFormation to work with common AWS offerings, such as CodePipeline. However, you can also create your own event-based rules with AWS Lambda. Such events are triggered when a configuration is invoked or changed. In order to create these customized, event-driven rules, you must first create a Lambda function, then create a custom rule in AWS Config and finally associate the rule with the function.
Let's underscore the distinct separation here. The function is not the rule, but rather the logic employed to trigger the rule. The rule itself is a customized version of an established managed rule in AWS Config. Thus, users can create a detailed Lambda function capable of invoking compliance rules. Follow this next example in our AWS Config tutorial to create new rules with Lambda.
First, create the Lambda function that will drive the rule. Sign into the AWS Lambda console and check that your current region supports AWS Config rules, then select a config-rule-change-triggered blueprint. There is no need to configure triggers, because the function is always triggered based on events -- in this case, changes.
Now, configure the Lambda function with details such as a name, preferred runtime, code type and handler. Select a role and role name, along with an AWS Config Rules permission policy template. Review theses details and create the Lambda function. Test the function by configuring and executing a test event for the new rule.
With the Lambda function created, you can create a custom rule. This is similar to the first approach, with which you tailor predefined AWS Config rules, but users should ensure the rule is created in the same region where the Lambda function was created.
Open the AWS Config console, locate the Rules page and select Add rule. Choose Add custom rule and complete the details such as the rule name, description, trigger type, trigger scope, resources and so on. The most notable difference here is the inclusion of an AWS Lambda function Amazon Resource Name, which associates the rule with the function.
Finally, you will need to define the rule parameter, along with the key or value for the rule. For example, if the function is intended to test a specific instance type, the rule may use a parameter such as desiredInstanceType and a value of a1.2xlarge -- or whatever the desired type may be. Once the new rule is saved, it will appear in the Rules page. Now, when the associated Lambda function is executed, it will run the corresponding rule.