AWS Services
AWS Config
Understand AWS Config for resource configuration history, compliance rules, conformance packs, aggregators, remediation, and SAA-C03 governance scenarios.
After this, you will understand
AWS Config helps learners answer a different question from CloudTrail: not just who changed something, but what the resource configuration is and whether it complies.
AWS Config records resource configurations over time and evaluates them against rules.
Learners use CloudTrail for every governance question and miss Config's configuration timeline and compliance evaluation role.
Use AWS Config to record resource state, evaluate rules, aggregate compliance, and trigger remediation when resources drift.
Think before readingWhat is the simplest difference between CloudTrail and AWS Config?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Resource configuration history
- Configuration recorder
- Delivery channel
- Configuration items
- AWS Config rules
- Managed and custom rules
- Conformance packs
- Aggregators
- Remediation
- Config versus CloudTrail
1. Plain-English Mental Model
AWS Config records AWS resource configurations and evaluates them against rules.
If CloudTrail helps answer "who called this API?", AWS Config helps answer "what did this resource look like, when did it change, and is it compliant with our rules?"
The simple model is:
resource state changes -> AWS Config records configuration -> rules evaluate compliance
Examples:
- Is this S3 bucket public?
- Does this security group allow SSH from anywhere?
- Is encryption enabled?
- When did this route table change?
- Which resources are noncompliant across accounts?
AWS Config is a governance and compliance service. It is not a performance monitoring service and not the primary API audit trail.
2. Why This Service Exists
Cloud environments drift.
Engineers create resources manually. Deployment pipelines change settings. Security groups widen. Buckets become public. Encryption is disabled. Tags go missing. Backup settings change. In a multi-account environment, no one can inspect every resource by hand.
AWS Config exists to record resource configuration history and evaluate resources against desired rules.
For SAA-C03, AWS Config appears in questions about compliance, resource configuration history, detecting drift, checking whether resources follow policies, aggregating compliance across accounts and Regions, conformance packs, and remediation.
The exam often contrasts Config with CloudTrail and CloudWatch. Config is resource state and compliance. CloudTrail is API audit. CloudWatch is metrics and logs.
3. The Naive Approach And Where It Breaks
The naive approach is manual inspection:
open console -> click resources -> hope nothing changed
This breaks at scale. Resources exist across accounts, Regions, and services. Manual checks are inconsistent and not historical.
Another naive approach is to rely only on CloudTrail. CloudTrail can show that an API call happened, but it is not the best tool for asking "which resources are currently noncompliant?" or "what was the configuration timeline?"
Another mistake is enabling Config without thinking about scope and cost. Recording every supported resource and many rules in every account can create significant cost if not planned.
AWS Config needs deliberate recorder scope, rule design, aggregation, and remediation strategy.
4. Core Primitives
A configuration recorder records supported resource configuration changes.
A delivery channel sends configuration snapshots and history to an S3 bucket and can integrate with SNS.
A configuration item is a point-in-time representation of a resource configuration.
An AWS Config rule evaluates resources. Managed rules are provided by AWS. Custom rules can use Lambda or policy-as-code style approaches.
A conformance pack is a collection of rules and remediation actions deployed as a single package.
An aggregator collects Config data from multiple accounts and Regions for centralized visibility.
Remediation can run Systems Manager Automation documents or other actions to fix noncompliant resources.
5. Architecture Use Cases
Use AWS Config to detect public S3 buckets, unrestricted security groups, missing encryption, untagged resources, disabled logging, or noncompliant IAM settings.
Use conformance packs to deploy a standard compliance rule set across accounts or organizational units.
Use aggregators for central security or platform teams that need visibility across many accounts and Regions.
Use remediation to automatically fix known safe drift, such as enabling S3 Block Public Access or tagging missing values when policy allows.
Use Config history to investigate when a resource setting changed.
Pair Config with CloudTrail. Config shows the state change. CloudTrail can help identify who made the API call.
7. Security Model
AWS Config needs service-linked roles or service roles to record resource configuration.
Centralized Config architectures need account and Region planning. Aggregators require permissions to collect data.
The S3 delivery bucket should be protected because configuration history can be sensitive. It may reveal resource names, security settings, and infrastructure structure.
Use KMS encryption for delivery buckets where required.
Restrict who can modify Config rules, recorders, aggregators, and remediation actions. A user who can disable Config can hide future drift.
Remediation roles should be least privilege. Automatic remediation with broad permissions can cause damage.
8. Reliability And Resilience
AWS Config improves governance reliability by continuously recording and evaluating resources.
However, rules can be misconfigured, disabled, scoped too narrowly, or too noisy.
If Config is not enabled in a Region, resources in that Region may not be recorded.
Use organization-level deployment patterns where possible to avoid missing new accounts.
Test remediation before enabling automatic changes broadly.
Use CloudWatch alarms or EventBridge rules for critical compliance changes where immediate action is needed.
9. Performance And Scaling
AWS Config is managed, but rule evaluation volume matters.
Some rules evaluate on configuration changes. Others evaluate periodically. Large accounts with many resources can produce many evaluations.
Aggregators help centralize visibility but can also create query and operational scale considerations.
Custom Lambda rules must scale and handle event shapes correctly.
Conformance packs can deploy many rules at once, so understand evaluation volume and cost before broad rollout.
Config is not a low-latency enforcement firewall. It detects and evaluates. Preventive controls may require IAM, SCPs, service settings, or Control Tower guardrails.
10. Cost Model
AWS Config cost depends on configuration items recorded, rule evaluations, conformance packs, and related services.
Recording all resources across all Regions can be expensive if not planned.
Conformance packs can multiply rule evaluations.
Use recorder scope and rule choice deliberately. Do not enable expensive checks casually in sandbox accounts without retention or governance value.
Automatic remediation may invoke Systems Manager Automation or Lambda and add cost.
The cost is justified when it reduces compliance risk, investigation time, and configuration drift.
12. SAA-C03 Exam Signals
"Track resource configuration history" points to AWS Config.
"Evaluate whether resources comply with rules" points to AWS Config rules.
"Deploy a group of compliance rules together" points to conformance packs.
"Aggregate compliance across accounts and Regions" points to Config aggregators.
"Who changed the resource?" points to CloudTrail, often alongside Config.
"Metric alarm on CPU" points to CloudWatch, not Config.
"Prevent action before it happens" may point to IAM or SCPs, not Config detection after the fact.
13. Common Exam Traps
Do not confuse AWS Config with CloudTrail.
Do not confuse AWS Config with CloudWatch.
Do not assume Config prevents every bad change. It often detects and remediates after evaluation.
Do not enable rules without understanding cost and scope.
Do not forget Regions. Config must record where resources exist.
Do not give remediation roles broad power without careful testing.
15. Related Topics
Review AWS CloudTrail, Amazon CloudWatch, AWS Systems Manager, and Secure Cross-Account CloudTrail Logging.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.