Configuration drift detection and management
6/10 MediumInfrastructure managed by CloudFormation can drift when modified through AWS Console, SDK, or CLI. Without proper tools, detecting and reconciling these changes is manual and error-prone.
Sources
- https://experience.percona.com/postgresql/postgresql-complexity-and-your-business/enterprise-scale-challenges-real-world-postgresql-issues-youll-face
- https://aws.amazon.com/blogs/devops/aws-cloudformation-2025-year-in-review/
- https://blog.tryterracotta.com/why-is-terraform-still-hard-in-2025/
- https://hoop.dev/blog/pain-point-terraform-hits-hard-when-your-infrastructure-grows-faster-than-your-control-over-it/
- https://dev.to/mechcloud_academy/the-tough-side-of-terraform-10-challenges-youll-face-and-how-to-tackle-them-376n
Collection History
The moment your infrastructure touches the real world, it starts to drift. An engineer fixes something manually in the AWS console. It doesn't know about the out-of-band changes. It doesn't warn you that a resource has drifted. It happily wipes out your fix and calls it 'safe.'
A PostgreSQL instance in AWS might be configured differently than one running on-prem, leading to unexpected query performance differences and security gaps. Schema changes, replication settings, and connection pooling can drift over time, causing failures during failover or recovery.
Configuration drift occurs when infrastructure managed by CloudFormation is modified through the AWS Console, SDK, or CLI. Drift-aware change sets address this challenge by providing a three-way comparison between your new template, last-deployed template, and actual infrastructure state.