In a previous post, we looked at how to use change sets with CloudFormation. This post covers how to use change sets with a nested CloudFormation Stack.

If you’re not familiar with nested CloudFormation stacks, it is just what it sounds like. A root stack or top level stack will call subordinate or child stacks as part of the deployment. These nested stacks could be deployed as a standalone stack or they can be tied together by using the AWS::CloudFormation::Stack resource type. Nested stacks can be used to deploy entire environments from the individual stacks below it. In fact a root stack may not deploy any resources at all other than what comes from the nested stacks. An example of a commons stacking method might be to have a top level stack that deploys a VPC, while a nested stack is responsible for deploying subnets within that stack. You could keep chaining this together to deploy EC2 instances, S3 buckets or whatever you’d like.

Deploying a Change Set for a Nested Stack

As you can see from the first screenshot below, I have a nested stack that deployed a subnets stack and the root stack is my VPC-Deploy stack. For this example, lets assume I need to modify my subnets. Pretend for a second, I goofed up the IP addressing. Now from our previous post, you might just go and assign a change set to the subnets stack, but since it is part of a nested stack we want to make sure not to break that chain. Remember if we later need to update the VPC stack, we’ll want to make sure that we don’t break the nested stack as well.

Here’s the problem. If we attempt to deploy a change set on our VPC-Deploy stack, one of the changes listed will be to subnets, but you won’t see what those changes are. To test and make sure that only the changes you want to be made are staged, let’s perform the first parts of deploying a changes set on our subnets stack, but we WILL NOT execute it.

So as we’ve done previously, create a new change set for our nested stack.

NOTE: When you attempt to deploy a change set on a nested stack a warning message will pop up reminding you that this could cause your stack to be out of sync since it’s a nested stack. Continue through this process, but remember not to deploy the change.

Select your template.

Add your details.

Add your tags and set the permissions appropriately.

Review and click “Create Change Set” button.

When we review the changes we can see that I’ll be replacing two subnets and two route tables.

At this point we know that the changes that we had wanted to make are reflected correctly in CloudFormation. If we saw changes in the previous screen that we didn’t want to make, we would know it at this point.

Really Deploy a Change Set at the Root Stack

Now that we’ve tested that, let’s actually set the change set on our root stack. Select it from the list and go through the same process with our root template. Remember that the child template is probably the only thing that changed, so the root template should be the same.

Once we go through all of the screens, notice what the stack update looks like. Here we see a single change, not on the subnets and the routing tables themselves, but rather the subnets CloudFormation stack. This is the reason we pushed the change set to the child stack first, so we could see what those changes would be. The root stack update makes this visibility difficult.

Deploy the change set on the root stack and the nested stacks should be updated accordingly.

Summary

Using change sets on a nested CloudFormation stack isn’t much different from using them on a stand alone stack, but in order to get the same visibility, testing them out but not deploying them, on the nested stack is an easy way to achieve this. Just be careful not to deploy them so that the root and child stacks don’t get out of sync.