JSTGTECH
← Back to blog

Service spotlight: AWS Config for compliance-as-code and drift detection

3 min read

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.

Related posts