AWS Config —
Configuration Compliance & Drift Detection
AWS Config continuously records the configuration of every resource in your account, evaluates compliance against desired settings, and tracks every change over time. It answers: "Is my infrastructure configured correctly — and when did it change?"
What is AWS Config?
AWS Config is a configuration recording and compliance evaluation service. It continuously captures the configuration state of your AWS resources, maintains a complete history of changes, and evaluates whether resources comply with your desired configurations.
Building Inspector
- Photographs every room at regular intervals
- Checks each room against building codes
- Flags violations: "this exit is blocked"
- Maintains a history: "Room 3 changed on March 5"
- Doesn't fix anything — only reports
AWS Config
- Records configuration of every resource continuously
- Evaluates resources against Config Rules
- Flags non-compliance: "S3 bucket is public"
- Maintains history: "SG changed at 3 AM by user alice"
- Can trigger auto-remediation via SSM
| Service | What It Answers | Focus |
|---|---|---|
| AWS Config | What is the resource's configuration? Is it compliant? | Configuration state & compliance rules |
| CloudTrail | Who did what, when, from where? | API activity audit trail |
| CloudWatch | How is the resource performing? | Metrics, logs, alarms, dashboards |
Config = "Is the S3 bucket currently public, and when did it become public?" CloudTrail = "Who made the S3 bucket public?" CloudWatch = "How many requests is the S3 bucket receiving?" Config tells you what changed, CloudTrail tells you who changed it, CloudWatch tells you how it's performing.
| Term | Definition |
|---|---|
| Configuration Item (CI) | Point-in-time snapshot of a resource's configuration (type, ID, state, relationships, tags) |
| Configuration Recorder | The service that captures CIs when resources change (must be enabled) |
| Configuration History | Collection of CIs for a resource over time — full change timeline |
| Configuration Snapshot | Complete picture of ALL resources' configurations at a point in time (delivered to S3) |
| Delivery Channel | S3 bucket (required) + optional SNS topic where Config sends data |
| Config Rule | A compliance check that evaluates whether a resource's CI meets desired configuration |
| Remediation Action | An SSM Automation document that fixes non-compliant resources |
- "Is the security group configured correctly?" → AWS Config
- "Who changed the security group?" → CloudTrail
- "How is the instance performing?" → CloudWatch
- "When did the S3 bucket become public?" → AWS Config (configuration timeline)
- "Config needs to be enabled" → Config Recorder is NOT on by default (unlike CloudTrail Event History)
- "Configuration data stored where?" → S3 bucket (you configure the delivery channel)
AWS Config records WHAT your resources look like (configuration state) and evaluates WHETHER they comply with rules. It must be explicitly enabled (Configuration Recorder). Config = configuration compliance, CloudTrail = API audit, CloudWatch = performance metrics. Together they form the three pillars of AWS governance and observability.
Config Rules — Compliance Evaluation
Config Rules are the heart of AWS Config. Each rule defines a desired configuration and evaluates whether your resources comply. AWS provides 300+ managed rules and you can write custom rules with Lambda or Guard.
AWS Managed Rules
- 300+ pre-built rules maintained by AWS
- No code required — just configure parameters
- Covers security, cost, performance best practices
- Examples:
s3-bucket-public-read-prohibited,encrypted-volumes - Updated automatically when AWS adds features
Custom Rules
- Lambda-backed: write evaluation logic in Python/Node.js/Java
- Guard-backed: declarative policy-as-code (CloudFormation Guard DSL)
- Use for organisation-specific policies
- Example: "All EC2 must have tag
CostCenter" - Guard rules are simpler — no Lambda function needed
| Rule Name | What It Checks | Category |
|---|---|---|
s3-bucket-public-read-prohibited | S3 bucket is not publicly readable | Security |
s3-bucket-ssl-requests-only | S3 bucket requires HTTPS | Security |
encrypted-volumes | EBS volumes are encrypted | Security |
rds-instance-public-access-check | RDS is not publicly accessible | Security |
restricted-ssh | Security groups don't allow SSH from 0.0.0.0/0 | Security |
cloudtrail-enabled | CloudTrail is enabled in the account | Governance |
required-tags | Resources have mandatory tags | Cost/Governance |
ec2-instance-managed-by-ssm | EC2 instances are managed by SSM | Operations |
iam-password-policy | IAM password policy meets requirements | Security |
root-account-mfa-enabled | Root account has MFA enabled | Security |
Detective Evaluation (Default)
- Change-triggered: evaluates when resource configuration changes
- Periodic: runs every 1h, 3h, 6h, 12h, or 24h
- Detects non-compliance after the change happens
- Reports compliant / non-compliant / not applicable
- Most common mode for production monitoring
Proactive Evaluation
- Evaluates resources before they are created
- Called during CloudFormation stack operations
- Prevents non-compliant resources from being provisioned
- Uses CloudFormation Guard rules
- Shift-left: catch violations before deployment
Config Rules are detective, not preventive. They detect non-compliance after a change occurs — they don't block the change. For prevention, use SCPs (Organisation-level), IAM policies (permission boundaries), or CloudFormation Guard + proactive evaluation (pre-deployment).
- "Detect if S3 buckets are public" → Config rule
s3-bucket-public-read-prohibited - "Ensure all EBS volumes are encrypted" → Config rule
encrypted-volumes - "Prevent non-compliant resources" → Proactive evaluation (pre-deployment) or SCP
- "Custom compliance check" → Custom Lambda-backed rule or Guard rule
- "Evaluate on a schedule" → Periodic evaluation (1h, 3h, 6h, 12h, 24h)
- "Evaluate when resource changes" → Change-triggered evaluation (default)
- "300+ pre-built rules" → AWS Managed Rules
Config Rules evaluate whether resources comply with desired configurations. AWS provides 300+ managed rules; custom rules use Lambda or Guard. Rules are detective (detect after change) — for prevention, use SCPs or proactive evaluation. Change-triggered rules fire on configuration changes; periodic rules run on a schedule. Non-compliance events are emitted to EventBridge for automated response.
Configuration Recording & History
The Configuration Recorder is the engine of AWS Config — it captures a Configuration Item (CI) every time a supported resource is created, modified, or deleted. These CIs form a complete configuration timeline you can query at any point.
| CI Field | What It Contains | Example |
|---|---|---|
resourceType | AWS resource type | AWS::EC2::SecurityGroup |
resourceId | Unique resource identifier | sg-0abc123def456 |
configuration | Full JSON configuration blob | Inbound rules, outbound rules, VPC ID |
relationships | Connected resources | VPC, EC2 instances using this SG |
tags | Resource tags | Environment=prod, Team=platform |
configurationItemCaptureTime | When the CI was recorded | 2026-05-07T14:30:00Z |
configurationStateId | Version counter | Increments on each change |
Config records relationships between resources, letting you trace dependencies and blast radius:
| Feature | Configuration History | Configuration Snapshot |
|---|---|---|
| Scope | Single resource over time | All resources at a point in time |
| Delivery | S3 bucket (per resource type) | S3 bucket (on demand or scheduled) |
| Use case | "Show me all changes to SG X in last 30 days" | "What did my entire environment look like on Jan 1?" |
| Format | JSON file per resource per time period | JSON file with all CIs |
| Trigger | Automatic on each change | Manual via API or scheduled delivery |
S3 Bucket (Required)
- Stores configuration history and snapshots
- Enable versioning and encryption (SSE-KMS)
- Apply lifecycle rules for cost management
- Can be in a separate security account
SNS Topic (Optional)
- Notifications on configuration changes
- Notifications on compliance state changes
- Notifications when snapshots are delivered
- Fan out to Lambda, SQS, email, etc.
The Config console provides a resource timeline view — select any resource and see every configuration change over time, with diffs between versions. Combined with CloudTrail, you can see what changed (Config) and who changed it (CloudTrail). This is invaluable for incident investigation.
| Option | What Gets Recorded | Use Case |
|---|---|---|
| All supported resources | Every resource type in the region | Full compliance coverage (recommended) |
| Specific resource types | Only selected types (e.g., EC2, S3, IAM) | Cost-sensitive, targeted compliance |
| Include global resources | IAM users, roles, policies (global) | Enable in ONE region only to avoid duplicates |
Global resources (IAM) should only be recorded in one region (typically us-east-1). If you enable "include global resources" in every region, you'll record duplicate CIs and pay extra. The Config console warns about this.
- "See all changes to a resource over time" → Configuration History (per-resource timeline)
- "Point-in-time view of all resources" → Configuration Snapshot
- "Which resources are connected to this instance?" → Config Resource Relationships
- "Store Config data in separate account" → Configure delivery channel with cross-account S3 bucket
- "Avoid duplicate global resource recording" → Enable global resources in ONE region only
- "Config Recorder must be enabled" → It's NOT on by default (unlike CloudTrail Event History)
The Configuration Recorder captures a Configuration Item (CI) every time a resource changes — containing full configuration, relationships, tags, and timestamps. Configuration History shows changes to one resource over time; Configuration Snapshots show all resources at a point in time. Both are delivered to S3. Enable global resource recording in only one region to avoid duplicate costs. Resource relationships enable dependency mapping and blast-radius analysis.
Conformance Packs & Config Aggregators
For enterprise-scale governance, AWS Config provides Conformance Packs (bundles of rules mapped to compliance frameworks) and Config Aggregators (centralised compliance views across accounts and regions).
A Conformance Pack is a YAML template containing a collection of Config Rules and optional remediation actions, designed to map to a specific compliance framework.
| Conformance Pack Template | What It Checks |
|---|---|
| Operational Best Practices for HIPAA | Encryption, access controls, audit logging for health data |
| Operational Best Practices for PCI DSS | Cardholder data encryption, network segmentation, logging |
| Operational Best Practices for CIS AWS Foundations | CIS Benchmark Level 1 + 2 controls |
| Operational Best Practices for NIST 800-53 | Federal security controls |
| Operational Best Practices for AWS Well-Architected | Security, reliability, performance pillars |
| Custom conformance pack | Your own YAML with selected rules + remediation |
A conformance pack deploys as a single unit — all rules are created/updated/deleted together. This is cleaner than managing 50 individual rules. Conformance packs can be deployed via Organizations to all member accounts simultaneously.
Organisation Aggregator
- Auto-discovers all accounts in AWS Organization
- No manual account authorization needed
- Collects from all regions automatically
- Recommended for enterprises
Individual Aggregator
- Specify account IDs manually
- Each source account must authorise the aggregator
- Use when not using AWS Organizations
- Good for partner/vendor compliance views
- "Deploy 50 Config rules mapped to HIPAA" → Conformance Pack (template)
- "Single view of compliance across all accounts" → Config Aggregator
- "Auto-discover accounts for aggregation" → Organisation Aggregator (requires AWS Organizations)
- "Deploy conformance pack to all accounts" → Organizations integration (stacksets behind the scenes)
- "Read-only cross-account view" → Aggregator is read-only — it doesn't remediate, only aggregates data
Conformance Packs are YAML-defined bundles of Config Rules mapped to compliance frameworks (HIPAA, PCI DSS, CIS). Config Aggregators provide a centralised, read-only compliance dashboard across accounts and regions. Organisation Aggregators auto-discover all member accounts — no manual authorisation. Deploy conformance packs via Organizations for enterprise-wide governance.
Remediation, Integration & Cost
Detecting non-compliance is only half the battle — remediating it is the other half. AWS Config integrates with SSM Automation for auto-remediation and EventBridge for event-driven workflows.
Automatic Remediation
- Runs immediately on non-compliance detection
- Uses SSM Automation documents (pre-built or custom)
- Configurable retry attempts (1–5)
- Max concurrent executions limit
- Example:
AWS-DisableS3BucketPublicReadWrite
Manual Remediation
- Triggered by user clicking "Remediate" in console
- Same SSM Automation document executes
- Used for high-risk changes needing human approval
- Can require approval via SSM Automation approval step
Common SSM remediation documents:
| SSM Document | What It Fixes |
|---|---|
AWS-DisableS3BucketPublicReadWrite | Removes public access from S3 bucket |
AWS-EnableS3BucketEncryption | Enables default encryption on S3 bucket |
AWS-EnableCloudTrail | Creates/enables a CloudTrail trail |
AWS-EnableEbsEncryptionByDefault | Enables EBS encryption at account level |
AWS-RevokeUnusedIAMUserCredentials | Deactivates unused IAM keys |
Config emits events to EventBridge on compliance state changes, enabling automated workflows:
- Compliance change: resource goes compliant → non-compliant (or reverse)
- Configuration change: any resource configuration update
- Rule evaluation: when a rule evaluation completes
Alert Patterns
- Non-compliant → SNS → Slack/email notification
- Critical resource changed → PagerDuty alert
- Compliance score drops → management dashboard update
Automation Patterns
- Non-compliant SG → Lambda removes 0.0.0.0/0 rule
- Untagged resource → Step Functions adds tags
- Unencrypted volume → Lambda encrypts via snapshot
| Component | Cost | Notes |
|---|---|---|
| Configuration Items recorded | $0.003 per CI | Each resource change = 1 CI |
| Config Rule evaluations | $0.001 per evaluation | First 100K evals/month in free tier |
| Conformance Pack evaluations | $0.001 per evaluation per rule | Same as individual rules |
| Proactive evaluations | $0.001 per evaluation | Pre-deployment checks |
| S3 storage | Standard S3 pricing | For configuration history & snapshots |
Do
- Record only needed resource types — not all 300+ types if unnecessary
- Enable global resources in ONE region — avoid duplicate IAM CIs
- Use periodic evaluation for non-critical rules (reduces eval count)
- Leverage free tier — first 25 rules free per region
- S3 lifecycle — move old config data to Glacier
Don't
- Record all resources in all regions without purpose (cost multiplied)
- Use change-triggered for low-importance rules — use periodic instead
- Duplicate global resource recording — creates 2× CIs
- Create custom Lambda rules unnecessarily — check managed rules first
- Forget S3 costs — config history files accumulate
AWS Security Hub uses Config Rules as its foundation for security standards:
- Security Hub enables Config rules automatically when you activate a standard (CIS, PCI DSS, AWS Foundational)
- Security Hub consolidates findings from Config, GuardDuty, Inspector, Macie, Firewall Manager
- If Config is not enabled, Security Hub cannot evaluate resource compliance
- Exam point: "Security Hub requires Config to be enabled" — this is a common prerequisite question
- "Auto-fix non-compliant resources" → Config rule + automatic remediation (SSM Automation document)
- "Alert on compliance change" → Config → EventBridge → SNS/Lambda
- "Security Hub not showing compliance data" → Config Recorder is not enabled (prerequisite)
- "Cost of Config" → $0.003/CI + $0.001/rule evaluation; first 25 rules free per region
- "Make S3 bucket private automatically" → Config rule + SSM
AWS-DisableS3BucketPublicReadWrite - "Reduce Config costs" → Record specific resource types, enable global resources in one region, use periodic evaluations
- "Config rule vs SCP" → Config detects non-compliance (detective); SCP prevents the action (preventive)
Config auto-remediation uses SSM Automation documents to fix non-compliant resources automatically (e.g., make public S3 bucket private). EventBridge enables event-driven workflows on compliance changes. Pricing is $0.003/CI recorded + $0.001/rule evaluation, with first 25 rules free. Security Hub depends on Config being enabled. Optimise costs by recording only necessary resource types, using periodic evaluations, and enabling global resources in one region only.
AWS Config — Complete Domain Summary
- Purpose — records WHAT your resources look like, evaluates WHETHER they're compliant, and tracks WHEN configurations change
- Config Rules — 300+ managed rules, custom Lambda/Guard rules; detective (change-triggered, periodic) and proactive (pre-deployment) evaluations
- Recording — Configuration Items capture full resource state + relationships; delivered to S3; history per-resource, snapshots for all resources
- Enterprise — Conformance Packs (HIPAA, PCI DSS, CIS templates); Aggregators (multi-account, multi-region compliance view)
- Remediation — SSM Automation documents for auto/manual remediation; EventBridge integration for event-driven workflows
- Cost — $0.003/CI + $0.001/eval; first 25 rules free; optimise by scoping resource types and using periodic evaluations