Published:
Estimated reading time:
8–9 minutes
Cloud Drift Detection: What It Is and Why It Matters
Cloud infrastructure rarely stays exactly as it was originally deployed. Engineers make emergency changes, deployment pipelines update resources, automation modifies configurations, and organizational requirements evolve over time.
Some of those changes are expected. Others create a gap between what the organization believes should exist and what is actually running in the cloud.
That gap is commonly called cloud drift. Drift detection identifies these differences so teams can determine whether a change is legitimate, should become the new desired state, or needs to be corrected.
What Is Cloud Drift?
Cloud drift occurs when the actual state of a cloud environment no longer matches an intended or required state.
The most familiar example involves Infrastructure as Code. Terraform might define a security group that allows HTTPS traffic from a specific network. If someone later modifies that security group directly in AWS, the live configuration no longer matches what Terraform expects.
But Infrastructure as Code represents only one kind of expected state. An organization may also require production storage to use encryption, prohibit unnecessary public exposure, or require logging in sensitive environments. Those requirements can change even when the infrastructure itself does not.
This gives cloud teams three useful states to consider:
Intended state: What engineering systems such as Terraform, CloudFormation, or Bicep expect.
Required state: What security policies, compliance controls, and governance requirements say must be true.
Actual state: What currently exists in AWS, Azure, or Google Cloud.
Drift detection compares actual cloud state with the expectations that matter.
Configuration Drift vs. Governance Drift
The distinction between configuration drift and governance drift is important because they answer different questions.
Configuration drift occurs when live infrastructure no longer matches the configuration engineering expects. A Terraform-managed security group changed manually through the AWS console is a straightforward example.
Governance drift occurs when live infrastructure no longer satisfies an organizational requirement. That can happen because the infrastructure changed, but it can also happen because the requirement changed.
Suppose an organization introduces a new requirement that sensitive production storage must use customer-managed encryption keys. Existing infrastructure may still match Terraform perfectly, but it can now violate the organization's required state.
The reverse can also happen. An engineer might make a legitimate emergency change directly in the cloud. Terraform now differs from production, creating configuration drift, even though the new live configuration may be operationally correct.
Drift detection therefore should not automatically assume that one side of the comparison is right. Its first job is to expose the difference.
Why Cloud Environments Drift
Cloud environments are dynamic systems, so some amount of drift is inevitable. Engineers make emergency changes during incidents, automation operates outside the primary IaC pipeline, managed cloud services modify runtime state, and teams occasionally use provider consoles or APIs directly.
Infrastructure as Code reduces this problem by making configuration versioned, reviewable, and repeatable, but it cannot guarantee that the live environment remains identical to the repository. Cloud providers still expose APIs and consoles independently of Terraform, CloudFormation, Bicep, or other provisioning systems.
Organizational requirements also evolve. A configuration that satisfied security policy six months ago may no longer satisfy today's requirements, even if nobody changed the resource.
The objective of drift detection is therefore not to prevent all change. It is to identify when change has created a meaningful difference between reality and intent.
Not Every Difference Is a Problem
Cloud infrastructure contains plenty of state that is expected to change. Autoscaling groups adjust capacity, ephemeral resources appear and disappear, managed services modify supporting infrastructure, and operational systems respond dynamically to runtime conditions.
A useful drift-detection system needs to distinguish these expected changes from state that should remain controlled.
Even an unexpected difference is not necessarily wrong. An emergency production change may have solved a real problem and should now be incorporated into Terraform rather than reversed.
When drift is detected, teams generally have several possible responses. They can restore the live environment to the intended state, update the intended state to reflect an approved change, document an exception, or investigate further before deciding.
This is why detecting drift and resolving drift are separate problems.
Why Drift Detection Needs to Be Continuous
A one-time comparison provides only a snapshot. Infrastructure can change immediately afterward, and organizational requirements can evolve independently of deployments.
Continuous drift detection repeatedly evaluates actual cloud state against the expectations that matter. Different controls may operate at different frequencies or respond to provider events, but the important characteristic is that evaluation continues throughout the infrastructure lifecycle.
This is also why pre-deployment IaC scanning is not sufficient on its own. It can determine whether proposed infrastructure satisfies a requirement before deployment, but it cannot prove that the live environment will remain in that state afterward.
A strong governance model evaluates both what teams intend to deploy and what actually exists.
Drift Detection Is Part of Continuous Governance
Security posture management, compliance monitoring, IaC drift detection, and cloud governance all encounter variations of the same underlying problem: does the environment still look the way it should?
The expected state simply comes from different places.
Terraform may define engineering's intended configuration. A CSPM policy may define an acceptable security condition. A compliance control may define a technical requirement, while a broader governance policy might incorporate ownership, environment, criticality, or other organizational context.
Continuous Governance connects those requirements to the live environment instead of treating evaluation as something that happens only during deployment or periodic audits.
That broader context also helps determine how important a finding is. An unexpected configuration in an experimental development environment may require a different response from the same condition in a business-critical production environment.
Remediation Should Address the Source of Truth
Once drift is detected and determined to be undesirable, the next question is how to correct it.
For infrastructure managed through IaC, directly changing the live resource may provide only a temporary fix. If Terraform still contains the original configuration, the next deployment can recreate the problem.
A durable remediation should generally update the system responsible for managing the infrastructure. That can produce a workflow such as:
Detect → Investigate → Update IaC → Validate → Review → Deploy → Verify
Not every remediation belongs in IaC. Some operational conditions require discrete actions rather than persistent configuration changes. The execution mechanism should match the type of problem.
What matters is that remediation addresses the appropriate source of truth and that the environment is evaluated again afterward. Deploying a change is not proof that the original requirement has been satisfied.
AI Can Help Determine Which State Should Win
Detecting that two states differ is relatively mechanical. Determining what should happen next can require much more context.
An AI system can investigate the live environment, relevant Infrastructure as Code, organizational policies, dependencies, and ownership information before proposing a response. This can be particularly useful when a manual change may have been intentional or when satisfying a governance requirement requires more than restoring a previous value.
For example, AI might identify a manually modified network rule, determine what depends on it, locate the Terraform module responsible for the resource, and propose a code change that preserves legitimate connectivity while satisfying the security requirement.
The value comes from reasoning about the difference before trying to fix it.
The resulting remediation can still pass through deterministic validation, repository permissions, human review, and existing deployment workflows. AI helps determine the appropriate solution without becoming the final authority over production.
Multi-Cloud Drift Requires Common Intent, Not Identical Clouds
AWS, Azure, and Google Cloud expose different resources, APIs, policy mechanisms, and configuration models. Drift detection therefore has to understand the provider-specific state it is evaluating.
Organizational requirements can still remain consistent across providers.
A company might require production object storage to prevent unauthorized public access regardless of where it runs. Evaluating that requirement will involve different provider-specific controls for Amazon S3, Azure Blob Storage, and Google Cloud Storage, but the governance intent remains the same.
This separation allows organizations to maintain common requirements without reducing different cloud providers to an artificial lowest-common-denominator model.
How StratoCloud Approaches Cloud Drift
StratoCloud approaches drift primarily through Continuous Governance, where organizational requirements can be evaluated against current cloud environments across AWS, Azure, and Google Cloud.
Namespaces and cloud-agnostic labels provide organizational context around AWS accounts, Azure subscriptions, and Google Cloud projects. This allows governance requirements to target environments according to concepts such as ownership, business function, environment, or criticality rather than depending exclusively on provider hierarchy.
Evaluation can use live provider APIs to understand current cloud state instead of assuming that an IaC repository or synchronized resource inventory perfectly represents what exists right now. When a finding requires deeper investigation, AI can query additional cloud state and combine it with the organizational context StratoCloud already understands.
If the appropriate remediation belongs in Infrastructure as Code, Intelligent Remediation can generate a proposed change inside an isolated execution environment, validate it with appropriate tooling, and deliver it through an authorized GitHub pull request. The organization's existing review and deployment workflow remains responsible for deciding whether that change reaches production.
Continuous Governance can then evaluate the requirement again after deployment, closing the loop between required state and actual state.
Drift Detection Is Really About Maintaining Intent
Cloud drift is not fundamentally about forcing infrastructure to remain unchanged. Cloud environments are supposed to change.
The important question is whether those changes remain consistent with what engineering and the organization intend.
Infrastructure as Code provides one representation of that intent. Security policies, compliance controls, and governance requirements provide others. Live cloud APIs reveal the actual state that exists right now.
Drift detection connects those perspectives. When reality diverges from intent, teams can determine whether the change should be accepted, incorporated into the desired state, documented as an exception, or remediated.
That makes drift detection less about keeping infrastructure static and more about preventing change from silently separating reality from intent.
Frequently Asked Questions
What is cloud drift?
Cloud drift occurs when actual cloud state differs from an intended or required state. This can include differences from Infrastructure as Code as well as differences from security, compliance, or governance requirements.
What is drift detection?
Drift detection compares actual cloud configuration with an expected state and identifies meaningful differences. The expected state may come from IaC, organizational policies, security standards, or other governance requirements.
Is cloud drift the same as Terraform drift?
No. Terraform drift is one form of cloud drift in which actual infrastructure differs from Terraform's expected state. Cloud drift can also occur when actual infrastructure no longer satisfies organizational requirements.
What is governance drift?
Governance drift occurs when actual cloud state no longer satisfies an organizational requirement. This can happen because infrastructure changes or because the organization's requirements change.
Is all cloud drift bad?
No. Some differences are intentional or part of normal cloud behavior. Drift detection identifies the difference so teams can determine whether to accept it, incorporate it into the intended state, create an exception, or remediate it.
Can Infrastructure as Code prevent drift?
IaC reduces inconsistency and provides a strong representation of desired state, but cloud APIs, consoles, other automation, runtime behavior, and changing organizational requirements can still create drift.
How should cloud drift be remediated?
The response depends on the source of truth and why the difference exists. For IaC-managed infrastructure, durable remediation generally means updating the relevant code, validating and deploying the change, and then verifying the live environment again.
Can AI help with cloud drift?
Yes. AI can investigate why actual and expected state differ, examine surrounding cloud infrastructure and IaC, and generate a proposed remediation. Authorization, validation, approval, and production execution can remain governed by deterministic controls.
