AWS Config — Resource Configuration Tracking

Core concept → Configuration tracking and compliance rules

The core idea is straightforward: Config watches every AWS resource you create, modify, or delete, and judges it against rules. A rule can be simple (e.g., 'is this S3 bucket encrypted?') or complex (e.g., 'is this IAM role used by an instance that can reach the internet?'). When a resource does not meet a rule, it is marked non-compliant. Think of Config as a continuous compliance audit that runs whether you look at it or not.

Three key characteristics: managed rules are AWS-built checks you enable with one click; custom rules are logic you write in Python or Node.js and deploy as Lambda functions; remediation (optional) automatically fixes a non-compliant resource or alerts you to do so. A resource can be compliant to some rules and non-compliant to others, and Config tracks both the current state and the history.

How it works → Events, rules, and the config recorder

The mechanics run in three parts. First, the Config Recorder watches your account for resource changes. When you create an EC2 instance, modify a security group, or delete an RDS database, CloudTrail sends an event, Config intercepts it, and the recorder captures the entire resource configuration (all properties) and stores it in S3 and a database. This is not just 'a thing was created’; it is the full configuration state at that moment.

Second, rules evaluate continuously. Some rules are triggered by changes (e.g., when an S3 bucket is modified, check if versioning is on); others run on a schedule (e.g., every 12 hours, re-evaluate every RDS instance). When a rule evaluates a resource, it returns either COMPLIANT or NON_COMPLIANT.

Third, findings are recorded. Every evaluation result goes into the Config database, which means you have a complete timeline: resource X was compliant at 3:15pm, drifted at 3:27pm when someone disabled encryption, and went back to compliant at 4:10pm when the automation fixed it. This timeline is gold during incident investigations.

Managed rules → 200+ AWS-built compliance checks

AWS maintains a library of 200+ managed rules covering common compliance needs across industries. A small sample:

To use a managed rule, you enable it in Config (specify parameters like which resource types to check, how often to run), and AWS does the heavy lifting. The rule comes with a description, remediation guidance, and often an optional remediation action (a Systems Manager automation you can run to auto-fix the issue). Because AWS maintains the rules, they stay current with best practices and new resource types. The tradeoff: you cannot customize them; if you need a variation on a rule, you write a custom one.

Custom rules → Lambda-based compliance logic

When AWS-managed rules do not cover your logic, you write a custom rule in Lambda. A custom rule is a Python or Node.js function that receives a resource and returns COMPLIANT or NON_COMPLIANT. Common examples:

• Enforce a naming convention (e.g., all production instances must start with 'prod-')
• Check tag coverage (e.g., 'all databases must have a Cost Center tag')
• Validate resource relationships (e.g., 'this Lambda must run in a VPC')
• Cross-resource compliance (e.g., 'if an instance is tagged backup:yes, it must be in a backup plan')

You write the Lambda, deploy it, and tell Config about it. Config invokes your function on a schedule or on changes, passes the resource, and your function returns the result. The lever is that you control the logic entirely, but you own the maintenance: your Lambda has to stay compatible with API changes and new resource types.

Config Aggregator → Multi-account, multi-region compliance

A single AWS account gives you visibility into your own resources, but organizations need compliance across 5, 50, or 500 accounts and regions. Enter the Config Aggregator: a centralized dashboard that collects Config findings from multiple member accounts and regions.

The setup: designate one account as the aggregator account and authorize it to read Config from member accounts. The aggregator polls each member account’s Config API, pulls compliance findings, and shows you a single dashboard with breakdowns like 'all accounts, all regions, rule-by-rule compliance rates.' You can drill down: ‘account 456 is non-compliant with 'encrypted-volumes’; click it to see which volumes are unencrypted and which account/region they are in.

This is the mechanism that scales Config from 'I compliance-check my own stuff' to 'the enterprise reports compliance posture to auditors.' A typical enterprise might aggregate 200+ accounts across 10 regions into one dashboard, making it impossible for a non-compliant resource to hide in a forgotten corner of the org.

Remediation → Automatic fixes or human alerts

Finding non-compliance is half the battle; fixing it is the other half. Config supports two remediation patterns. Automatic remediation runs a Systems Manager automation document that fixes the resource without human intervention. For example, when a rule detects an S3 bucket is public, the remediation action blocks public access automatically. Manual remediation sends you an alert (via SNS or EventBridge) that tells you to fix it yourself.

Automatic remediation is powerful because it closes the gap instantly, but it requires confidence in the automation and the IAM permissions to run it. A remediation action that encrypts every non-compliant EBS volume is great; a remediation that deletes a resource is risky and probably not something you want running unsupervised. Most teams use auto-remediation for defensive fixes (block public access, enable encryption) and manual remediation for changes that need review (tag modifications, security group updates).

Drift detection → Spotting unauthorized changes

A resource can drift in two ways. Config drift is when the current configuration no longer matches what a rule expects (e.g., encryption was on, someone disabled it). Stack drift (CloudFormation-specific) is when a resource was created by CloudFormation but then modified outside CloudFormation, breaking the IaC source of truth.

