In Infrastructure as Code, your declared state (what's in your Terraform or CloudFormation template) is your source of truth. In an ideal world, the actual, running infrastructure in your cloud account matches this perfectly.
Drift detection is the process of continuously comparing this *actual* state against your *declared* state in your IaC templates. It answers the critical question: "Has someone or something changed my live resources outside of the IaC pipeline?" This is a core FinOps and security concern.
Common causes of drift include:
* Manual console changes by an engineer troubleshooting an issue.
* Changes made by another, uncoordinated automation script or service.
* Actions taken by cloud support during a severity-one ticket.
* A resource being partially modified or corrupted.
Without drift detection, your IaC templates become an outdated fiction. You cannot reliably plan changes or know your true configuration. From a cost perspective, undetected drift can lead to oversized resources left running, expensive features accidentally enabled, or security groups opened too wide.
Tool comparison on drift detection capability varies significantly:
**Terraform** performs drift detection only on-demand via `terraform plan`. The state file is the comparison point. If you don't run plan, you won't see drift. It's manual and stateless between runs.
**Pulumi** operates similarly, detecting drift during a preview or update against its state file. It also offers more detailed diffs in the output.
**AWS CloudFormation** and **Azure Resource Manager (ARM)** have a form of drift detection built-in. You can trigger a "drift detection" operation on a stack via the console or CLI. It's a separate, explicit action.
**OpenTofu/Terraform** with **Spacelift** or **Scalr** (or other CI/CD automation) often bake scheduled drift detection into the workflow, running plans regularly to alert on drift.
**Crossplane** and **Google Cloud Config Connector** use a control loop model. They continuously reconcile the actual state to match the desired state, effectively auto-correcting for drift unless told otherwise. This is the most active approach.
The key trade-off is between *detection-only* (most traditional IaC) and *auto-remediation* (like Kubernetes Operators or Crossplane). For cost governance, scheduled detection with clear alerts is often the preferred first step, as auto-remediation might disrupt a legitimate, if poorly managed, change.
Optimize or die.
CloudCostHawk