AWS Config best practices

AWS Config is a service that maintains a configuration history of your AWS resources and evaluates the configuration against best practices and your internal policies. You can use this information for operational troubleshooting, audit, and compliance use cases. In this blog post, I share best practices on how to use AWS Config as a tool for enabling governance across your enterprise.

Configuration Recording best practices

1. Enable AWS Config in all accounts and Regions.
This is an industry best practice recommended by the Center for Internet Security (CIS). By using AWS Config you can audit the configuration of your AWS resources and ensure that they comply with configuration best practices. You can use AWS CloudFormation StackSets to enable AWS Config in multiple accounts and Regions using this sample CloudFormation template.

2. Record configuration changes to ALL resource types.
When you are setting up AWS Config, select “All resources” for the resource types that need to be recorded in AWS Config. This ensures that you have a comprehensive configuration audit in place because AWS Config supports more than 100 different resource types in AWS. New resource types would automatically be recorded via this setting.

3. Record global resources (such as IAM resources) only in one Region.
This ensures that you don’t get redundant copies of IAM configuration Items in every Region. It also controls your costs.

4. Ensure that you have a secure Amazon S3 bucket to collect the configuration history and snapshot files.
Your Amazon S3 bucket receives configuration history and configuration snapshot files, which contain details for the resources that AWS Config records. This S3 bucket should not be publicly readable or writeable. Follow S3 security best practices and turn on the S3 best practices conformance pack to identify buckets that are publicly accessible. Also note that if you delete your S3 bucket and create a new one, make sure to update the setting in AWS Config to continue receiving these snapshots and history files.

5. Specify an Amazon S3 bucket from another (central IT) account for centralized management of history files and snapshots.
This is especially valuable in an enterprise scenario where a central IT/InfoSec account needs to collect data from multiple accounts.

6. Specify an Amazon Simple Notification Service (Amazon SNS) topic from another (central IT) account for centralized management of configuration and compliance notifications.
AWS Config streams all configuration and compliance change notifications to an SNS topic. Use a central topic to gather notifications from multiple accounts on your enterprise in case they need to be processed by a central IT/InfoSec team.

7. Use Amazon CloudWatch Events to filter AWS Config notifications and take action.
AWS Config streams all configuration and compliance change notifications to CloudWatch Events, in addition to SNS. This means that you can use the native filtering capabilities in CloudWatch Events to filter AWS Config events so that you can route specific types of notifications to specific targets. For example, you can send compliance notifications for specific rules or resource types to specific email addresses, or route configuration change notifications to an external ITSM/CMDB tool.

8. Use the AWS Config service linked role to allow Config to record resource configuration changes.                                                                                                                                                                                                                                                                                                        A service-linked role (SLR) makes setting up AWS Config easier because you don’t have to manually add the necessary permissions for Config to record the configuration of AWS services that Config supports. AWS Config uses the service-linked role named AWSServiceRoleForConfig. AWS Config uses this service-linked role to call other AWS services on your behalf. The permissions policy for this role contains read-only and write-only permissions on the AWS Config resources and read-only permissions for resources in other services that AWS Config supports. For more information, see Supported Resource Types. When setting up AWS Config via the console, this SLR is automatically created by Config if you select the option to use the Config SLR instead of your own IAM role.

9. If you prefer to create an IAM role for AWS Config yourself, use the AWS managed policy AWS_ConfigRole and attach it to your IAM role.
AWS updates this IAM policy each time AWS Config adds support for an AWS resource type. This means that AWS Config will continue to have the required permissions to record configuration data of supported resource types as long as the role has this managed policy attached.

10. Set the appropriate permissions for the IAM role assigned to AWS Config.
AWS Config assumes the role that you assign to it to write to your S3 bucket, publish to your SNS topic, and to make Describe or List API requests get configuration details for your AWS resources. When you use the AWS Config console to create or pick an existing service linked role for Config, AWS Config automatically attaches the required permissions for you. But if you are using the AWS CLI to set up AWS Config or if you are using your own IAM role, you must manually update the S3 bucket policy to allow AWS Config to access your S3 bucket, the access policy on your SNS topic to allow Config to publish messages, and the IAM policy to allow Config to get configuration details about your resources. For more details, please see Permissions for the IAM role assigned to AWS Config, Required Permissions for the Amazon S3 Bucket When Using Service-Linked Roles and Required Permissions for the Amazon SNS Topic When Using Service-Linked Roles.