Config continuously tracks both. The most important use case: incident investigation. You wake up to a security alert — an instance is being scanned. You pull Config, and it shows exactly when the security group changed (2:15am), what the change was (ingress rule added for port 22), which user/role made it, and what the configuration was before and after. Instead of chasing logs across CloudTrail, Config gives you a complete picture in one place. For regulated industries this is not optional; auditors require it.

Incident forensics → The config timeline

When things go wrong, Config is your forensic tool. Suppose a database was publicly accessible for three hours and you need to prove to auditors that it is now private. Config shows:

• 3:00am: database created, security group was restricted (compliant)
• 3:45am: security group modified to allow 0.0.0.0/0:3306 (non-compliant)
• 6:52am: security group reverted to restricted (compliant)

You know the exact window, the exact change, and (via CloudTrail integration) who made it. This is what compliance auditors want to see: evidence of the incident, proof that it was detected and acted on, and documentation that it will not happen again. Config without history is a point-in-time dashboard; Config with history is the audit trail that satisfies regulators.

Real-world use cases

Regulated financial services: PCI-DSS requires firewalls configured correctly, encryption enabled, and access logs. Config audits all three and reports monthly. The aggregator ensures no subsidiary's AWS account drifts out of compliance. Healthcare: HIPAA requires encryption at rest and in transit, MFA on admin access, and audit logging. Config enforces this; custom rules verify that database replication uses encrypted channels.

Government/defense contractors: FedRAMP requires continuous monitoring and evidence of control compliance. Config generates the evidence. Internal governance: many enterprises use Config not for external compliance but to enforce internal standards — all production databases must have backup enabled, all instances must be tagged with a cost center, all resources in dev must be smaller and cheaper than prod. Custom rules make this possible.

Integration with other AWS services

Config does not stand alone; it connects to the compliance ecosystem. AWS Security Hub aggregates Config findings alongside GuardDuty, IAM Access Analyzer, and third-party security tools, giving you one unified security dashboard. EventBridge receives Config compliance events (resource went non-compliant, remediation succeeded/failed) and routes them to SNS, Lambda, or a SIEM for alerting and automation. Systems Manager Automation runs remediation documents. CloudTrail logs all Config changes and rule evaluations for audit trails.

The glue is that Config becomes the source of truth for resource inventory and compliance; other services consume it and act on it. A well-architected compliance stack chains Config → EventBridge → Lambda → auto-remediation, with alerts to Security Hub if the automated fix fails.

Cost model and optimization

Config pricing has two components: evaluations (each time a rule runs against a resource) and configuration changes (each time Config records a new version of a resource). Evaluation cost depends on the rule type (managed rules are cheaper, custom Lambda rules pay for Lambda), and change cost depends on how often your resources are modified.

A typical enterprise account might have $20-50 per month in Config costs; a large org with many accounts and rules might run $200-500 monthly across the aggregator and all member accounts. The optimization: be selective about which resource types and rules you enable. You do not need to check every resource with every rule; focus on the high-risk resources (databases, security groups, IAM) and the rules that matter to your industry. Exclude non-production accounts if they do not need compliance reporting.

Best practices

Start narrow. Enable Config in one account, enable a few high-value managed rules (encrypted-volumes, s3-public-access, mfa-enabled), and watch for false positives. Once you trust the rules, expand to other accounts.

Aggregate early. Even with two accounts, set up an aggregator. It simplifies the dashboard and makes multi-account compliance reporting automatic later.

Use auto-remediation sparingly. Automatic fixes are fast but risky; use them for defensive changes (block, restrict, enable) and manual review for anything that modifies or deletes data.

Chain Config to EventBridge. Raw compliance findings are not actionable; route them to an automated system that alerts on drift, triggers remediation, and keeps a log of what changed and why.

Keep history. Enable Config recording and never turn it off. The value of Config doubles when you have a year of history; compliance audits and incident forensics depend on it.

Write custom rules for your standards. AWS-managed rules cover common compliance; custom rules enforce your specific requirements (tagging, naming, architecture patterns).

Trade-offs and gotchas

False positives on configuration changes. Config records every change, including transient ones (an instance boots with a temporary security group, then joins a load balancer that changes it). Rules that are too strict trigger non-compliance alerts on resources that are technically fine. Add filtering and grace periods to your rules.

Remediation drift. Auto-remediation can fail silently (the Lambda ran but the resource was not actually fixed). Always pair auto-remediation with a rule that re-checks, so drift is re-flagged if the fix did not stick.

Multi-account aggregator lag. Config Aggregator polls member accounts on a schedule, so findings can be 5–15 minutes stale. For real-time alerting, pair it with EventBridge, which fires immediately.

Cost surprise on large scale. An organization with 500 accounts and 50 rules can easily run 10,000+ evaluations per hour. This is fast (microseconds per rule), but at scale it adds up. Monitor your evaluation counts and be deliberate about rule scope.

When Config is not enough

Config is strong on resource configuration and compliance rules, but it has blind spots. It does not see inside instances (OS-level compliance like 'is CIS benchmark applied?' requires Systems Manager Session Manager or third-party agents). It does not track application-level compliance (whether your app logs to CloudWatch, whether it validates input). It does not understand cost (whether a resource is wastefully large). For those, you layer in Security Hub (for broader security findings), Systems Manager Patch Manager (for OS patches), and third-party tools like Dome9 or CloudHealth (for cost and app-level compliance).