AWS Config Setup: Recording Resources and Evaluating Compliance at Scale

AWS Config is deceptively easy to enable and surprisingly easy to misconfigure. You can click through the console wizard in five minutes and walk away believing your environment is fully monitored — when in reality you are recording a fraction of your resource types, only in the regions you happened to think of, with findings delivered to an S3 bucket nobody checks. The false confidence that follows is more dangerous than no monitoring at all.

This guide covers everything that matters for a production-grade Config deployment: which resource types to record, how to configure the delivery channel, how to set up multi-account aggregation, the cost implications of different recording strategies, and the operational gaps to watch for once everything is running.

How AWS Config Works

Config operates through three core components: the configuration recorder, the delivery channel, and the rule evaluation engine. The recorder continuously monitors your AWS resources and captures configuration snapshots whenever a change is detected. The delivery channel specifies where those snapshots go — an S3 bucket for history and an optional SNS topic for notifications. Rules then evaluate the recorded configurations and produce COMPLIANT or NON_COMPLIANT findings.

The critical thing to understand is that Config is regional. You must enable it independently in every region where you run workloads — or use AWS Organizations-level StackSets to do it centrally. A Config setup enabled only in us-east-1 knows nothing about your eu-west-1 resources. This is the most common misconfiguration that leads to genuine coverage gaps.

Enabling Config in All Regions

Manual per-region setup does not scale. For any organization beyond a handful of accounts and regions, use AWS CloudFormation StackSets deployed from the Organizations management account. The StackSet targets all accounts in the organization and all active regions, ensuring consistent Config configuration everywhere workloads run.

The CloudFormation template should create the configuration recorder, delivery channel, and S3 bucket policy in one shot. Key parameters to configure per deployment: the recording group (all resources or specific resource types), the IAM role that Config uses to read resource configurations (AWSServiceRoleForConfig is the managed service-linked role), and the target S3 bucket in your centralized logging account.

If you prefer the CLI approach, aws configservice put-configuration-recorder and aws configservice put-delivery-channel are the two commands that matter. Run these in every region via a script that iterates through the output of aws ec2 describe-regions --all-regions. Do not rely on a static region list — it will be stale by the time new regions launch.

What to Record: All Resources vs. Specific Types

Config's recording group determines which resource types it tracks. You have two options: record all supported resource types (including global resources like IAM), or specify a subset. The default is to record everything, which is almost always the right choice for security and compliance purposes — but it has cost implications that deserve planning.

If you record all resource types, Config tracks over 300 resource types as of 2026. Every configuration change generates a configuration item stored in S3 and billed per item recorded. For large environments with frequent deployments, this can be substantial. The formula is roughly: (number of configuration changes per day) × (cost per configuration item recorded) × (number of regions). AWS charges $0.003 per configuration item recorded.

A pragmatic middle ground for cost control: record all resource types by default, but exclude high-churn resources that have low security relevance. Lambda function versions are a common exclusion — each deployment creates a new version, generating configuration items with minimal compliance value. Exclude them explicitly in the recording group configuration to reduce noise and cost without material security coverage loss.

Global resources — IAM users, roles, policies, and groups — are only recorded in one region per account to avoid duplicate items. Enable global resource recording in your primary region and disable it everywhere else. Failing to set this correctly results in duplicate IAM findings across regions, which inflates counts and makes compliance scoring unreliable.

Delivery Channel: S3 Bucket and SNS Configuration

The delivery channel specifies where Config sends configuration history, configuration snapshots, and compliance change notifications. The S3 bucket is mandatory; the SNS topic is optional but recommended.

Your Config delivery S3 bucket should live in a dedicated logging account, separate from the account being monitored. Use a bucket policy that grants Config's service principal (config.amazonaws.com) the PutObject permission on a prefix scoped to the source account ID. Use S3 Object Lock in compliance mode and set a retention period aligned to your compliance requirements — PCI DSS requires one year minimum, many frameworks require seven years. Enable S3 server-side encryption with KMS and disable public access at the bucket and account level.

The SNS topic connected to the delivery channel receives compliance change notifications — when a resource transitions from COMPLIANT to NON_COMPLIANT or vice versa. Wire this SNS topic to a Lambda function or EventBridge pipe that routes high-severity compliance changes to your security alerting platform. This turns Config from a passive compliance reporter into an active compliance alerting system.

Multi-Account Aggregator vs. Per-Account Setup

