Drift is a comparison with a defined scope
CloudFormation drift detection compares supported resource configuration with the expected configuration represented by the stack. It is useful for identifying changes made outside the stack workflow, such as an emergency security-group edit or a manually altered setting.
A stack reporting no detected drift is not a complete security or configuration audit. Resource support and property coverage matter, and some resources can be reported as not checked. Values left implicit in the template can also limit what the comparison establishes.
Setup: preserve intended and current state
Record the stack ID, Region, current template, parameter values and relevant nested stacks. Identify the service owner and any emergency changes recorded during recent incidents. A manual difference may be intentional mitigation that should be represented in code, rather than immediately reversed.
Check the current resource-type support and required read permissions. Keep the detection request and completion state in the change record. Starting detection is different from receiving its final result; a stale previous result should not be presented as evidence about a later manual change.
Review drift results in sequence
- Run an approved detection operation and wait for its final status. Record the timestamp and distinguish detection failure from a completed comparison.
- Inspect each resource result, including unchecked or failed items. Determine which properties were represented and compared instead of treating the stack-level summary as the entire inventory.
- Map reported property differences to the owning service and the change history. Compare the expected and actual values with the reason for any operational intervention.
- Review nested-stack coverage explicitly. Investigate a nested stack at its own supported boundary where required, rather than assuming every descendant was fully checked by one parent operation.
Illustrative incident: a manual mitigation is nearly overwritten
In this illustrative scenario, an operator adds a narrow network rule to restore a business integration during an incident. The later drift report correctly identifies the difference. Another engineer proposes reverting it immediately to make the stack summary green.
The service owner reviews the mitigation, confirms the application dependency and incorporates the approved rule into the template through a normal change review. The team then verifies fresh drift evidence. This constructed example explains reconciliation ownership; it does not document an actual Clouvenix incident.
Diagnostic table
| Observation | Evidence | Meaning |
|---|---|---|
| Detection operation fails | Status reason and read permissions | Comparison did not complete |
| Resource is not checked | Current type and property support | Coverage gap |
| Actual value differs | Property path and change history | Reconciliation decision needed |
| Parent looks clean, child differs | Nested stack identity and result | Scope needs explicit review |
Correct the desired state deliberately
Decide whether the actual resource or the template represents the approved configuration. Prepare a reviewed change set or supported service correction accordingly. A drift report is evidence for that decision, not authority to delete an emergency mitigation or recreate a stateful resource.
After the correction, run a new detection and validate the representative application operation. Include controls outside drift coverage in the broader configuration review. Keep the result associated with its template revision and time, since resources can change again immediately after detection.
Monitoring and SOP
Schedule drift reviews according to workload ownership and change frequency, and route unresolved differences to a named operator. Track unchecked resources as explicit coverage gaps. The SOP should retain the detected property, approved desired state, owner decision and verification evidence so a clean summary remains explainable rather than becoming the only operational objective.
See Clouvenix cloud architecture for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 20 October 2026; confirm behavior for your deployed edition and version.