AWS Config records the configuration state of supported AWS resources in an account and Region. Its configuration items (CIs) let you inspect recorded state over time, while AWS Config rules evaluate that state against conditions you define. The coverage depends on the resource types AWS Config supports, their availability in each Region, and the scope and frequency of your configuration recorder.

Use AWS Config to answer questions such as “What configuration did this resource have?” and “Does its recorded configuration match this rule?” Pair it with services such as CloudTrail when you also need API activity and request identity.

Choose AWS Config's scope first

AWS Config is regional. Set up and verify recording in each account and Region you need to cover. A customer-managed configuration recorder specifies which supported resource types to record. The delivery channel is required and sends configuration history and snapshots to Amazon S3; an Amazon SNS topic is optional if you want notifications. An account can also have service-linked recorders whose scope is set by the AWS service that uses them.

  1. Check coverage. Review the current AWS Config supported resource types and relationships list and its Regional coverage information.
  2. Select resource types. You can record all supported resource types or choose specific types. Some global resource types are recorded only in their home Region, so account for those when choosing where to look for them.
  3. Set recording frequency. Choose continuous recording for each detected configuration change, or daily recording for the most recent state over a 24-hour period when it differs from the previous CI. Daily frequency is not available for AWS::Config::ResourceCompliance, AWS::Config::ConformancePackCompliance, or AWS::Config::ConfigurationRecorder. AWS Firewall Manager depends on continuous recording, which AWS recommends when you use Firewall Manager. See the recording guidance for current limitations.
  4. Configure delivery and permissions. Assign the recorder an appropriate IAM role and configure the S3 delivery channel. Add SNS only if your workflow needs notifications.
  5. Verify the result. Check that the recorder is running and that recent CIs appear for the resource types and Regions in scope.

What the resource inventory includes

AWS Config supports many resource types, including EC2 instances, EBS volumes, VPCs, security groups, S3 buckets, IAM resources, and databases. The supported list changes over time, and not every resource type is available in every Region. A resource type must also be included in the recorder's scope before AWS Config records its configuration. Check the live coverage list instead of assuming that “all resources” means every AWS service or object in an account.

AWS Config can record relationships between certain supported resource types. For example, it can show that an EBS volume is attached to an EC2 instance. The relationship list is type-specific: it is not a complete dependency map, data-flow diagram, or calculation of effective IAM access. Check the relationship column in the supported-resource documentation for the pairs you need to investigate.

Read configuration history and correlate changes

A configuration item captures a resource's recorded attributes at a point in time. AWS Config adds items as it detects changes, and the resource timeline lets you compare those states and review creation or deletion history.

You can request history with the AWS CLI:

aws configservice get-resource-config-history --resource-type AWS::EC2::Instance --resource-id i-0123456789abcdef0 --region us-east-1

Replace the example resource ID and Region with values from your account. The get-resource-config-history command returns paginated results, and each API request can cover at most seven days. Use time bounds and pagination when retrieving a longer period.

Add context with related services

Correlate state changes with CloudTrail

AWS Config records resource configuration state. CloudTrail records API activity, including details such as who made a request, when it happened, and the request source. AWS Config can correlate configuration changes with related CloudTrail events, but the resource history alone is not an API audit trail.

Compare stack state with its template

If you manage a resource with CloudFormation, AWS Config history answers what recorded states were observed; CloudFormation drift detection compares supported stack resources with the properties declared in a template. Those views help answer different questions. For more on the template comparison, see our CloudFormation drift detection guide.

Evaluate recorded configurations with rules

AWS Config rules evaluate resource configurations and report a compliance result such as COMPLIANT or NON_COMPLIANT. AWS managed rules cover common checks. For custom checks, you can use a Lambda-backed rule or write an AWS Config custom policy rule in CloudFormation Guard. Rules can evaluate matching configuration changes or run on a periodic schedule.

A rule result reports whether its condition passed; it does not itself change a resource or certify an account against a regulation. To take action on a noncompliant resource, configure remediation separately. AWS Config supports manual remediation and automatic remediation, commonly through an AWS Systems Manager Automation document. Review the action and permissions because automatic remediation can modify resources. See AWS Config's remediation guidance.

Group checks with conformance packs

A conformance pack is a YAML template that groups AWS Config rules and may include remediation configurations. You can deploy a pack to an account and Region or across an AWS Organization. AWS sample packs that refer to standards or benchmarks are starting points for governance checks; they do not guarantee that you meet a standard or pass an assessment. Adapt the checks to your actual requirements and validate coverage with the people responsible for compliance.

Aggregate data across accounts and Regions

An AWS Config aggregator collects configuration and compliance data from selected source accounts and Regions into a central view. The aggregator is read-only: it cannot deploy rules or change source resources. AWS Config must already be enabled and recording in each source account and Region; creating an aggregator does not start source recorders. For individual source accounts, grant the required aggregation authorization. Organization aggregation uses AWS Organizations integration.

Understand retention and cost

By default, AWS Config retains configuration items for seven years (2,557 days). You can set its history retention period from 30 to 2,557 days. This controls how far back AWS Config history and APIs can return configuration items. Files delivered to S3 have separate storage and lifecycle settings; changing AWS Config retention does not apply an S3 lifecycle policy to those files. See the AWS Config retention documentation for the exact behavior.

AWS Config charges are based on the number of configuration items recorded, active rule evaluations, and conformance pack evaluations, with prices varying by Region. Daily recording can reduce the number of items for frequently changing resources, but it also reduces history detail; choose the frequency that meets your audit and operational needs. Budget separately for S3 storage and any other services used for notifications or remediation. Check the current AWS Config pricing page before expanding recorder scope or deploying many rules and packs.

Use AWS Config within its recorded scope

AWS Config is most useful when you know which resource types and Regions it covers, select a recording frequency that preserves the history you need, and write rules for specific configuration questions. Use CloudTrail for the API events behind a change, and treat aggregators, remediation, retention, and conformance packs as separate parts of the design.