AWS Config

Unlike AWS CloudTrail, AWS Config is a per-region service. However, we can still aggregate Config results across all regions and even across AWS accounts within an organization account. With AWS Config, we can track the compliance, configuration, and CloudTrail API calls of supported AWS resources over time.

We can also set up SNS notifications for critical configuration changes using AWS EventBridge or AWS Lambda. AWS Config logs are usually recorded within S3 buckets that can be queried and analyzed using AWS Athena.

Key concepts

Here’s a list of key AWS Config concepts that we need to know:

Recording configuration changes

The following are the most important concepts related to recording configuration changes that we need to be aware of:

• Configuration recorder: The configuration recorder refers to AWS Config’s component for continuously detecting and recording any AWS resource configurations within our AWS account. We can also specify what resource types we want to monitor for more customized monitoring.

• Configuration items: A configuration item (CI) refers to the configuration of an AWS resource at a specific moment. Every time a resource’s configuration changes, a new configuration item is created detailing that change. Configuration items include the metadata, such as the AWS resource ID, the configuration change time, and the relationship of the changed resource with other AWS resources.

• Configuration history: The configuration history refers to a particular AWS resource’s chronological set of configuration items. It allows us to track changes and review the configuration of a resource over time.

Config rules

Config rules refer to any rules we define in AWS Config for evaluating resource configurations. AWS Config determines whether a resource’s configuration is compliant or non-compliant based on whether it passes the Config rule checks.

The AWS Config rule can have one of the following evaluation statuses at only one point:

• COMPLIANT: The AWS resource has passed the compliance check for the Config rule.

• NON_COMPLIANT: The AWS resource has failed the compliance check for the Config rule.

• ERROR: The Config rule has an invalid parameter, the wrong parameter type, or formatting issues because of which the rule cannot be evaluated on a resource.

• NOT_APPLICABLE: This status is displayed for any AWS resources that have been filtered out in the Config rule because the rule logic cannot be applied to it. For example, the AWS-managed alb-desync-mode-check rule is only applied to an application load balancer and not applicable to network load balancers and gateway load balancers.

AWS Config rules are of two types:

• AWS-managed Config rules: These are pre-defined yet customizable rules created and managed by AWS Config.

• Custom Config rules: We can create them from scratch and customize them per our organization’s needs. The custom rules are usually created with the help of AWS Lambda.

Remediations

Remediations in Config rules refer to automated or manual actions that are triggered when the resource configuration change violates the Config rule. These actions are also referred to as remediation actions. With these actions, we can reconfigure the AWS resources to make them compliant. Here’s an example of using a Config remediation action to detect EC2 security groups with open SSH connection access and remove the associated inbound rule:

Remediation actions can be either automated or manual. For manual remediation actions, we have to either go to the AWS Management Console or, through an API call, manually trigger a pre-defined remediation action for any non-compliant resources under a specific Config rule.

For automated remediation actions, we need to also utilize SSM automation documents. We can specify and use both AWS-managed or custom automation documents. We can also have automation documents that invoke a Lambda function for additional actions.

We can set Config remediation retries to run remediation actions on a resource that is still non-compliant after an automated remediation action has been executed.

Conformance packs

We can define a conformance pack as a collection of Config rules and associated remediation actions that we can deploy and manage as a single entity. We can manage conformance within a single region or account and across all accounts and regions in an organization.

To create a conformance pack, we must create a YAML template with the list for custom/AWS-managed config rules and remediation actions and then deploy it on AWS Config to create a conformance pack.

How AWS Config works

Here’s a breakdown of how the AWS Config service normally works:

• We enable AWS Config to start discovering AWS resource configuration changes. Simultaneously, we can set up any Config rules at this stage, but these can also be set up later.

• The configuration recorder records any configuration changes and records them in a storage resource like an S3 bucket.

• In case we already have any Config rules set up, we can see the records of any AWS resource configuration changes and which of these resources are compliant.

• Non-compliant resources automatically trigger automated remediation actions and are constantly triggered until those resources become compliant. Manual remediation actions need to be triggered automatically by us.

• We can integrate AWS Config with the AWS EventBridge or AWS Lambda services to send SNS notifications when a non-compliant resource is identified in a Config rule.

Example: Tracking EC2 configuration changes

Let's consider an example of a Config rule dictating that all EC2 instances must be configured with the t2.micro instance type to be compliant. We also perform the appropriate remediation action as well as send the appropriate SNS notification:

Here, a user updates the instance type of an EC2 instance to m4.xlarge from t2.micro. This configuration change is recorded and saved by AWS Config in an S3 bucket.

Based on custom Config rules, AWS Config also identifies that the configuration change has made the EC2 instance resource non-compliant. In response, it triggers an SNS notification using EventBridge to the administrator mailing list and also triggers an automated remediation action to change the instance type back to t2.micro via the SSM automation documation.

Use cases

Here are some use cases of AWS Config:

• Record resource configuration changes: Discover all AWS resources within our account and record any configuration changes on those resources.

• Troubleshoot operational issues: Recording configuration changes provide insights to quickly troubleshoot any operational issues.

• Deploy a compliance-as-code framework: We can manage our compliance requirements as code by using Config rules remediation actions that will allow for automatic evaluations of resource configuration across our account.

• Continually monitor and analyze security status: With Config, we can quickly identify resources with configurations that pose a security risk and potential vulnerability. We can also review the configuration history to identify any security incidents.

Benefits of AWS Config

Here are some of the benefits of the AWS Config service:

• AWS Config helps us monitor, record, and evaluate configuration changes continuously, making it easier to track these changes.

• AWS Config allows us to evaluate the compliance of our AWS resource configurations according to our organization’s rules and regulations.

• AWS Config can be integrated with AWS Systems Manager to automate the remediation of non-compliant resources.

Understanding costs

AWS Config costs are based on the number of configuration items (CIs) recorded. A configuration item is created whenever AWS Config detects a change in a tracked resource. More resource configuration changes mean more configuration items, which means we incur higher costs with AWS Config.

This lesson taught us about AWS Config, its potential benefits, and how it helps record configuration changes with Config rules and make the appropriate counter changes using remediation actions.