Article

Using AWS CloudFormation Drift Detection

On November 14th, AWS announced the release of the long-anticipated Drift Detection feature for CloudFormation. This has been a common feature request among many AWS customers that seek to ensure their deployments are configured as expected. This post will walk you through why this is an important feature and how it can be used.

What’s the Big Deal?

If you’re not familiar with it already, CloudFormation is a free service from AWS that lets you describe your infrastructure through a YAML or JSON file and then deploy the configuration. Simply define your desired state and CloudFormation will deploy the resources and arrange them so that dependent services are (usually) deployed in the correct order. If you’re familiar with Ansible, Chef, or Puppet, this concept of a desired state shouldn’t be new.

As a consultant, I’m often trying to highlight the importance of this tool and how some sort of IaC should be used to manage the environment. That’s usually easy at the start. But, inevitably something will happen or an emergency occurs where a manual change gets made to the environment and the code doesn’t get updated. Maybe that isn’t a big deal, but what subsequently happens when someone then updates the code for another change and applies a change set? That’s right–that manual change that was made in the middle probably got wiped out, and whatever issue occurred before is likely back.

Introducing Drift Detection

Now that the new feature has been released, let’s take a look at it in a lab. The screenshot below is a list of CloudFormation templates that have been applied in one of my own lab environments. Obviously, I’m always updating my infrastructure through code, so I should have nothing to worry about. But let’s test this new feature out anyway, just for fun.

I’ve selected one of my stacks and then hit the “Actions” drop-down, followed by the “Detect drift” option. Notice that this is also a nested stack and will work just fine.

After you select “Detect drift”, a notification bar will be displayed, alerting you that drift detection was initiated.

Select the stack again and then click the “View drift results” drop-down from the “Action” button.

The drift detection page opens to show… wait a second! I’d apparently made a manual change to a security group somewhere along the way, so the drift detection capability now displays what no longer matches my template.

If we select the resource that has drift, we can click the “View drift details” button to get more information. As we can see from the following screen, I have replaced one of my source addresses with an anywhere (0.0.0.0/0) rule.

If we scroll further down, we’ll see the current configuration vs the template used to deploy the resource. This can be a great tool to get some of the same manual changes that were made to the environment into the CloudFormation templates stored in your version control repo.

Summary

CloudFormation has been a great tool to manage your AWS infrastructure and I’ve often said that it should be the only way that you interact with the AWS infrastructure. The ability to keep a desired state is enough reason to use it over the CLI or the AWS web console. Now that we can review the infrastructure with what we deployed, implementing this tool as part of your AWS operations is even more powerful. 

This post originally appeared on TheITHollow.