Cloud environment drift is one of the quietest ways infrastructure gets compromised. A developer makes a manual change in the console to fix a production incident. A security team tightens an IAM rule directly. An autoscaling event adjusts a resource that no template anticipated. None of these changes get committed back to the codebase. Six months later, nobody can explain why the environment no longer matches the Terraform or CloudFormation state file, and deployments start failing in ways that look inexplicable.
Australian IT teams running workloads on AWS, Azure, or GCP encounter drift constantly. It isn't a sign of bad engineering. It's the predictable result of building complex systems under time pressure, without enforcing the discipline to keep code and reality synchronised.
What drift actually looks like
Drift doesn't announce itself. It accumulates. The most common form is a configuration mismatch: a security group rule added manually during an incident that never made it into the infrastructure-as-code repo. A database parameter tuned through the cloud console. A storage bucket permission adjusted by a team that didn't have access to deploy from code. Each change is defensible in isolation. Collectively, they pull the live environment away from what the codebase describes.
The second form is resource drift: cloud resources that exist in the live account but not in any state file. These are usually orphaned from a previous deployment, a one-off experiment, or a service that was manually created before the team adopted infrastructure-as-code. They keep running, keep billing, and keep carrying whatever security posture they had when someone last touched them manually.
The third form is dependency drift. A module version pinned in code gets updated in the registry. An AMI referenced by its latest alias points to a different image than it did when the template was written. The code looks the same. The environment isn't.
Why drift is a security problem, not just a hygiene issue
Configuration drift is often framed as a DevOps concern. It's actually a security exposure. When live infrastructure diverges from declared state, your security posture is no longer what your code reviews, your audit logs, or your compliance controls assume it is. A manually added IAM permission that never went through a pull request bypasses every approval gate you built. A security group rule added at 2am during an outage might open a port that should never be public.
Cloud IAM misconfigurations are already one of the most common attack vectors facing Australian organisations. Drift makes them harder to catch because the gap between intended state and actual state isn't visible in the code. You'd need to compare the live environment directly against the state file to find it, and most teams only do that when something breaks.
The cloud IAM misconfigurations that most commonly affect Australian teams start exactly here: a permission granted manually during an emergency, never revoked, sitting in the live environment while the declared policy says something different. Drift is the mechanism that keeps those misconfigurations invisible.
How to detect drift before it causes damage
The tooling exists. The discipline to use it consistently is what most teams lack.
Terraform provides terraform plan and the dedicated terraform refresh command to compare live state against declared configuration. Running a plan against production before any deployment will surface drift as proposed changes the team didn't intend. AWS Config continuously records resource configuration changes and can flag deviations from desired state. Azure Policy and GCP's Config Controller offer similar capabilities. The problem is that most teams run these checks reactively, after something breaks, rather than as a scheduled baseline check.
A more practical approach: schedule a weekly drift detection run as part of your CI/CD pipeline. Don't just run it on deployments. Run it independently, against every environment, and alert on any detected diff that wasn't initiated by a code change. Tools like Driftle, Spacelift, and Atlantis can automate this for Terraform-managed infrastructure. For AWS specifically, CloudFormation Drift Detection can run on a schedule via EventBridge.
Pair detection with tagging. Resources that exist in the live account but carry no IaC-managed tag are drift candidates by default. A consistent cloud tagging strategy makes unmanaged resources visible in cost and security reports, not just in dedicated drift tooling.
Fixing drift without breaking production
Detection is the easy part. Reconciliation is where teams make mistakes.
The instinct is to force the live environment back to the declared state immediately. That instinct is dangerous. If someone manually adjusted a configuration to keep a production system running, overwriting it with the previous declared state takes you back to the problem that caused the manual change. Before you remediate drift, you need to understand why it happened.
A structured remediation process works in three steps. First, inventory the drift: list every deviation, categorise it as a configuration change, a new resource, or a deleted resource, and record who made the change and when (cloud provider audit logs are the source of truth here). Second, decide which direction to reconcile: either update the live environment back to declared state, or update the declared state to capture the legitimate change. This is a human decision, not an automated one. Third, close the gap that allowed the drift in the first place, which almost always means tightening console access and adding a detection check to the deployment pipeline.
For teams running workloads across AWS, Azure, and GCP simultaneously, drift management gets harder because each provider's tooling is different. A multicloud environment needs a consistent detection layer above the provider tools, not three separate drift-checking processes that nobody coordinates.
Prevention: making drift structurally harder
The most effective drift prevention is removing the path that creates it. If engineers can't make manual changes to production infrastructure through the console, they can't cause console-driven drift. That means restricting direct console access for production environments, routing all changes through infrastructure-as-code pipelines, and using short-lived credentials that don't persist past a deployment session.
This isn't about distrust. It's about removing the option that bypasses the audit trail. When a production incident demands a fast fix, engineers should be deploying a targeted IaC change, not clicking through a console. That requires pipelines fast enough to be useful under pressure, which is a separate engineering challenge, but a solvable one.
Immutable infrastructure patterns help too. If every deployment replaces resources rather than modifying them, there's no in-place configuration to drift from. Container-based workloads managed through Kubernetes or ECS already benefit from this to a degree. The principle extends to virtual machines, network configurations, and IAM policies when teams are disciplined about it.
Cloud environment drift won't disappear entirely. The goal is to make it detectable within hours rather than months, and reconcilable through a clear process rather than a guessing game. Teams that schedule drift detection, restrict console access to production, and close the loop on every manual change will catch the gaps before attackers or auditors do.