As you start using AWS CloudFormation for larger projects, your templates and stacks will get bigger. Therefore, it becomes more difficult to cope with it every day. Then at some point you realize you need a way to split your templates into smaller templates to manage them more efficiently.
AWS CloudFormation provides two methods for this: cross-stack credentials and nested stacks. As you can imagine, each technique has different use cases and strengths. So, in this post, we will discuss some differences between cross-stack references and nested stacks.
Manage your stacks separately or together
To begin with, let's understand how each method organizes its stacks.
With cross-stack references, you manage your stacks separately. You export an output from one stack and import it into another stack, or in other words, your second stack references the output from the first stack. Therefore, the exported output must be ready before the import stack is created. Therefore, you must first create the export stack and then the import stack.
But with nested stacks, you manage your stacks together through a master stack. Your roots stack template contains resource definitions for your nested stacks with the S3 URLs for your templates. In addition, in a root stack template, you can pass the output of one nested stack to another using the inherent methodFn::GetAttthey act as return value attributes for other types of AWS resources. This also creates implicit dependencies between your nested stacks and the order of your builds. Therefore, nested stacks are created and updated as a normal resource. You only use your roots stack for these actions.
So if you want to manage your stacks from a single point, you should use nested stacks. For example, you can define a roots stack that uses different templates to create an application load balancer, an autoscale pool, and so on. These resources often require sub-resources such as audiences and autoscale group policies. Therefore, it would be more sensible to place them in separate templates, but build or update them together through their rootstack.
Alternatively, you can use cross-stack credentials if you want to manage your stacks as separate entities. For example, say one of your stacks is a network stack that creates a VPC, and you have multiple stacks for different applications running on the same VPC. In that case, you can create your network stack separately and share its output with the values needed by your application stacks.
Share your resources or templates
As I mentioned earlier, you share the output between your stacks in cross-stack references. While these exported results may have some value, in practice they are often identifiers of the resources created by the export stack. For example, you can export subnet IDs for the public subnets created by your networking stack and import them into your application stacks. Your application stacks can then use these subnet IDs to create the necessary AWS resources in the public subnets. So usually you share the resources created by the export stack with others. But these stocks are controlled by the exporter stack. Only those in the import stacks are referenced.
However, a roots stack that creates nested stacks is similar to a regular stack, but creates multiple CloudFormation stacks. You can use the same nested stack template to define a similar nested stack on different master stacks. So you can share templates between multiple roots stacks. You can even use the same template to define multiple nested stacks of the same type in the same master stack. The only requirement is that you put the template in an S3 bucket in the AWS region you are using.
If you use local paths for your nested stacks, you can also copy the nested stack template between your books and define a new nested stack below the new master stack. So with nested stacks, your focus should be on the templates in terms of sharing. Whereas with cross-stack references your goal would be to share resource IDs if necessary.
Update your stack resources
In cross-stack references, you cannot update the exported output value if another stack is already importing it. This is because the stacks are managed separately and the updated value may have an unexpected impact on the import stack. For example, the update may require replacing a resource. Therefore, AWS CloudFormation does not allow this.
However, if you share a resource by exporting its ID as I described above, you can update its properties and make it available to all resources that import its output just by updating the export stack. Let me give an example to explain this better. Let's say you have multiple database stacks that use the same security group rules, and you need to allow access to the same port for all databases created by those stacks. If you create the database security group in a network stack and share the security group ID as an exported result with the database stacks, you can add the rule to the network stack template and update the stack network without touching the database stacks. Your new rule will be applied to all your databases once the network stack update is complete. But you cannot change the exported security group ID in any way unless you remove its credentials from the database stacks.
But in nested stacks, all resources are managed together through the master stack. There are no update limits on the output of nested stacks, even if they are passed as parameter values to other nested stacks. Because you update your nested stacks by updating their main stack, a stack update is also initiated for the affected nested stacks. Subsequently, if a resource replacement is required in an affected nested stack, you can do so during your own stack update.
Thus, updating the output of a stack or any source is easy in nested stacks. You just make the changes to your templates and update your roots stack. He takes care of the rest.
Easily duplicate your AWS infrastructure
One of the strengths of using AWS CloudFormation is the reuse of your templates to easily duplicate your infrastructure. For cross-stack references, create all stacks one by one to recreate the same architecture for different uses in the same or different AWS region.
But if you organize your stacks as nested stacks, you can simply deploy another root stack with the same templates in any area you want, and it will also create the nested stacks for you. Also if you use and use local paths for your nested stack templatescloud formation packagecommand from the AWS CLI, it can take care of uploading the built-in stack templates to an S3 bucket for you. All you need to do is choose a region and provision an S3 bucket in that region. Using bash scripts in your implementations makes this even easier.
So if you plan to easily create duplicates of your infrastructure and manage it as one project, using nested stacks can help.
Conclusion
Cross-stack references and nested stacks have their use cases. They may seem complicated at first, but you need to know how to use them to effectively organize your AWS CloudFormation stacks.
As an experienced developer, I like to break large projects into several small parts and often use nested stacks to group and encapsulate my related AWS resources. It also simplifies code sharing between different infrastructure projects. Also, I often create a single VPC stack and share its resources by exporting its output, since AWS limits the number of VPCs you can create in an AWS region to five.
Thank you for reading!
Would you like to learn AWS CloudFormation?
If you're new to AWS CloudFormation or learning more advanced features like cross-stack references and nested stacks, which are covered in this post, my beginner and advanced AWS CloudFormation courses on Udemy can help.
Level 1:
AWS CloudFormation step by step: from beginner to intermediateIf you are new to CloudFormation, this course is for you. It teaches you how to create, update, and delete CloudFormation stacks, write your own templates using YAML, and use template sections effectively. You will also learn how to use change sets to securely update your stacks and cloud training commands from the AWS CLI.
Interested? To see the course topics and register with a special discount, you can use this link:Sign up for AWS CloudFormation step by step - from beginner to advanced on Udemy!
Level 2:
AWS CloudFormation Step by Step: Intermediate to AdvancedThis course continues from
AWS CloudFormation step by step: from beginner to intermediateand teach more advanced topics like stack references and nested stacks, helper scripts, stack policies, custom resources, stack operations, and how to implement serverless resources with the AWS serverless application model, etc. Includedcross-stack referencesjgeneste stapelsexpanded with practical examples. As you may have guessed, this course requires completion of the beginner's course or knowledge of all subjects.You can view the course page and register with a special discount via this link:Step by Step Sign Up for AWS CloudFormation - Intermediate to Advanced on Udemy!
I've put together these courses to help you learn AWS CloudFormation in detail step by step. Therefore, I recommend that you complete the beginner level course first and then move on to the advanced course for a better experience.
See you in my AWS CloudFormation courses!
References