A Config aggregator collects compliance data from multiple accounts and regions into a single account, providing an organization-wide compliance view. You have two aggregator types: account-level aggregators (manually specified list of accounts) and organization-level aggregators (automatically includes all accounts in the AWS Organization).

Use the organization-level aggregator. It requires authorization from the management account and automatically enrolls new accounts as they join the organization — you do not need to update a static account list. Deploy the aggregator in a dedicated security or audit account, not the management account itself. The management account has broad access that makes it a higher-value compromise target; keeping monitoring infrastructure in a separate account with minimal permissions limits blast radius.

An important limitation: the aggregator provides read-only compliance visibility. It does not push rules to member accounts. Config rules must be deployed independently in each account — typically via StackSets. The aggregator then collects and aggregates their compliance results. This two-step architecture (StackSets for rules, aggregator for visibility) is the correct pattern for organization-scale Config management.

Configuration Recorder vs. Config Rules

These are often confused. The configuration recorder is the data collection mechanism — it tracks what your resources look like at any point in time. Config rules are the evaluation mechanism — they assess whether what the recorder captures meets your compliance requirements. You need both, and they serve different purposes.

You can have a fully operational configuration recorder with zero rules deployed. In that case, you get historical configuration tracking and the ability to query past resource states (useful for incident investigation), but no compliance evaluation and no COMPLIANT/NON_COMPLIANT findings. Conversely, rules cannot function without the recorder — they evaluate the data the recorder captures. Enable the recorder first, then layer rules on top.

Cost Estimation

Config pricing has three components: configuration items recorded ($0.003 each), active Config rule evaluations ($0.001 per evaluation after the first 100,000 per month), and conformance pack evaluations ($0.0012 per evaluation after the first 100,000 per month). For a medium-sized AWS environment — say, 500 actively changing resources across five regions with 50 Config rules — expect roughly $150–400 per month per account before aggregator costs.

The aggregator itself adds a charge for the compliance data it pulls: $0.0012 per compliance evaluation collected. For an organization with 100 accounts, each running 50 rules evaluating 200 resources, the aggregator overhead is meaningful but typically small relative to the per-account recording costs.

To estimate your specific costs before enabling Config at scale, enable it in a single non-production account for two to four weeks and measure the configuration item volume. Scale that number by region count and account count to project total spend. This exercise also surfaces high-churn resources that are candidates for exclusion from the recording group.

Related Reading

• Essential AWS Config rules — the managed rules that deliver the highest security signal
• Config conformance packs — deploying CIS, PCI DSS, and NIST frameworks in one command
• Multi-account Config aggregator — unified compliance visibility across your organization
• Compliance monitoring and risk scoring — turning Config findings into an actionable health score

FAQ

Does AWS Config record every resource change in real time?

Config records changes continuously, but there is a short delay between when a resource changes and when the configuration item appears. For most resource types this is seconds to minutes, not hours. Rule evaluations triggered by configuration changes happen shortly after the new configuration item is recorded. Periodic evaluations run on a schedule you configure — every 1, 3, 6, 12, or 24 hours. For real-time security event detection, pair Config with EventBridge rules that trigger on API calls directly rather than relying solely on Config's change detection.

Can AWS Config record resources in all regions automatically?

Not automatically — Config must be enabled per region. The most reliable approach is deploying Config via CloudFormation StackSets from the Organizations management account, targeting all organizational accounts and all enabled regions. This ensures consistent coverage and automatically applies to new regions when you start using them.

What IAM role does AWS Config need?

Config uses the AWSServiceRoleForConfig service-linked role by default. This role has read permissions across all supported AWS services, allowing Config to describe and record resource configurations. For the delivery channel, Config also needs s3:PutObject on the target bucket and sns:Publish on the target topic. If you are using a cross-account S3 bucket, the bucket policy must explicitly grant Config's service principal access.

How do I exclude specific resource types from Config recording?

In the configuration recorder settings, choose "Record all resources" then specify an exclusion list of resource types to skip. The exclusion list accepts resource type strings in the format AWS::Lambda::LayerVersion or AWS::CloudFormation::Stack. Alternatively, choose "Record specific resource types" and enumerate only the types you want tracked — this is more explicit but requires maintenance as you adopt new AWS services.

What is the difference between Config snapshots and configuration history?

Configuration history is the continuous stream of configuration items generated every time a resource changes — this is always on when the recorder is running. Configuration snapshots are point-in-time exports of the current configuration state for all recorded resources, delivered to S3 on demand or on a periodic schedule. Snapshots are useful for audit purposes and bulk analysis. History is what powers rule evaluations and the Config timeline view in the console.