Everything you need to know about CloudFormation Drift Detection

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:DescribeInstances for 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.