AWS DevOps Blog
Use Nested Stacks to Create Reusable Templates and Support Role Specialization
When you create AWS CloudFormation templates, you might find that you’re continually describing the same set of resources in different templates. However, instead of repeatedly adding them to each of your templates, consider using nested stacks.
What are Nested Stacks
With nested stacks, you can link to a template from within any other template. You simply create a separate template for the resources that you want to reuse and then save that template in an Amazon S3 bucket. Whenever you want to add those resources in another template, use the AWS::CloudFormation::Stack resource to specify the S3 URL of the nested template.
When to Use Nested Stacks
An example will show when and how nested stacks are useful. Imagine that you have two websites. Their templates are identical except for their backend database, as shown in the following figure:
Instead of describing the load balancer and autoscaling group in both templates, you can create a separate template and link to it, as shown in the following figure:
When you use the Website1 template to create a stack, CloudFormation creates two stacks (the Website1 stack and a nested Frontend stack). CloudFormation treats the nested stack as a resource of the parent stack. For example, if you update or delete the Website1 stack, CloudFormation updates or deletes the nested Frontend stack.
If you use the Website2 template to create a stack, CloudFormation creates another two stacks (the Website2 stack and a nested Frontend stack). Although the Website1 and Website2 stacks link to the same template, CloudFormation creates a new nested stack for each website (the nested stacks aren’t shared).
You can also customize each nested stack. For example, if the website stacks required different configurations for their load balancers and autoscaling groups, you can use input parameters to customize those resources.
When you’re deciding to use nested stacks, consider how much customization you need to do. The more customization each resource requires the less beneficial nested templates become. However, if you can easily reuse a template pattern without too much customization, you can use a nested stack.
Why Use Nested Stacks
Assume that you wanted to use the Frontend resources to create more websites. You can easily reuse the Frontend template by including it as a nested stack. You don’t need to manually add front-end resources to every new website template that you create.
In addition to being more efficient, nested stacks make assigning ownership to stack resources easier. Because nested stacks are separate templates, you can have separate owners maintain each template. For example, the owners of Website1 and Website2 don’t need to worry about maintaining the load balancer and autoscaling group. They just nest the Fontend template in their website templates.
Meanwhile, the owners of the front-end resources can make changes to their template, such as increasing the desired capacity size of the autoscaling group, without interfering or modifying anyone else’s template. And stacks that are using the Frontend template will get the changes the next time the stacks are updated. In other words, you can take advantage of role specialization, letting the experts own and make changes to the resources that they understand.
Anytime you see a pattern in multiple templates, look to see if you can use nested stacks. Nesting makes your templates easier to reuse and assign ownership. Also, just like any other stack, you can send inputs to and get output from the nested stacks. For sample templates, see Stack Resource Snippets in the AWS CloudFormation User Guide.