What Is Infrastructure Drift? Causes and Prevention

Infrastructure drift happens when the actual state of a running system no longer matches what its infrastructure-as-code definitions say it should be. A engineer opens the cloud console under deadline pressure and manually bumps a server’s memory limit, or resizes a database, or opens a firewall port — and from that moment on, the code and reality disagree. The next time someone applies the IaC configuration, it either silently reverts the manual fix or errors out because the tool doesn’t recognize the resource’s current state.

Why it happens

Drift almost always starts with a change made outside the normal deployment path:

• Manual console or CLI changes. Someone edits a resource directly during an incident, then forgets — or doesn’t have time — to reflect the change back into the IaC source.
• Out-of-band automation. A separate script, a scheduled job, or another team’s tooling modifies a resource that’s also managed by your Terraform or CloudFormation configuration.
• Provider-side changes. Cloud providers sometimes change default values, rotate underlying resources, or apply changes as part of a maintenance action, none of which the IaC state file knows about.
• Partial or failed applies. A deployment that fails halfway through can leave some resources updated and others not, creating drift between what the state file believes happened and what actually happened.
• Multiple tools managing the same resource. If both a CI/CD pipeline and a manual runbook can touch the same infrastructure, whichever ran most recently wins — and the IaC tool has no way to know that.

Why drift is a problem

The core promise of infrastructure-as-code is that the code is the source of truth: read the configuration and you know what’s running. Drift breaks that promise. Once state diverges, the next terraform apply (or equivalent) can do one of three unwelcome things: silently revert a manual fix that was actually load-bearing, fail outright because the tool can’t reconcile what it expects with what it finds, or — worst case — apply a change that looks safe in isolation but interacts badly with the undocumented manual change sitting underneath it.

Drift also erodes trust in the deployment process itself. Once engineers learn that the “true” state of production sometimes lives in the console rather than in the repository, they start treating IaC as aspirational rather than authoritative, and manual fixes become more common — which produces more drift. It’s a feedback loop that’s much cheaper to interrupt early than to unwind later.

How to detect it

Most IaC tools have a built-in comparison step, commonly a “plan” or “diff” command, that compares the live state of a resource against the configuration before applying anything. Running that comparison on a schedule — even if you don’t intend to apply the result — surfaces drift as soon as it happens rather than at the next deploy. Some teams wire this into CI as a nightly job that posts an alert (rather than auto-applying) whenever a plan shows unexpected changes, since an unattended drift-correction apply can be just as risky as the drift itself if the manual change was intentional and undocumented.

How to prevent it

• Restrict direct access. If engineers can’t make console changes to production resources in the first place, they can’t introduce drift that way. This is a stronger guarantee than asking people to remember to update the code afterward.
• Route all changes through the same pipeline. If every infrastructure change — routine or emergency — goes through the same CI/CD path, there’s no separate manual path for drift to enter through. This is the core idea behind GitOps: the repository state and the deployed state are kept in sync by an automated reconciliation loop, not by developer discipline.
• Prefer immutable infrastructure. Under an immutable infrastructure model, servers and resources aren’t patched in place — they’re replaced wholesale from a known-good definition. This removes most of the incremental, hard-to-track edits that cause drift in mutable systems.
• Run drift detection regularly, not just at deploy time. A resource can drift on its own, without any deploy triggering a check. Scheduled plan-only runs catch that.
• Make emergency changes fast to codify. Drift caused by genuine incidents is unavoidable sometimes — the fix is making it fast and low-friction to backport a hotfix into the IaC source afterward, so the emergency deviation doesn’t become permanent.

Drift detection tools vs manual plans

Dedicated drift-detection tooling generally works the same way a manual plan does — read live state, compare against declared state, report differences — but automates the comparison across an entire environment on a schedule and can integrate with alerting systems. For small teams, a scheduled CI job running a plan-only command is often enough; larger organizations with many services and teams touching shared infrastructure tend to need dedicated tooling to keep the volume of drift reports manageable, similar to how larger organizations invest in a broader internal developer platform to keep infrastructure changes consistent across teams.

The takeaway

Infrastructure drift is the gap between what your infrastructure-as-code says should be running and what’s actually running, and it almost always starts with a change made outside the normal deployment pipeline. The fix isn’t better documentation discipline — it’s removing the side doors: restrict direct access to production resources, route every change (including emergency ones) through the same pipeline, and run drift detection on a schedule so gaps surface before they cause an incident rather than during one.