IaC Drift Detection Patterns Guide

IaC drift occurs when your live cloud infrastructure diverges from what your Infrastructure-as-Code configuration describes. It's dangerous for several reasons: it breaks the predictability of IaC (your 'source of truth' no longer reflects reality), it makes the next automated deployment unpredictable or destructive, it can introduce security vulnerabilities (e.g. a security group rule opened manually), and it erodes team trust in automation. Even small drifts compound over time — a manually added S3 bucket policy today becomes an unexpected terraform destroy next sprint.

These three tools detect drift at different scopes. 'terraform plan' is the standard approach: it compares your config against the state file and shows what Terraform would change — but it only knows about resources tracked in your state file. 'terraform refresh' (deprecated in TF 1.x, replaced by 'terraform apply -refresh-only') updates the state file to match actual cloud reality without making changes, which lets you see what drifted. Driftctl is a dedicated open-source drift scanner that goes further: it detects cloud resources that exist in your account but are NOT in any Terraform state at all — so-called 'unmanaged resources'. This is the coverage driftctl excels at.

Prevention has four pillars. First, enforce IaC-only changes: use IAM policies and OPA/Sentinel rules to block direct console edits in production accounts. Second, run drift detection in CI/CD: schedule 'terraform plan' or driftctl scans daily or on every push, and alert on any diff. Third, use state locking with DynamoDB (Terraform) or Pulumi Cloud to prevent concurrent modifications. Fourth, implement GitOps: treat your IaC repo as the only source of truth, and use automated reconciliation (ArgoCD, Atlantis, Flux) so any deviation triggers an automatic correction. Teams that skip even one pillar typically see drift accumulate within weeks.

The decision depends on why the drift happened. If someone made an emergency fix that should be permanent (e.g., opening a port during an incident), update the IaC to match, commit, and run a plan/apply to reconcile. If the drift is unintentional or unauthorized (someone clicked around in the console), run 'terraform apply' to revert cloud to match IaC — after confirming no data loss. If it's auto-scaling state (instance counts, read replicas), consider using 'lifecycle { ignore_changes }' to tell Terraform to ignore those attributes. Never just 'terraform refresh' and commit the drifted state without understanding why the drift occurred.

For Terraform: start with 'terraform plan -refresh-only' built-in, add driftctl for unmanaged resource detection, and Infracost for cost drift. For Pulumi: 'pulumi refresh' updates stack state and shows drift; Pulumi Cloud also provides drift reports. For AWS CDK: use 'cdk diff' which shows CloudFormation change sets — CloudFormation natively tracks drift via 'aws cloudformation detect-stack-drift'. For Ansible: use '--check' mode (dry-run) to see what would change; ansible-lint and Molecule help validate configuration state. For all platforms, AWS Config Rules provide a compliance layer that continuously evaluates resources against your policies regardless of which IaC tool manages them.