Announced this week, CloudFormation Drift Detection has been a long time coming! That being said, it's great when features like this are added to the platform and I get to use them everywhere without any effort on my part!
Combined with the recent CloudFormation console update, it's been a good "pre:Invent" for CloudFormation, and re:Invent 2018 is still a week away!
After switching to the new console, I had to go to the column settings to add in "Drift status" column:
Looking through the official docs, a few things jumped out at me:
- Only values that you have set can be detected. This means if you're using the default values for any of your resource properties, you won't see any drift on them...
- ...Except for objects in property arrays! This might be reported as drift even if a value is not specified (because deep equality is hard!) e.g. security group ingress/egress rules arrays. There's also reports of array-based properties reporting as drifted because they're being checked out of order - I can imagine it will get addressed soon.
- Detection is currently only supported for a limited set of resources at the moment, but it's still a solid list and will cover most resources you're interested in. I expect this will be a highly requested feature for service teams to implement when releasing new features, and for existing services not yet covered.
- You can do detection on a stack, or on a specific resource.
- You can't do detection on stack resources (i.e. stacks with nested stacks), but you can do it on the nested stacks in isolation; Yet another reason to not bother with nested stacks.
- You will need appropriate IAM permissions: For the new CloudFormation actions, and for the resources you're detecting on (e.g.
ec2:DescribeInstancesfor EC2 instances, etc). If you're using the managed CloudFormation policies, you'll be fine. - Drift cannot be detected across stacks, so resource attachments that span stacks will not show up.
- Some properties will not be supported, because it just doesn't make sense to return them e.g. passwords and Lambda code packages.
All in all this is a great feature to have, and I'm looking forward to new resources being added as the offering matures.
Some use-cases I'll be working on:
- Run drift detection as part of a deployment pipeline, flagging if the deployed stack has changed since the last deployment.
- Periodic detection on all stacks (particularly in production) with alerts being raised when detected.
If you've got other use-cases in mind, please share them in the comments below.