11. Ensure that the SNS topic permissions are restricted to only allow AWS Config to publish messages to it.
AWS Config must have permissions to send notifications to an SNS topic. If you use the AWS Config console to set up your delivery channel with a new SNS topic or you choose an SNS topic that already exists in your account, these permissions are automatically added to the SNS topic. However, if you specify an existing topic from another account or you set up your delivery channel using the API, you must make sure that the topic has the correct permissions.

12. Turn on periodic snapshots with a minimum frequency of once per day.
This ensures that the latest configuration state of all resources in your account is backed up daily.

13. Use the AWS CloudTrail Lookup API action to find the API events that occurred in the timeframe when the configuration change occurred.
The AWS Config console uses the Lookup Events API action to retrieve the API events from AWS CloudTrail around the timeframe when a configuration change was recorded in AWS Config. If you are consuming the AWS Config data programmatically, use this API action to correlate the configuration changes detected in AWS Config to the API events in AWS CloudTrail.

14. If you have your own third party ITSM or CMDB solution like ServiceNow or Jira Service desk, use the AWS Service Management connector to feed Config data into those systems.
For more details, refer to https://docs.aws.amazon.com/servicecatalog/latest/adminguide/integrations-servicenow.html and https://docs.aws.amazon.com/servicecatalog/latest/adminguide/integrations-jiraservicedesk.html

15. Identify resources that are undergoing the most configuration changes on a routine basis to control costs.
Since AWS Config tracks changes to the configuration of resources, resources that are undergoing a lot of mutations may end up incurring higher than normal Config recording charges. Use this blogpost to identify resources that are changing frequently and resource types that underwent most changes during the month: https://aws.amazon.com/blogs/mt/identifying-resources-most-configuration-changes-aws-config/

Compliance evaluation best practices

16. Use Conformance Packs in your account as well as across your organization.
Use conformance packs to quickly deploy a pack of Config rules and remediation actions in your account. You can also deploy a pack centrally from a master or a delegated admin account across an entire organization in AWS Organizations. In this scenario, the pack and its contents are immutable, meaning member accounts cannot modify or delete the conformance pack. Here is a useful blogpost: https://aws.amazon.com/blogs/mt/deploying-conformance-packs-across-an-organization-with-automatic-remediation/    

17. Leverage the sample templates for conformance packs as a starting point to quickly bootstrap your accounts.
AWS Config offers multiple conformance pack sample templates to run checks against AWS service best practices, industry benchmarks (such as CIS) and regulatory requirements (PCI, HIPAA, FedRamp, NIST-800 etc.). Sample conformance pack templates are intended to help you create your own conformance packs with different or additional rules, input parameters and remediation actions that are most appropriate for your resources. The sample conformance pack templates, including those related to specific compliance standards and industry frameworks, are not designed to, and do not, ensure your compliance with any such standard or framework and it is your responsibility to ensure any such compliance. Note: Using a sample conformance pack template neither replaces your need for internal efforts to ensure compliance with any applicable standard nor guarantees that you will pass any compliance assessment. 

18. Use AWS Security Hub for an opinionated set of security checks and AWS Config conformance packs for any customization or building your own compliance pack.
If a compliance standard, such as PCI-DSS, is already present in AWS Security Hub, then the fully managed AWS Security Hub service is the easiest way to operationalize it. However, if you want to assemble your own compliance or security standard, which may include security, operational or cost optimization checks, AWS Config conformance packs are the way to go. AWS Config conformance packs simplify management of AWS Config rules by packaging a group of AWS Config rules and associated remediation actions into a single entity. This packaging simplifies deployment of rules and remediation actions across an organization. It also enables aggregated reporting, as compliance summaries can be reported at the pack level. You can start with the AWS Config conformance samples we provide, and customize as you see fit.

