Cloud Security Maturity Model·AWS v3.0.0

Drag to explore · pinch to zoom

Optimized Incident response

c4.15 Automate correction of configuration drift

Enforce your security baseline by detecting and auto-correcting configuration drift with AWS Config auto-remediation, which runs a Systems Manager automation to return a resource to the desired state. Detect-and-correct complements preventive guardrails; it is not a replacement.

Implementation guidance

Detect and correct with AWS Config

AWS Config auto-remediation runs an AWS Systems Manager Automation runbook to return a non-compliant resource to its desired state, enforcing your security baseline continuously.

Prevent vs. detect-and-correct

Why not just prevent drift with SCPs and IAM policies? Prevention is ideal — the misconfiguration never exists — and you should use guardrails for your hard invariants. But detect-and-correct is a useful complement:

  • Better builder experience — instead of an opaque "access denied", you can let the change happen, revert it, and notify the owner (via tags) with an explanation.
  • Covers pre-existing drift — policies do not fix misconfigurations that predate them; Config remediation does.
  • Catches privileged bypass — if someone who can bypass a policy misconfigures a resource, Config still corrects it.
  • Supports softer responses — for example open a ticket on drift and auto-close it when resolved, rather than hard-blocking.

How it fits together

Resource drifts from baseline AWS Config continuously evaluates against rules compliant → no action non-compliant SSM Automation auto-remediation runbook + notify owner (tags) Desired state re-evaluated · complements preventive guardrails (c2.5), does not replace them
AWS Config continuously evaluates resources against rules; a non-compliant resource triggers an SSM Automation runbook that returns it to the desired state and notifies the owner, then the resource is re-evaluated. This detect-and-correct loop complements preventive guardrails (c2.5) — it does not replace them.

How to validate

  • Do you detect configuration drift against your security baseline (for example with AWS Config)?
  • Do you auto-correct high-confidence misconfigurations, or at least open a ticket and notify the owner?
  • Do preventive guardrails (SCPs/RCPs) cover your hard invariants, with detect-and-correct handling the rest?

Threats addressed

  • Configuration drift silently moves resources out of your security baseline; without detection and correction, a misconfiguration can persist unnoticed and become an entry point.

AWS services

AWS Config AWS Systems Manager

Pricing

Framework mappings

AWS CAF

Well-Architected

NIST CSF

References