Infrastructure as Code has become the backbone of modern cloud infrastructure management. Tools like Terraform give teams the ability to define, provision, and manage infrastructure in a consistent, repeatable way. But there is one problem that creeps in over time — Terraform drift.
Terraform drift is the gap between what your state file describes and what actually exists in your cloud account. A security group rule gets edited in the AWS console during an incident. An auto-scaler adds instances that Terraform doesn't track. A failed apply leaves the state file describing infrastructure that only half exists. Over time, the state file quietly falls behind reality, and the next terraform plan surfaces changes nobody remembers making.
This guide covers how to detect, fix, and prevent drift. It also explains why drift is structural to the state-file model, and how infrastructure-from-code tools like Encore avoid it by design.
Terraform tracks infrastructure through a state file, a JSON document that maps your .tf configuration to real cloud resources. Every plan or apply compares that state against what's actually deployed. When they don't match, Terraform reports the difference as changes it wants to make.
Drift shows up in a few ways:
terraform plan
where resources show modifications you didn't write
The tricky part is that Terraform won't tell you about drift until you ask. Between runs, your state can quietly fall behind reality.
Most drift doesn't come from malicious changes. It comes from the gap between how teams intend to manage infrastructure and how they actually do it day-to-day.
Manual console changes are the most common source. A developer debugging a production issue opens the AWS console and edits a security group rule directly
What Terraform Drift Is and Why It Matters
Infrastructure drift in Terraform describes a mismatch between the "blueprint" — your .tf files and modules — and the actual resources running in the cloud, and the Terraform state file is the artifact that represents the platform's understanding of that blueprint.
Terraform drift occurs when the real-world infrastructure in your cloud provider changes without those changes being recorded in your Terraform configuration or state file.
For example:
You create an S3 bucket using Terraform, but later, someone manually adds a bucket policy directly via the AWS console
Drift can lead to:
- Security risks — e.g., manual policy changes introducing vulnerabilities
- Operational inconsistencies — Terraform overwriting changes unexpectedly
- Compliance issues — Actual infra no longer matches approved definitions
Terraform drift is riskier than it looks because the gap directly impacts security, compliance, reliability, and cost. You will learn concrete detection techniques, prevention best practices, and step-by-step remediation workflows that scale across teams and clouds.
The article covers native Terraform commands and their limits, automated continuous monitoring patterns, governance controls such as policy-as-code and RBAC, remediation decision frameworks, and a practical tool-evaluation checklist for selecting drift detection solutions. Real-world tradeoffs — including operational overhead, auditability, and cost implications — are emphasized so you can choose between manual processes and automated reconciliation.
Why Drift Happens
Drift is the term for when the real-world state of your infrastructure differs from the state defined in your configuration. This can happen for many reasons. Within the context of your configuration, it happens when adding or removing resources or changing resource definitions. External to your configuration, drift occurs when resources have been terminated or have failed, and when changes have been made manually or via other automation tools.
Terraform cannot detect drift of resources and their associated attributes that are not managed using Terraform. For example, Terraform will not detect changes in a virtual machine that have occurred as a result of installing applications locally or using a configuration management tool like Chef or Ansible.
Common reasons include:
- Manual changes in the cloud console or via CLI
- Automated scripts or third-party tools modifying infrastructure
- Emergency hotfixes applied directly to production
- Misaligned processes where Terraform is not the single source of truth
Drift can happen due to changes outside of the Terraform workflow, such as manual modifications, automated external processes, or resource eviction.
Manual changes: As a DevOps engineer, when you have severity one issues, you may make manual changes just to get the systems up and running, but this also means that you have to make these changes in the code afterward. Sometimes, you forget that you’ve made these changes, and your configuration will drift.
External processes: You may have automated processes outside Terraform’s control, such as autoscaling actions triggered by cloud providers or external scripts that make changes to your infrastructure.
Resource eviction: Due to cost-saving measures and policy violations, resources can be evicted or deleted, which can cause drift.
Drift is a significant concern that can lead to inconsistencies, complicating infrastructure management.
Common sources of infrastructure drift
Consistency is a key goal when managing infrastructure using Terraform. With IaC, you can keep multiple environments consistent, irrespective of how many times they are recreated.
Infrastructure drift undermines that consistency. Here are some of its common sources:
Manual changes
Manual changes are a primary cause of infrastructure drift
They forget to make the same change in Terraform. - Drift appears: In AWS, the Auto Scaling Group now has maxsize = 10. In the Terraform code and state, it still says maxsize = 5. Your infrastructure has drifted away from the desired IaC definition. - Drift detection: The next time you run terraform plan, Terraform shows a change that looks like this: ~ maxsize = 10 -> 5. This is Terraform telling you that the live configuration is different from what your code expects. - Decision point: You now have to choose: - Update the Terraform code to maxsize = 10 and apply it so the state matches reality. - Or keep max_size = 5 in code, apply, and intentionally roll the autoscaling limit back down.
This is Terraform drift in practice. Someone changes cloud resources directly, Terraform does not know until you compare desired state to live state, and you only regain control when you update code or apply a plan.
How Drift Is Detected
When infrastructure drift occurs, the first challenge is to identify it. As we have seen, drift has multiple sources, so it is not possible to track where and when the drift happens without a monitoring mechanism.
You can identify the existence of drift by running a couple of Terraform commands
The easiest way to detect drift is to run:
bash
terraform plan
Terraform will compare the current state in the .tfstate file with the actual state in the cloud provider and display the differences.
Terraform State. The state file and how Terraform tracks resources.
Terraform Refresh. The refresh command and reconciling real-world drift.
Terraform Plan. The plan command and reconciling desired configuration with real-world state.
Terraform Config
For ongoing monitoring, you can:
- Use AWS Config or Azure Policy to detect configuration changes
- Integrate drift detection into your CI/CD pipeline
- Schedule regular Terraform plans for visibility
Terraform drift detection identifies when the actual cloud infrastructure diverges from the declared Terraform infrastructure as code configuration, and this guide shows why that gap matters for security, compliance, reliability, and cost.
Throughout, the guide integrates platform-level capabilities that accelerate detection and remediation while keeping the analysis vendor-neutral except where env zero is introduced as a concrete example of automation and governance.
Native Terraform Commands and Their Limits
Terraform tracks infrastructure through a state file, a JSON document that maps your .tf configuration to real cloud resources. Every plan or apply compares that state against what's actually deployed. When they don't match, Terraform reports the difference as changes it wants to make.
Drift shows up in a few ways:
terraform plan where resources show modifications you didn't write
The tricky part is that Terraform won't tell you about drift until you ask. Between runs, your state can quietly fall behind reality.
Native detection relies on refresh and plan:
bash
terraform refresh
terraform plan
Refresh updates the state file to reflect reality. Plan then compares the refreshed state to the configuration. If they don't match, Terraform reports the difference as changes it wants to make.
The limits are explicit: Terraform cannot detect drift of resources and their associated attributes that are not managed using Terraform. For example, Terraform will not detect changes in a virtual machine that have occurred as a result of installing applications locally or using a configuration management tool like Chef or Ansible.
Remediation Workflows
Once drift is detected, you need to decide whether to keep or revert the changes.
If the change is intentional — Update your Terraform code to match the new configuration and commit the changes to version control.
If the change is unintentional — Run:
bash
terraform apply
This will revert the infrastructure to match your Terraform configuration.
Now your Terraform code and your infrastructure are out of sync.
Drift appears when live configuration differs from code expectations. You now have to choose: Update the Terraform code to maxsize = 10 and apply it so the state matches reality, or keep maxsize = 5 in code, apply, and intentionally roll the autoscaling limit back down.
The remediation decision framework involves:
- Audit the change origin: manual console, autoscaling, external script, or eviction
- Assess security and compliance impact
- Decide to codify the drift or revert it
- Update code and state in a controlled manner
Real-world tradeoffs — including operational overhead, auditability, and cost implications — are emphasized so you can choose between manual processes and automated reconciliation.
Prevention Best Practices
While you can’t eliminate drift entirely, you can reduce its frequency and
Governance controls such as policy-as-code and RBAC help keep the state file authoritative. Automated continuous monitoring patterns provide visibility before drift becomes operational risk.
Prevention best practices include:
- Make Terraform the single source of truth and enforce it via access controls
- Restrict manual console access with RBAC and just-in-time approvals
- Integrate drift detection into your CI/CD pipeline
- Schedule regular Terraform plans for visibility
- Use AWS Config or Azure Policy to detect configuration changes
- Reconcile external automation with Terraform outputs rather than direct resource mutation
You may have automated processes outside Terraform’s control, such as autoscaling actions triggered by cloud providers or external scripts that make changes to your infrastructure.
Drift is structural to the state-file model. Infrastructure-from-code tools like Encore avoid it by design.
Detection Methods Comparison
| Method | Scope | Frequency | Typical Use |
|---|---|---|---|
| terraform plan | Configuration vs live state | On demand | Ad hoc drift check |
| terraform refresh | State file update | Before plan | Reconcile state |
| AWS Config / Azure Policy | Cloud-native compliance | Continuous | Policy enforcement |
| CI/CD scheduled plan | Automated visibility | Regular | Ongoing monitoring |
| Manual console audit | Human review | Sporadic | Incident response |
Common Drift Sources
| Source Type | Example | How Drift Appears |
|---|---|---|
| Manual changes | Security group edited in AWS console during incident | terraform plan shows modification not in code |
| External processes | Autoscaler adds instances Terraform doesn't track | State shows fewer instances than live |
| Failed apply | State describes infrastructure that only half exists | Plan shows resources to create that already exist |
| Resource eviction | Cost-saving deletion removes resources | Plan shows resources missing |
Conclusion
Terraform drift is structural, not accidental. Terraform tracks infrastructure through a state file, a JSON document that maps your .tf configuration to real cloud resources. Every plan or apply compares that state against what's actually deployed. When they don't match, Terraform reports the difference as changes it wants to make. Between runs, your state can quietly fall behind reality, and the next terraform plan surfaces changes nobody remembers making.
Most drift doesn't come from malicious changes. It comes from the gap between how teams intend to manage infrastructure and how they actually do it day-to-day. Manual console changes are the most common source. A developer debugging a production issue opens the AWS console and edits a security group rule directly.
Drift can happen due to changes outside of the Terraform workflow, such as manual modifications, automated external processes, or resource eviction. Drift is a significant concern that can lead to inconsistencies, complicating infrastructure management.
Detection requires asking Terraform to compare. The easiest way to detect drift is to run terraform plan. Terraform will compare the current state in the .tfstate file with the actual state in the cloud provider and display the differences. For ongoing monitoring, you can use AWS Config or Azure Policy to detect configuration changes, integrate drift detection into your CI/CD pipeline, schedule regular Terraform plans for visibility.
Remediation is a decision, not an automatic revert. Once drift is detected, you need to decide whether to keep or revert the changes. If the change is intentional — Update your Terraform code to match the new configuration and commit the changes to version control. If the change is unintentional — Run terraform apply. This will revert the infrastructure to match your Terraform configuration.
Prevention reduces frequency but cannot eliminate drift entirely. While you can’t eliminate drift entirely, you can reduce its frequency and. Governance controls such as policy-as-code and RBAC, automated continuous monitoring patterns, and making Terraform the single source of truth keep the state file authoritative.
Terraform cannot detect drift of resources and their associated attributes that are not managed using Terraform. For example, Terraform will not detect changes in a virtual machine that have occurred as a result of installing applications locally or using a configuration management tool like Chef or Ansible.
The practical path is continuous detection, deliberate remediation, and governance that makes manual changes visible before they become security risks, operational inconsistencies, or compliance issues.