Okay; as we have understood what is possible, let's see it all in action and create our own custom Config rule. Our example organization has an internal policy that states that every production server must be backed up daily. Being awesome AWS engineers, we are using the AWS Backups service and have created a backup plan that takes a daily snapshot of Elastic Block Store (EBS) volumes that have been assigned to the plan. The backup plan looks for a resource tag called Backup with the value of Daily and automatically adds those to the plan:

Now that it would be easy to comply with our company policy by creating the tag when the instance is built, we could use a Lambda function to listen for CreateInstance actions in CloudTrail and check that the tag is present as well. However, what if something happened to the tag after the instance was built? It could have been removed or the value could have been changed, causing the instance to drop out of the backup plan. This is where an AWS Config rule is perfect, because the service is continually monitoring the configuration of our resources. If a tag on an instance is removed or updated, we can trigger a Lambda function to run to check that the resource is still complying with our policy. 

So, let's go and create that Config rule. But first, we need to create the Lambda function to implement the remediation logic. I've chosen to use a blueprint to start with, the one called config-rule-change-triggered. This will include some scaffolding that we can use to get started faster. Take some time to familiarize yourself with the functions that are in there, because they will help you to do your checks and run your configuration evaluations. Whatever logic you choose to implement, you need to assemble and return a payload to the PutEvaluations action of the Config API. The structure of the payload is an array with evaluations. Here's an example of one evaluation:

[ 
  { 
    ComplianceResourceType: configurationItem.resourceType, 
    ComplianceResourceId: configurationItem.resourceId, 
    ComplianceType: compliance, 
    OrderingTimestamp: configurationItem.configurationItemCaptureTime, 
  }
]

Okay; so, now we have a function that can receive an event if triggered. Now, we need to create a new trigger in Config. Head over to the AWS Config console. If this is the first time you have used the service, you will need to set up some initial configurations. This includes creating an S3 bucket to store all of the configuration records and an IAM role for Config to use. We're then presented with a rather blank-looking dashboard, which will be populated when Config completes the discovery of the inventory:

Next, we need to create our custom rule. First, click the Rules option on the left-hand side menu and then click the Add rule button. I'm going to call my rule prod-backup-compliance-rule and drop in the Amazon Resource Name (ARN) of the Lambda function that it will trigger. The rest of the details are easy to follow as well:

We want our rule to fire when it notices changes to the configuration, specifically changes to EC2 instances. There's also a space at the bottom for us to add some arbitrary parameters that the Lambda can use during execution. I've passed in the tag that we will be interested in. Externalizing this value is a good idea because it means we don't have to hardcode it into the function code, so we can write the function to be reusable for other environment tags should we need to. 

After we create the rule, that's all we need to do. The trigger is set up and enabled and will trigger the Lambda function to execute whenever a change to an EC2 instance is made. 

This is a great example of how you can enforce your security compliance policies using only serverless services.