Configuration drift is the gap that opens between how your cloud infrastructure was defined and how it actually exists right now. It accumulates through emergency console fixes, manual scaling, partial deployments and undocumented changes. Left undetected, drift turns a reviewed, approved architecture into an environment nobody has fully seen — usually discovered during an incident or an audit.
Most teams already accept drift as inevitable. The more useful question is not whether it exists but how fast it is accumulating, because rate of change is a far better early warning signal than any single misconfiguration.
What is configuration drift?
Configuration drift occurs when the live state of a resource no longer matches its intended state — the Terraform plan, CloudFormation template, hardening baseline or documented architecture that was signed off.
It shows up in familiar forms:
- A security group rule added at 2am during an incident and never removed
- An IAM policy widened for a debugging session, then forgotten
- An RDS parameter changed by hand and never reflected in code
- Encryption or logging disabled temporarily to unblock a deployment
- A resource created directly in the console, outside any IaC pipeline
None of these are exotic. Every one of them is a rational response to time pressure. Drift is not a discipline failure; it is the predictable residue of operating a production system under load.
The second item on that list is the best-measured. Palo Alto Networks’ Unit 42 analysed more than 680,000 identities across 18,000 cloud accounts belonging to over 200 organisations, and found that 99% of cloud users, roles, services and resources held excessive permissions — with “excessive” defined precisely as permissions left unused for 60 days or more. Only 1% were scoped to what they actually did.
That is drift with a number attached. Almost none of those permissions were granted maliciously or carelessly; they were granted for a reason that expired, and nothing in the environment noticed the expiry. John Morello, then VP of Prisma Cloud at Palo Alto Networks, characterised the underlying difficulty in that report as the nature of cloud itself — “dispersed, rapidly evolving, and dynamically fluctuating” — which is a fair description of why point-in-time review never quite catches up.
Why is configuration drift dangerous?
Because it silently invalidates the assumptions everything else depends on.
Your threat model assumed a specific network boundary. Your compliance evidence described a specific control state. Your disaster recovery plan assumed you could rebuild from code. Drift breaks all three at once, and the failure is discovered at the worst possible moment:
- Rebuild failure. Infrastructure-as-code that no longer matches production cannot reliably recreate it. The recovery plan you tested is not the environment you have.
- Compliance gaps. Your evidence describes an approved configuration. An auditor examines the live one. The mismatch is the finding.
- Expanded attack surface. A forgotten ingress rule is indistinguishable from an intentional one until someone uses it.
- Compounding divergence. Drift is path-dependent. Each undocumented change makes the next one harder to reason about, until the safest option feels like leaving it alone.
This is not a theoretical risk profile. Unit 42’s 2026 Global Incident Response Report found that in more than 90% of the incidents it investigated, misconfigurations or lapses in security coverage materially enabled the intrusion. Attackers are not usually defeating controls; they are finding places where controls were never applied, or were applied and later quietly undone.
The deeper cost is epistemic. Once drift is significant, nobody trusts the documentation, so nobody maintains it, so the only source of truth becomes the live environment — which is exactly the state governance exists to prevent.
How do you detect cloud configuration drift?
There are three approaches to infrastructure drift detection, and they answer different questions.
There are three detection approaches, and they answer different questions.
| Approach | What it compares | Catches | Misses |
| IaC drift detection | Live state vs declared template | Divergence from code (CloudFormation drift detection, terraform plan) | Anything created outside IaC entirely |
| Policy / posture scanning | Live state vs rule set | Known misconfigurations against defined policies | Novel changes no rule anticipated |
| Change velocity baselining | Current change rate vs historical normal | Unusual activity patterns, including changes that individually look fine | Slow, low-volume drift below the noise floor |
The first two are widely deployed and both are point-in-time comparisons against a known reference. They are necessary, and they share a blind spot: they can only catch what someone already thought to describe.
The third is less common and is where early detection actually comes from.
What is a change velocity baseline?
A change velocity baseline is the normal rate and pattern of change for a given part of your environment — how many changes a resource type typically sees, from which identities, at which times, through which mechanisms.
Once you know normal, deviation becomes measurable. Consider what each of these tells you:
- IAM policy modifications in a production account jump from roughly two a week to nineteen in a single afternoon
- Security group changes begin arriving from a role that has never modified networking before
- Resource creation appears in a region your organisation does not operate in
- Console-originated changes spike in an account that is supposed to be pipeline-only
- Change activity clusters at 03:40 in an account whose team works a single timezone
No individual event in these examples is necessarily a violation. A rule-based scanner may pass every one of them. But the pattern is the signal — and it is the same signal set that surfaces credential compromise, rogue deployments and shadow IT, which is why velocity monitoring pays for itself beyond drift alone.
This is the mechanism behind Cloudeva.ai’s velocity baselining: rather than only asking whether a change violates a rule, it asks whether this volume and shape of change is normal for this account.
Which signals indicate anomalous cloud activity?
Five worth instrumenting first, in rough order of diagnostic value:
- Volume deviation — change count for a resource type materially above its trailing baseline.
- Identity novelty — a principal making a category of change it has no history of making.
- Origin shift — an account moving from pipeline-originated to console-originated changes.
- Timing anomaly — activity outside the working pattern of the owning team.
- Region expansion — any resource activity in an unused region, which is a long-standing indicator of both cryptomining abuse and unsanctioned experimentation.
The reason to prioritise these over adding more policy rules is coverage. Rules find known-bad configurations. Velocity signals find unexpected behaviour, which is a strictly larger and more useful category — and it does not require you to have anticipated the specific failure in advance.
How do you build infrastructure drift detection into daily operations?
- Ensure complete change capture. Organisation-wide CloudTrail across all regions, and AWS Config recording in every governed account. Drift you cannot observe cannot be baselined.
- Establish per-account baselines. Aggregate change activity by resource type, identity and origin over several weeks. Do not use a single global threshold — a busy development account and a locked-down production account have legitimately different normals, and one shared threshold guarantees both false positives and false negatives.
- Reconcile IaC continuously, not at deploy time. Run drift detection on a schedule rather than only when a pipeline happens to execute. A stack that has not deployed in three months is the one most likely to have drifted.
- Alert on deviation, not on volume. The failure mode of drift programmes is alert fatigue. Route deviations from baseline; suppress routine churn.
- Close the loop. Every confirmed drift item ends in one of two places — reverted, or promoted into code. “Acknowledged” is not a resolution, and a backlog of acknowledged drift is just drift with extra steps.
- Review baselines quarterly. Baselines are perishable. A team that adopts a new deployment pattern will trip its own thresholds until the baseline is refreshed.
Step two is where most implementations fail, and it fails quietly: a single global threshold produces enough noise that the team stops reading the alerts, and the programme is functionally dead while still appearing green on a status page.
Frequently asked questions
What causes configuration drift in AWS?
Chiefly manual changes made outside infrastructure-as-code — console edits during incidents, temporary permission grants that are never revoked, and hand-tuned parameters. Automated processes contribute too: autoscaling, service-linked role updates and third-party integrations all modify live state without touching your templates.
How often should you check for configuration drift?
Continuously for high-risk resource types such as IAM, security groups, encryption settings and public-facing endpoints. Daily is sufficient for most other resources. Periodic manual reviews are too slow to be useful, because drift’s cost is proportional to how long it goes unnoticed.
Can Terraform prevent configuration drift?
Terraform detects drift when you run a plan, and re-applying can correct it. It cannot prevent someone from changing infrastructure directly, and it has no visibility into resources created outside its state file. IaC narrows the surface for drift; it does not eliminate it.
What is the difference between configuration drift and a misconfiguration?
A misconfiguration is a setting that is wrong against a standard. Drift is a setting that has diverged from its own approved definition. Drift often produces misconfigurations, but a drifted resource can also be technically secure and still be a governance problem — because nobody authorised it and nobody knows it exists.
How does shadow IT detection work, and can it catch a rogue deployment?
By combining attribution with baselining. Attribution tells you which identity made the change; velocity baselining tells you whether that identity, at that time, at that volume, is behaving as it normally does. Attribution alone gives you a name; the baseline is what tells you the name is unexpected.
Want to know your environment’s normal change rate — and get told when it shifts? See how Cloudeva.ai baselines change velocity →