19. Use the AWS Config Rule Development Kit (RDK) for authoring custom rules.
The RDK simplifies the authoring experience and validates the rule for various resource types.

20. Create change-triggered custom rules for resource types supported in AWS Config.
When creating custom rules, create change–triggered rules versus periodic rules to ensure that your resources get evaluated for compliance every time there is a configuration change. For more information, see AWS Supported Resource Types and Resource Relationships.

21. Create periodic custom rules for resource types not supported in AWS Config.
Even though AWS Config tracks changes for a limited number of resources today, you can still create periodic AWS Config rules to evaluate the configuration of resources that are not yet supported in AWS Config, by using custom rules.

22. In a multi-account scenario involving custom rules, centralize the Lambda function in one account for easier management.
Here is a use blog to centrally manage conformance packs: https://aws.amazon.com/blogs/mt/manage-custom-aws-config-rules-with-remediations-using-conformance-packs/

23. Use the AWS Config Rules repository, a community-based source of custom AWS Config rules.
This new repository gives you a streamlined way to automate your assessment and compliance against best practices for security of AWS resources.

24. Config rules and conformance packs that have global resources in scope (such as IAM), should only be deployed in one region to avoid costs and API throttling.
IAM being a global service, we recommend having the rules leveraging IAM resources to be present only in one Region, similar to recording global resources (such as IAM resources) only in one Region. This applies to regular Config rules, organizational Config rules, as well as rules created by other AWS services (like Security Hub and Control Tower). Some of the rules that fall in this category include: mfa-enabled-for-iam-console-access, iam-user-mfa-enabled, access-keys-rotated and iam-user-unused-credentials-check.

25. Use Annotations.
For custom rules, while submitting put-evaluations, use “annotations” to add supplementary information about how the evaluation determined the compliance.

26. Ensure judicious usage of “DeleteResults” and “Re-evaluate”rules functionalities for your config rules to avoid spike in AWS Config billing.
AWS Config stores compliance state changes of resources as evaluated by AWS Config Rules. The annotation for this resource type is “AWS::Config::ResourceCompliance”. Whenever you  “Delete results” (DeleteEvaluationResults API) and “Re-evaluate” a config rule (StartConfigRulesEvaluation API) for a rule there will be a new CI created for this resource type to record the latest compliance state. This could impact your AWS Config CI recording costs if these actions are called on a frequent basis.

Cross-account aggregation and advanced query best practices

27. Use the data aggregation feature to aggregate resource configuration and compliance data into a central account.
This feature allows you to aggregate AWS Config Rules compliance statuses from multiple accounts and Regions into a single account to provide an organization-wide view of your compliance. It also aggregates the current configuration state of your resources across those accounts and Regions. Use the get-aggregate-resource-config API to view the current configuration of any resource via a single API endpoint, instead of calling the Describe APIs of individual services.

28. Create an organizations-based aggregator to aggregate AWS Config data from your entire organization.
This simplifies the setup experience, and it also automatically updates the aggregator when accounts join/leave your organization.

29. Use the Advanced queries feature to centrally query your resource configuration and compliance data.
This feature provides you an easy mechanism to query the current configuration state of your AWS resources from a central account. For example, using this query capability, you can retrieve a list of Amazon Elastic Compute Cloud (Amazon EC2) instances of a particular size, Amazon Elastic Block Store (Amazon EBS) volumes that are not attached to an Amazon EC2 instance, or resources that have encryption disabled. This capability works across accounts, Regions, and organization in AWS Organizations.

30. Use Amazon Athena to query the historical state of your resources.
Since advanced query (mentioned above) only queries current state data, you can use Amazon Athena to query the Config history files. Here is a useful blogpost: https://aws.amazon.com/blogs/mt/how-to-query-your-aws-resource-configuration-states-using-aws-config-and-amazon-athena/

About the Author

Sid Gupta is the Principal Product Manager for AWS Config. AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Sid enjoys working with customers and help them implement cloud governance best practices. In his spare time, he enjoys hiking, reading and spending time with his kids.