Service spotlight: AWS Config for compliance-as-code and drift detection
Terraform tells you what infrastructure should look like at apply time. It doesn’t tell you what changed at 3am when someone with console access manually flipped a security group rule to unblock themselves and forgot to revert it. That gap — configuration drift between what you declared and what’s actually running — is what AWS Config is built to close.
What it actually is
AWS Config continuously records the configuration state of supported
resources in your account (over 300 resource types) as a timestamped
history, and evaluates that state against Config rules — either AWS
managed rules (s3-bucket-public-read-prohibited,
restricted-ssh, iam-password-policy) or custom rules backed by your
own Lambda function or Guard/CloudFormation Guard policy. Every recorded
change produces a configuration item, and Config keeps a full
timeline, so you can ask “what did this security group’s rules look like
at 2:14pm last Tuesday” and get an actual answer, not a guess reconstructed
from CloudTrail events.
Rules run either on a schedule (periodic) or triggered by a configuration change (change-triggered), and each evaluation produces a compliant/non-compliant verdict per resource that shows up in one dashboard across the account — or, aggregated, across an entire Organization via Config aggregators.
Where it earns its keep
- Drift detection that isn’t tied to your IaC tool. Config doesn’t know or care that a resource was created by Terraform — it evaluates whatever’s actually running against your rules, which catches manual console changes, break-glass fixes that weren’t reverted, and changes made by tools outside your Terraform state entirely.
- Point-in-time configuration history for incident response. “What changed on this resource in the hour before the incident” is a Config timeline query, which is a much faster starting point than paging through raw CloudTrail events trying to reconstruct resource state by hand.
- Automated remediation. A non-compliant finding can trigger an SSM Automation document via remediation actions — auto-revoking a security group rule that opens 0.0.0.0/0 on port 22, for example — so drift doesn’t just get flagged, it gets fixed without a human in the loop for well-understood violations.
- Organization-wide compliance posture in one place. Conformance packs bundle related rules (CIS benchmark, PCI-DSS-aligned checks) and deploy across every account in an Organization via an aggregator, giving one compliance score instead of per-account spot checks.
Where it doesn’t replace Terraform (or vice versa)
Config is observational and reactive — it tells you what’s true now and evaluates it against policy, but it doesn’t prevent a bad change from happening in the first place the way a Terraform plan/apply gate or an SCP does. And Terraform’s state file, while it also describes resource configuration, only reflects what Terraform itself last applied — it goes stale the moment something changes outside Terraform, which is exactly the blind spot Config is designed to catch. The two are complementary: Terraform (plus policy-as-code gates like Checkov) prevents drift at apply time; Config catches whatever gets through anyway, including changes that never went through Terraform at all.
The pricing model
Config bills per configuration item recorded and per **rule evaluation**, both of which scale with account activity and resource count — a large, churny account with many resource types and frequent changes will rack up config-item costs faster than a small, stable one. Turning on recording for every supported resource type across every account in an Organization without checking projected volume first is the most common way a Config bill surprises someone; scope the recorder to resource types you actually intend to have rules for if cost is a concern, rather than defaulting to “record everything.”
A practical tip
Start with a conformance pack for a benchmark you already care about (the AWS-provided CIS or Foundational Security Best Practices packs are good defaults) instead of hand-picking individual managed rules — it gets you broad, curated coverage immediately, and you can prune or add rules from there once you see what’s actually flagging in your account.
Join the discussion
Comments for this post live on social — reply to the thread.
Related posts
Cloud roundup: macOS Screen Sharing bug now under attack
A patched macOS Screen Sharing flaw is being exploited to plant crypto miners, a Windows Defender bypass has no fix yet, and EC2 gets built-in app health checks.
Cutting NAT gateway costs with VPC endpoints that actually help
How gateway and interface VPC endpoints replace NAT gateway traffic for AWS API calls, what they cost instead, and which traffic still has to go through NAT.
Cloud roundup: S3 finally names the policy that denied you
AWS S3 access-denied errors now name the exact policy ARN, Client VPN gets a scriptable CLI, and OpenAI ships authorized offensive-security models on Bedrock.