AWS Config
AWS Config records the configuration of every supported resource over time as configuration items — snapshots taken whenever a resource changes — building a complete history of what each resource looked like on any date and what changed. On top of that history it evaluates rules that check configuration against your policies.
The contrast with CloudTrail is clean: CloudTrail tells you what API calls were made; Config tells you what the resources looked like before, during, and after.
Configuration Items
A configuration item is a JSON record of one resource's state at one moment, including its full configuration, its relationships to other resources (this instance attached to that volume), the change timestamp, and the correlated CloudTrail event. Items are delivered to an S3 bucket you own and queried through Config's API or Athena.
You enable Config per Region and, for organizations, through AWS Organizations, opting into the resource types you want recorded.
Rules and Conformance Packs
A rule evaluates configuration items. Managed rules (hundreds published by AWS, like s3-bucket-public-read-prohibited and rds-instance-public-access-check) enable with one call; custom rules are Lambda functions you write. Rules run on a schedule or are change-triggered, catching violations within minutes.
A conformance pack bundles rules into one deployable unit aligned with a framework (HIPAA, PCI DSS, NIST 800-53, FedRAMP) — a baseline of automated technical checks, not a complete compliance program.
Aggregation and Remediation
A Config aggregator consolidates configuration items and compliance findings from many accounts and Regions into one account — essential for organizations, where checking each account separately does not scale. Route findings to Security Hub for unified posture, and combine with EventBridge to fire a Lambda that auto-remediates a failed rule.
AWS Config — configuration state and drift over time, evaluated against compliance rules.
CloudTrail — the API-call audit trail — actions, not resulting configuration.
GuardDuty — active threat detection — Config is for posture, not live threats.
- Running Config in a single account or Region, leaving the rest as a compliance blind spot.
- Recording every resource type in every account when you do not need them all, driving up per-item cost.
- Expecting Config to detect active threats — it tracks configuration drift; use GuardDuty for threats.
- Leaving failed rules unrouted, so non-compliant resources sit unnoticed instead of flowing to Security Hub.
- Using Config for application configuration (feature flags, env vars) instead of AppConfig or Parameter Store.
- Forgetting an aggregator, so organization-wide compliance requires logging into each account separately.
- Enable Config in every Region of every account.
- Start with the FSBP conformance pack or the one matching your compliance framework, then add custom rules.
- Use a Config aggregator in a security or audit account for organization-wide visibility.
- Route findings to Security Hub and use EventBridge for automated remediation.
- Tune the recorder to exclude resource types you do not care about, to control cost.
- Tag rules with the policy or framework they enforce.
Knowledge Check
What does AWS Config record that CloudTrail does not?
- The configuration state of resources over time — what they looked like before and after a change
- The source IP address and user agent of each API call
- The identity of the IAM principal making each individual API call, along with the request timestamp
- Nothing — the two services record exactly the same data
What is a conformance pack?
- A bundle of Config rules deployed as one unit, often aligned with a compliance framework
- A set of CloudTrail trails deployed across an entire organization for centralized auditing
- A managed set of KMS encryption keys for a resource group
- A reusable CloudWatch dashboard template for resources
Why use a Config aggregator?
- To consolidate configuration and compliance findings from many accounts and Regions into one dashboard
- To reduce the number of configuration items each per-Region recorder captures and is ultimately billed for
- To encrypt the Config delivery channel's destination S3 bucket
- To replace the need for separate CloudTrail trails entirely
When is AWS Config the wrong tool?
- For real-time threat detection — that is GuardDuty's job; Config is for configuration drift and compliance
- For checking whether S3 buckets across the account block all public access
- For tracking the configuration change history of EC2 instances over time
- For continuously evaluating account resources against a PCI DSS compliance baseline and reporting any drift
You got correct