CloudFormation changesets - review changes before running a stack update

Brett Gillett

This post is part of a series of introductory articles related to building AWS services using AWS CloudFormation. You can read about CloudFormation Deletion Policy, CloudFormation Conditions, CloudFormation Parameters, and the DependsOn attribute in earlier posts

Think of a changeset as a dry-run - or an ‘Are you sure’ pop-up - it provides you with the opportunity to preview changes to AWS resources before you run the stack update.

Here’s a simple example of a generated changeset.

Example of a generated CloudFormation Changeset

The most critical columns in the above screenshot are ‘Action’ and ‘Replacement.’ Action tells you if you’re updating an existing resource or creating a new one. Replacement shows you the effect of your CloudFormation update on the identified resources.

If the value in the Replacement column is True (or Conditional), you would want to be sure the outcome is what you expected before executing the proposed changes. If not, you create another changeset that better reflects your changes or delete it altogether and start again.

OrbitOps Stop Coding. Start Building.

You can generate a changeset through the management console, via the AWS CLI, or programmatically using one of the AWS SDKs.
In our case, we’ve worked it into our CI/CD process. Whenever a commit occurs in one of our CloudFormation repositories, we generate a changeset by running the following AWS CLI command:

aws cloudformation deploy --template-file <template-file>
--stack-name $stackName
--no-execute-changeset --no-fail-on-empty-changeset
--capabilities CAPABILITY_IAM
--tags owner=$owner ownerEmail=$ownerEmail environment=$environment
--profile $profile

As far as changesets go, the critical options are –no-execute-changeset and –no-fail-on-empty-changeset.

The first option (–no-execute-changeset) generates the changeset but does not execute the proposed changes. Not allowing the changeset to run automatically is essential for several reasons. First, it will enable one person to generate the changeset (‘the committer’) while another person (‘the deployer’) is responsible for reviewing the changeset before deployment.
Second, it also allows us to follow any formalized change management process our customers may have - we generate the changeset anytime and wait for approval before updating the AWS resources.

The second option (–no-fail-on-empty-changeset) is needed because in most situations we’re deploying a complete solution via CloudFormation, which contains many related templates in a single pipeline. Without the second option, the deployment would fail if a single stack did not deploy any changes.

By leveraging changesets as part of your CloudFormation deployments, you’re able to protect yourself from unforeseen errors, practice separation of duties, and more effectively manage your AWS environment.

Brett Gillett


Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?