Introduction

I personally lean towards Terraform as my preferred Infrastructure as Code (IaC) tool for constructing AWS environments. Compared to Terraform, CloudFormation has its unique challenges that can complicate the process, including issues related to state management, developer experience, and provisioning or rollback complexities. It seems that AWS is also cognizant of these challenges, and has been making efforts to bridge the gap between CloudFormation, CDK, and Terraform – working towards a more user-friendly experience.

However, I understand that CloudFormation may sometimes be a necessity. the real world doesn’t always conform to our technical preferences. Often, we have to factor in project requirements or specifications that necessitate the use of certain tools or platforms. For instance, some projects might restrict us to using only AWS resources, consequently nudging us towards CloudFormation. In other cases, we may continue with CloudFormation due to factors like the potential migration costs or complexities involved in switching to other IaC tools.

In such scenarios, we must make some crucial decisions about how we manage CloudFormation templates and deploy our stacks. This post will focus on the latter: exploring the different strategies to deploy stacks in CloudFormation and helping you make an informed decision. We’ll compare two primary methods – Nested Stacks and Cross Stacks – and weigh their merits and challenges. If you prefer to bypass the detailed analysis, feel free to jump directly to the conclusion where we summarize the key takeaways.

Key Considerations in Stack Selection

In choosing between Nested Stacks and Cross Stacks, the crux of the differences primarily boils down to the hierarchical structure of the stacks. This structural difference brings with it a myriad of other factors that can influence the flexibility, manageability, and the overall experience of deploying and maintaining AWS environments. So, let’s delve into each aspect.

Stack Flexibility and Complexity

The first factor to consider when comparing Nested Stacks and Cross Stacks is the flexibility they offer in terms of architecture and the level of complexity they introduce.

Nested Stacks allow you to create a modular structure by encapsulating parts of your infrastructure into separate stacks. This is akin to breaking down a large software project into smaller, manageable components or services. However, with this modularity comes an inherent degree of interdependence among the stacks, introducing a layer of complexity, particularly when managing updates and deletions. For instance, you may encounter situations where even a small change to one nested stack may cause CloudFormation to indicate that all stacks will be updated in the change-set preview.

Even though stacks you didn’t actually change may remain untouched, the preview may give an impression of broader changes, implying potential risks to flexibility and stability arising from the ambiguous independence between stacks.

On the other hand, Cross Stacks are intrinsically more flexible, offering a more linear, less dependent architecture. You can deploy, update, or delete stacks independently, potentially providing a better developer experience. This approach may, however, require a strict naming convention or additional resources to maintain a structured and understandable hierarchy.

While both methods offer a certain level of flexibility, due to the inherent dependency issues with Nested Stacks, it can be argued that Cross Stacks, comprising multiple independent stacks, inherently offer greater flexibility. Given the value of modularity in managing infrastructure, Cross Stacks seem to have an edge in most scenarios.

Stack Management

A crucial aspect to consider when choosing between Nested Stacks and Cross Stacks is how they impact the management of your infrastructure. This essentially revolves around how effectively and efficiently you can control your resources, their configurations, and handle updates or rollbacks.

Nested Stacks, with their hierarchical structure, provide an organized and grouped view of resources. It allows for easier understanding of the resource relationships and dependencies, but this can be a double-edged sword. On one hand, it can simplify management by providing a coherent view of the overall system. On the other hand, it can make changes more complex and difficult to handle, especially in large-scale infrastructure due to interdependencies among the stacks.

Cross Stacks, on the contrary, while they do not inherently provide a structured view of the hierarchy, offer more transparency and control over individual stacks. Each stack is standalone, can be managed independently, and is less prone to cascading changes. However, to achieve a comprehensive view of resource hierarchy, you may have to rely on strict naming conventions or additional resources like documentation.

Overall, Cross Stacks seem to provide more granular control over individual resources, reducing the likelihood of cascading changes and making troubleshooting easier. However, Nested Stacks may offer a more coherent and organized view of your infrastructure, particularly useful in cases where you need to frequently view and understand the interrelationships among your resources.

