Configuration Drift

Configuration drift is a mismatch between an expected configuration and the configuration that actually exists. The expected state might be defined in an infrastructure-as-code template, a version-controlled operating-system baseline, or an approved security policy. For example, an administrator might temporarily open a security group to the internet during troubleshooting but forget to restore its original rules. The resource continues working, yet its configuration has diverged from the approved baseline.

Reliable drift management starts by defining the source of truth and the scope of comparison. Infrastructure templates describe particular resources and properties, while security policies express constraints such as requiring encryption or prohibiting unrestricted administrative access. These comparisons answer different questions. A resource can differ from its deployment template while still satisfying security policy, and it can match its template while remaining insecure because the template itself is flawed.

Cloud implementations combine change-triggered evaluations with scheduled assessments. Change-triggered checks shorten the interval between a modification and its detection. Scheduled checks provide recurring assurance and can assess conditions that do not have a suitable change trigger. Neither approach guarantees complete visibility: coverage depends on supported resource types, recorded properties, enabled accounts and Regions, permissions, and successful execution. A missed assessment or failed configuration recorder should therefore be treated as a monitoring gap, not as evidence of compliance.

On AWS, AWS Config records supported resource configurations and evaluates them using rules. Conformance packs package rules and remediation configurations to deploy a consistent assessment baseline across accounts and Regions. Rule evaluations may be change-triggered, periodic, or both, depending on the rule. Organization-wide aggregation supports centralized investigation, but aggregating results does not itself deploy rules or remediate resources.

Host-level configuration requires a different mechanism. AWS Systems Manager State Manager uses associations to apply desired configurations to managed nodes on a defined schedule or when otherwise triggered. An association might ensure that a security agent is installed and configured. Its compliance results reflect the association’s execution and assessment logic; they are not proof that every host setting remains continuously correct between executions. AWS Security Hub security controls and integrated findings provide centralized security posture visibility, but they do not replace infrastructure-template comparisons or host configuration enforcement.

Detection should lead to a controlled response. Preserve the observed configuration, identify the responsible change using audit records, assess the impact, and either restore the baseline or approve and codify the new state. For example, an unexpected inbound access rule can generate an alert and start a remediation workflow. Low-risk corrections can be automatic, while changes that might interrupt production traffic should require approval. Remediation should use least-privilege permissions, bounded retries, and checks that the resource is still noncompliant before modification.

Automation introduces trade-offs. Frequent assessments increase execution costs and API activity, while slower schedules leave longer exposure windows. Uncoordinated controllers can repeatedly overwrite one another, and automatic rollback can erase a legitimate emergency change. Use explicit ownership, time-limited exceptions, idempotent remediation, and post-remediation verification. Infrastructure as code reduces opportunities for drift but does not prevent out-of-band changes by itself. Drift detection is also not threat detection: an unexpected change warrants investigation, but it is not automatically malicious.