Customize AWS Config resource tracking in AWS Control Tower environment

[Update on July/26/2023] AWS Config recorder has recently provided support for excluding resource types from configuration change tracking, prior to this change all resource types needed to be explicitly listed. This blog has been updated to incorporate that change and make it easier to operationally manage.

Some of our largest customers use AWS Control Tower to govern and secure their multi-account AWS environment. AWS Control Tower implements security best practices like enabling AWS Config during account enrollment, which monitors all supported AWS resources.

We heard from some of our customers that this configuration records the activity of specific resources that aren’t critical to their use cases. Therefore, we would like to filter out some unwanted recorded resources and keep the AWS Config costs under control. This feedback usually came from customers with a lot of ephemeral AWS resources. For many customers, collecting this information for audit and compliance purposes in their production environments is critical. They may not need the same logging level in the development or staging environments to operate efficiently.

AWS Config has pricing dimensions based on the number of resources recorded, evaluation rules, and conformance pack evaluation. For more details, refer to the Config pricing.

Directly updating AWS Control Tower managed resources may lead to drift in the Landing Zone. This drift could conflict with the future AWS Control Tower service updates or block account management operations. Therefore, we don’t recommend directly updating the AWS Control Tower managed resources, such as AWS Config, in individual accounts. In this post, you’ll learn how to work around making changes to the existing AWS Config service without getting impacted during account updates and creation.

As we mentioned earlier, some customers may exclude recording certain resource types in AWS Config if there’s no business case or benefit. AWS Config Rules and AWS Security Hub rely on recording resources by AWS Config. Therefore, it’s essential to understand the impact of not recording certain resource types before excluding them from the AWS Config recorder.

Before you deploy this solution, you must understand your billing information and see if this solution will help address your requirements. Refer to steps 1 & 2 in the next section of the post to:

1. Dive deeper into understanding AWS Config spend.
2. Deploy this solution to confine the recordings to a set of resources that you consider critical for tracking in your environment.

Understand AWS Config spend

Understanding spending often starts with AWS Cost Explorer. Therefore, we’ll start there and you can set the filter (on the right) to include only Service Config and Group by Usage Type.

In our test account, we have simulated a misconfiguration that had created over 2000 Amazon Simple Queue Service (SQS) queues instead of the required 20.

In the following image, you can see that AWS Config cost spiked on May 9 when we enabled daily view. The scale of the actual dollar value is small for illustrative purposes. Grouping the Usage Type tells us that the main cost driver is ConfigurationItemRecorded in the us-west-2 region.

Figure #1: Cost explorer grouped by Usage Type

You can further group this by linked accounts to understand which one of the linked accounts is contributing to the consumption. In this case, you can see a sudden spike towards AWS Config spend on May 9 and 10 was in the account raovi-2021-aft.

Figure #2: Cost explorer grouped by Linked Account

Finally, log in to the individual accounts and check the AWS Config dashboard to see the Configuration Items Recorded metric. You also can apply a resource type filter for further analysis to understand the resource type (or types) driving the costs up.

The simulated example in the following image shows a sudden spike of over 2000 AWS Config items being recorded, resulting in increased ConfigurationItemRecorded costs.

Figure #3: AWS Config usage metrics from the console

Figure #4: Filter by resource type for AWS Config usage metrics

Using the AWS Config console, you could further filter these metrics by resource type.

Solution overview

This solution deploys into your AWS Control Tower management account’s home region. It utilizes each managed account’s AWSControlTowerExecution role to update the AWS Config recorder resource types in all AWS Control Tower governed regions. AWS Control Tower creates this role during the account enrollment process. The default values in the  the provided CloudFormation template excludes few sample resources from AWS Config tracking. While deploying this solution, you can update this parameter to match your use-case.

Figure #5: Solution overview

This solution leverages the lifecycle events that AWS Control Tower generates for certain management operations, such as updating the Landing Zone or managing an account.

1. An Amazon Event Bridge rule is created, which initiates the “Producer” AWS Lambda function on events like UpdateLandingZone, CreateManagedAccount, and UpdateManagedAccount.
2. The Producer Lambda function gets the list of all account IDs and regions where the AWS Config recorder has been deployed by querying the CloudFormation stack set created by AWS Control Tower.
3. The Producer Lambda function then sends the list of account IDs and regions to the Amazon SQS queue.
4. Every message in the Amazon SQS queue invokes the Consumer Lambda function.
5. Consumer Lambda function assumes the AWSControlTowerExecution role in the member account and updates the AWS Config recorder with the resource list specified as an input parameter while deploying the solution.

For the other two events, namely CreateManagedAccount and UpdateManagedAccount, the Producer Lambda function gets the list of regions where AWS Control Tower deploys AWS Config recorder using CloudFormation stack sets for the specific account ID. This avoids unnecessary resource usage and minimizes costs.

Deployment steps

Clone the Git repository or download the files on your local workstation.

Create a CloudFormation stack in the management account in the Control Tower home region using the template.yml file downloaded from the git repository. There will be two parameters presented to you, and let’s go through each parameter one by one.

• ConfigRecorderExcludedResourceTypes parameter takes a list of all AWS Config resource types that needs to be excluded for tracking. ensure that the list matches your use-case and is syntactically correct (comma-separated values).
• ExcludedAccounts parameter takes a list of AWS accounts to exclude any changes made. Replace the account IDs of your Log archive and Audit account IDs, and optionally specify any other account ID you want to exclude from this solution.

Create the stack after specifying the parameters and wait for the stack to deploy successfully. The solution will run once after the stack status is create complete. You should see one invocation for the Producer Lambda function and several invocations for the Consumer Lambda function.

Verification

To verify the AWS Config recorder changes, log in to individual linked accounts and verify the Resource Types as reported on the AWS Config console. The list of resource types should match the CloudFormation Parameter ConfigRecorderResourceTypes you entered during stack creation.

Figure #7: AWS Config console general settings

Furthermore, you may check the metric for Configuration Items Recorded and apply the filter for the excluded resource type(s), which will end up with no count.

Cleanup

To clean up this solution, you can delete the CloudFormation stack that you have created in the deployment steps section above. Until the cleanup, the resources monitored would be limited to what you had specified as part of the deployment steps.

Conclusion

In this post, you learned how to identify increased spend on AWS Config in a dynamic environment with ephemeral resources. Moreover, you learned how to exclude recording resource types that don’t provide business value. This method avoids impacting the existing AWS Control Tower setup, future Landing Zone updates, and any account management functions.

To gain hands-on experience with AWS Control Tower and AWS Config, please try out our Control Tower workshops.

Authors: