Infrastructure drift control
Add a read-only drift check to the delivery workflow
Detect changes without automatically applying a correction. Give the owning team a useful difference and enough context to decide what should happen.
In this article
Select a clear scope
Start with one maintained stack or workspace and identify its owner. Confirm which resources and properties the chosen tool can inspect.
Use an identity with the access needed to observe that scope and protect any resulting state or plan artefacts. Read-only inspection can still reveal sensitive configuration.
Keep detection separate from an apply job. A scheduled check should not gain mutation authority merely because the normal deployment pipeline has it.
Produce an actionable result
Capture the resource identity, changed property and expected versus observed state where safe to display. Link to the maintained definition and recent change records.
{
"scope": "production-api-example",
"resource": "network-rule-example",
"property": "allowed-source",
"observedChange": "narrowed during incident",
"decision": "pending-owner-review",
"automaticCorrection": false
}This illustrative record includes investigation context. The detector itself may only know the difference, so do not automatically infer the reason from a property name.
Avoid putting secret values in alerts. Refer authorised reviewers to a protected artefact when detailed inspection is required.
Route the finding to an owner
Notify the responsible team through the established operational channel and create a tracked item with a suitable priority. A public exposure change deserves different urgency from a harmless metadata difference.
Group repeated observations of the same unresolved change so every scheduled run does not create another identical incident.
Record whether the difference is accepted temporarily, being corrected or outside the detector's intended ownership. Each outcome should have a reason.
Verify reconciliation
After the team changes code or restores the intended resource state, rerun detection and test relevant service behaviour. A clean difference does not prove the application still works.
For an intentional external controller, document the ownership boundary and the checks that replace ordinary drift monitoring for that field.
Expand the check to more scopes once ownership, sensitive-output handling and response are working. Detection that produces unattended reports adds noise without making the environment more reproducible.
Primary sources
AWS CloudFormation: drift detectionReferences checked 11 September 2026.