Definition
What Is Infrastructure Drift?
Infrastructure drift is the gap between what your Terraform or OpenTofu files declare and what actually exists in AWS, Azure, GCP, or OCI. Here is what causes it, why it matters, and how teams classify it.
Infrastructure drift · reference
Infrastructure drift is the difference between declared infrastructure (what your Terraform or OpenTofu configuration says should exist) and live infrastructure (what the cloud APIs report right now).
If the code says a bucket is private and the console shows it as public, that is drift. If someone created a security group by hand and it never appeared in a module, that is also drift — just a different kind.
Drift is not a Terraform bug. Clouds are mutable. People, autoscalers, support tickets, and other pipelines all write to the same accounts.
What usually causes it
Most production drift comes from a short list of sources:
- ClickOps. A break-glass change in the AWS, Azure, or GCP console that never made it back into a pull request.
- A second writer. A Helm chart, a cloud-native controller, or another team's pipeline mutating the same resource.
- Provider defaults. A new default encryption flag or a computed attribute that the last apply never pinned.
- State that is stale. A plan run without a refresh, or a workspace that no longer owns the resource.
- Expected elasticity. Node counts, replica counts, and some load-balancer attributes that the platform is supposed to change.
The first four need a decision. The last one needs a rule so it stops flooding the report.
Why teams care
Drift is cheap when it is a missing tag. It is expensive when it is:
- an ingress rule that opened the network,
- an IAM trust policy edited during an incident,
- a database parameter that no longer matches the module,
- a DNS record that still works — until the next apply overwrites it.
The operational cost is not only the misconfiguration. It is the loss of confidence: if terraform apply might clobber a silent console fix, people stop applying, and the repo stops being the source of truth.
Three kinds of drift worth naming
| Kind | What you see | Typical response |
|---|---|---|
| Configuration drift | A managed resource's attributes differ from code | Reconcile to code, or update code to match reality |
| Unmanaged resources | Live objects with no address in state | Import, delete, or explicitly accept |
| Expected drift | Autoscaling, vendor-managed fields | Ignore with a documented exception |
If a report only says “drift found,” reviewers will ignore it. If it says “security-critical configuration drift on this security group,” they can act.
What drift is not
- A failed apply is an error, not drift.
- A plan that wants to create a new environment is a change request, not drift.
- Cost variance is a billing signal. It often follows drift (an oversized instance) but it is not the same thing.
What to do once you can name it
Scan with how to detect Terraform drift. Decide import, reconcile, or accept with the drift triage playbook.
If you want that scan and decision on connected clouds, use drift detection.