The content below is taken from the original ( AWS Config best practices), to continue reading please visit the site. Remember to respect the Author & Copyright.
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.
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 a common 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 60 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 two Config Rules that identify buckets that are publicly accessible.
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. Set the appropriate permissions for the IAM role assigned to AWS Config
An AWS Identity and Access Management (IAM) role lets you define a set of permissions. 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 update an IAM role, AWS Config automatically attaches the required permissions for you. But if you are using the AWS CLI to set up AWS Config or you are updating an existing IAM role, you must manually update the policy to allow AWS Config to access your S3 bucket, publish to your SNS topic, and get configuration details about your resources. For more details, please see Permissions for the IAM role assigned to AWS Config.
9. If you prefer to create an IAM role for AWS Config yourself, use the AWS managed policy AWSConfigRole and attach it to the 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 get configuration details as long as the role has this managed policy attached. Note: If you create or update a role using the AWS Management Console, AWS Config attaches the AWSConfigRole for you.
10. 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.
11. 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.
12. 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.
13. 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.
14. Create periodic 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.
15. 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.
16. 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.
17. Use Annotations.
For custom rules, while submitting put-evaluations, use “annotations” to add supplementary information about how the evaluation determined the compliance.
18. Don’t delete and re-create a rule in the same month.
AWS Config rules are charged a fixed amount per active rule per month. If you delete a rule and re-create it later in the month, you will be charged again for the rule. Note that the rule is considered active only if it gets triggered either by a periodic setting or a configuration change on an underlying resource. If there are no resources in an account, then the rule would not get triggered. Hence there is no real benefit in deleting a rule.
19. Use the data aggregation feature to aggregate compliance results 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.
20. 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.
About the Author
Sid Gupta is a Sr. 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 security best practices. In his spare time, he enjoys hiking, reading and spending time with his kids.