AWS Config Rules is an add-on to the AWS Config system and part of a growing repertoire of Amazon's development...
operations tools. When it was announced during the re:Invent 2015 keynote, AWS vice president Andy Jassy noted surprise that attendees were excited for a system that checks resource tags. But that's the thing about development operations: Automating small things can make all the difference between success and failure.
When first introduced, AWS Config Rules was largely described from the point of view of automating security constraints to prevent accidental and unnecessary access to resources. That's a good reason to use AWS Config Rules, but an even better reason could be to save money by automating the creation of resource tags.
Many development shops create a wide range of AWS resources on a daily basis, such as Elastic Compute Cloud instances, volumes, load balancers and virtual private networks. If a business leaves dozens of forgotten services running in the cloud, the costs add up, even with inexpensive resources. It is crucial to remember to terminate or release all unneeded resources at the end of the day.
Without a discipline for naming or tagging these resources, it can be difficult after the fact to distinguish between a forgotten test instance and a VPN server that's seen very little load. We can remove the problem of zombie resources by requiring an owner for all resources via resource tags.
Putting AWS Config Rules in place
To understand rules, you first have to understand a little bit about the AWS Config service itself. AWS Config performs four tasks: It records changes to resources, normalizes the description of the myriad of resource types, stores the results and then delivers them to Amazon Simple Storage Service for later analysis. It also writes to an Amazon Simple Notification Service (SNS) topic, allowing you to receive a near real-time stream of configuration change notifications.
AWS Config Rules is a system that listens to that SNS topic and runs AWS Lambda functions against each message. Each message contains a configuration item, which is a description of the state of the resource at a point in time. The description contains metadata, common attributes, relationships with other resources, the current configuration -- as might be returned by a describe API -- and a CloudTrail event identifier.
The AWS Config dashboard offers a timeline view that shows configuration changes, such as configuration items for a given resource. The configuration field displays what has changed; a link to the CloudTrail events gives you the user ID and location where the change originated.
AWS provides a set of predefined rules and has also established a partner system. Developers can use rules defined by other AWS partners or they can write custom rules. These rules are Lambda functions.
This is another reason to explore AWS Config Rules -- it's an easy way to get started with Lambda. If you opt for custom rules, you get a filled-in Lambda template. This gives you a way to start writing and modifying simple Lambda functions.
In Config Rules, developers can do more than just report a lack of compliance. Because AWS-provided rules tell you when a resource is out of compliance, they don't prevent noncompliance. A Lambda function can do (mostly) anything; a developer can write his function to disallow noncompliance. For example, if someone has created an instance without the mandatory AWS tags, that instance can be terminated.
Log management tools tidy up AWS resources
Boost AWS security with logging tools
AWS Config in need of refinement