Infrastructure drift explained: what it is and how it creeps in

Infrastructure drift is the gap between the state your configuration or infrastructure-as-code (IaC) says should exist and the state that's actually running in production. It happens whenever someone or something changes a live resource — a server, a firewall rule, a DNS record — without updating the source of truth that describes it. Left unchecked, drift turns your "known good" config into fiction.

Drift isn't a bug in any one tool. It's a structural risk of running infrastructure across multiple people, providers and automation pipelines, and it gets worse as your stack grows.

What counts as infrastructure drift?

Drift is any divergence between declared state (a Terraform file, a CloudFormation template, a DNS zone export, a runbook) and observed state (what the provider's API actually returns right now). It applies to almost anything with a config: compute instances, security groups, load balancer rules, TLS certificates, and DNS records.

A few concrete examples:

• Someone edits a security group rule in the AWS console to unblock a deploy, then forgets to reflect it in Terraform.
• A DNS record gets updated directly in a registrar's dashboard during an incident, bypassing the automation that normally manages it.
• An autoscaling group swaps in a new AMI (Amazon Machine Image) during a patch cycle, changing the instance configuration your IaC never knew about.
• Two teams manage the same DNS zone through different tools — one via Terraform, one by hand — and their changes silently overwrite each other.

Each of these leaves your documented infrastructure and your real infrastructure telling different stories.

How drift creeps in

Drift almost never happens on purpose. It creeps in through a handful of well-worn paths:

• Manual hotfixes. Someone changes a live resource during an incident because it's faster than going through the pipeline, and the follow-up ticket to backport the change never gets done.
• Out-of-band automation. A separate script, a provider's auto-patching, or a support engineer's console action changes a resource your main IaC doesn't know about.
• Split-brain ownership. Multiple teams or tools manage the same resource — common with DNS, where a registrar dashboard, a CDN, and a Terraform module might all claim to own the same zone.
• Provider-side changes. Managed services occasionally update underlying resources (patched AMIs, rotated certificates, updated default values) without any action on your end.
• Stale ignore_changes or unmanaged attributes. If your IaC tool is told to ignore certain fields, or doesn't track them at all, changes to those fields will never surface as drift — even though they're real.

None of these require negligence. They're just what happens when infrastructure has more than one door into it.

How drift detection actually works

Most IaC tools detect drift the same basic way: they query the live provider API for the current state of each resource, then diff it against the state they last recorded. Here's how that plays out across the major tools.

NoteAll three approaches are pull-based: they catch drift only when you run a scan, plan, or refresh. None of them watch for changes in real time by default, which means drift can sit undetected for hours or days between runs.

A typical Terraform drift-review workflow looks like this:

# Preview what has drifted, without touching any resources
terraform apply -refresh-only

# If the drift is expected/acceptable, accept the refreshed state
# If it's not, fix the real resource or update your .tf files, then:
terraform plan
terraform apply

Note too that IaC tools can only detect drift on attributes they actually track. Fields excluded via lifecycle { ignore_changes }, or simply outside the tool's schema, won't show up as drifted even when they've changed — a common source of false confidence.

Why DNS is especially prone to drift

DNS is one of the most drift-prone parts of any stack, for a simple reason: it's editable from too many places. A record can be changed through your registrar's dashboard, your DNS provider's console, a CI/CD pipeline, or a support ticket — often by different people who don't know about each other's changes. Unlike a server you can SSH into and inspect, a DNS record that's silently changed just quietly redirects traffic, breaks mail delivery, or fails a certificate validation, often without an obvious error message.

That's exactly the gap our How DNS resolution works piece touches on from the resolution side — but drift is the change-management side of the same problem: DNS is authoritative and shared, which makes it fragile to uncoordinated edits.

Reducing drift risk in practice

You can't eliminate drift entirely — provider-side changes and emergency fixes will always happen — but you can shrink the blast radius:

• Centralise ownership. Pick one system of record per resource type, especially for DNS, and route all changes through it.
• Run scheduled refresh/plan jobs, not just on-demand ones, so drift surfaces on a cadence rather than only when someone remembers to check.
• Alert on unexpected changes rather than relying on manual plan runs — continuous, event-driven detection catches drift far faster than periodic scans.
• Keep an accurate inventory of what exists and who owns it; see why infrastructure inventory is important for what to track.
• Automate routine changes so there's less reason for anyone to reach for a console in the first place — our guide on automating DNS, SSL and server tasks across providers covers this directly.

Catching DNS drift before it causes an outage

Because DNS drift is invisible until something breaks — a mail server stops receiving, a subdomain starts resolving to the wrong host — the most useful detection is continuous, not scheduled. InfraNest's DNS management watches your zones across every registrar and provider from one dashboard and flags unexpected record changes as they happen, so you're not relying on someone remembering to run a diff.

If you want to see what continuous drift alerting looks like in practice, check out DNS management and see how it fits into the rest of your stack.