If compliance is one of your priorities while working on AWS Cloud then Config is a good place to start. In this post, I will discuss Config service in detail. Before we start to look into the service we need to do initial setup. This setup includes configuring the recorder and setting up delivery channel.

I mentioned Config Service, Ideally it should be a service namespace, which has different boundaries for its constituent resource, namely, Configuration Resource and Compliance Resource. They are independent in a sense that one does not interfere other. AWS has two views for these two. Configuration Resource is point in time snapshot of resources configuration(describe api response) along with contextual attributes like account, region, AZ, event timestamps. Compliance resource is the compliance status and context (rule, account, and event timestamps)

Note: I have intentionally not included Aggregator here. It will the third box in above pic.

AWS have released SSM based remediation rules, we will discuss this in a different post.

Architectural landscape that is common and recommended is to have a central compliance account where you store Configuration from multiple accounts, Lambda runtimes for rules, config event hub (SNS) which in turn can broadcast it various downstream consumers. It would have been nice if we can enrich notification messages with custom attributes. AWS does not have that support and I guess it will be a feature request. Lambda runtime can be in the workload account but that will affect that account resource limits (lambda basically).

#aws-config #aws #compliance-services #amazon-web-services