Deployment and Change Control

The choice between Nested and Cross Stacks also has a direct impact on how you deploy and control changes to your infrastructure. This becomes particularly important when considering how updates, rollbacks, and error handling are managed.

Nested Stacks follow a hierarchical model, where updating the root stack initiates updates in all nested stacks. While this enables a simultaneous deployment of changes, it can also introduce potential risks. For instance, if the deployment fails in a nested stack, all other stacks, including those deployed without any issues, will be rolled back. This could extend the total deployment time and complicate the troubleshooting process for the problematic stacks.

Cross Stacks, in contrast, can be updated independently. This isolates changes, ensuring that an issue in one stack doesn’t affect others. Moreover, it makes the process of deploying updates and rolling back changes more transparent and manageable, offering better control.

Yet, this comes with a trade-off. Deploying updates to multiple stacks can be more time-consuming and might require additional tools or scripts to coordinate changes across stacks.

In conclusion, Cross Stacks may provide a more granular level of change control, while Nested Stacks facilitate deploying changes at once, at the potential cost of stability during updates. The choice would depend on your tolerance for risk, complexity, and the frequency of changes in your AWS environment.

Scaling and Large-Scale Infrastructure Management

When managing large-scale infrastructure, your choice between Nested Stacks and Cross Stacks can significantly impact your workflow. Nested Stacks, due to their inherently complex and interdependent structure, can become increasingly hard to manage as the scale of the infrastructure grows. The hierarchical nature of Nested Stacks means that a single issue in one stack can affect multiple stacks, making it more challenging to troubleshoot and resolve issues.

On the other hand, Cross Stacks shine in large-scale infrastructure management. Thanks to their independent structure, Cross Stacks offer a high level of control over each stack, making it easier to manage dependencies and troubleshoot issues. This separation of stacks also means that updates or issues are isolated to individual stacks, preventing a problem in one stack from affecting others.

However, it’s worth noting that the management of large-scale infrastructures with Cross Stacks could require third-party tools or extensive naming conventions to maintain clarity in stack relations and dependencies. Despite this, the modularity and control provided by Cross Stacks generally make them better suited to handle large-scale infrastructure.

Conclusion with Summary

As we reach the conclusion of our comparison, let’s summarize the major differences between Nested Stacks and Cross Stacks in AWS CloudFormation:

Feature	Nested Stack	Cross Stack
Modularity	Moderate (with dependencies)	Excellent (less dependencies)
Change Isolation	Fair	Excellent
Hierarchical Management	Excellent	Good (needs conventions)
Ease of Rollbacks	Fair (dependent on others)	Excellent (individual stacks)
Troubleshooting	Difficult (due to complexity)	Straightforward
Dependency Management	Complex (can be complex)	Simplified (more control)
Resource Grouping	Excellent	Good (needs conventions)
Large-Scale Infrastructure Management	Moderate (complexity can be an issue)	Excellent (better management of dependencies)
Atomic Deployment	Excellent	Good (possible with 3rd party tools)

Nested Stacks hold the upper hand in a few areas – they offer a clear visualization of the hierarchical relationship between stacks, enable easy resource grouping, and provide atomic deployment capabilities without the need for specialized tools.

However, in all other aspects, Cross Stacks come out ahead, delivering a more satisfying experience. It’s worth noting that the advantages of Nested Stacks can be counteracted in Cross Stacks with the use of clear naming conventions and certain tools like Sceptre. My practical experiences have led me to prefer Cross Stacks over Nested Stacks, especially as projects scale up and become more complex. The dependency issues inherent in Nested Stacks often lead to difficulties that Cross Stacks can mitigate more effectively.

Ultimately, the choice between Nested and Cross Stacks in CloudFormation depends on your specific needs and the scale of your project. I hope that this article provides some clarity and guidance to anyone grappling with similar decisions in CloudFormation.