Optimizing AWS CDK Structure with Stacks and NestedStacks
Written on
Chapter 1: Introduction to AWS CDK Stacks
When you begin your journey with AWS CDK, you may find yourself building everything within a single stack. While this approach is perfectly acceptable, it does come with certain limitations. For instance, a single stack can only accommodate up to 500 resources. Therefore, if you aim to construct a large AWS CDK infrastructure, you will eventually encounter these constraints.
It's essential to consider best practices from the start to optimize your project. I prefer to standardize the organization of all my AWS CDK projects, which allows me to create a single documentation guide applicable to all projects rather than developing unique documentation for each one.
Section 1.1: Understanding Stacks and NestedStacks
My approach to utilizing AWS CDK Stacks and NestedStacks begins with creating an app.py file. This file serves as the trigger for all primary root stacks. In more extensive infrastructures, you may require multiple stacks or projects. While typically a single root stack suffices, it's vital to ponder this before embarking on your Infrastructure as Code (IaC) journey with AWS CDK.
I designate a folder to house all my stack files. Since I utilize a single root stack, I organize everything within a folder named awsStack, categorizing all AWS CDK files by their respective groups or areas.
Subsection 1.1.1: Sample NestedStack Implementation
For example, I have a file dedicated to IAM Policies, where I integrate the IAM Policy Group as a NestedStack. This structure allows me to manage all IAM Policies efficiently, making it easier to read by dividing the code into smaller NestedStack files.
When a NestedStack returns its data, such as self.iamPolicyGroup, it enables you to access essential information like ARN IDs from your root stack.
The decision to use either a single Root Stack or a Root Stack with multiple NestedStacks depends on your specific needs. However, I've discovered various benefits and trade-offs associated with employing multiple NestedStacks.
Section 1.2: Advantages of Using Multiple NestedStacks
One significant advantage of adopting a root stack with multiple NestedStacks is the enhanced collaboration it affords teams of infrastructure developers. Each team member can concentrate on a particular area of the infrastructure without needing to manage the entire system.
This standardized approach simplifies the onboarding process for new developers, as they can quickly understand the established methods without having to reinvent the wheel for each new AWS CDK project.
When deploying your NestedStacks, they are executed separately while remaining part of the root stack. This structure ensures that if one component fails, it impacts the entire infrastructure chain, preserving integrity.
It's important to note the resource limitations: while a stack can contain 500 resources, this limit multiplies with each NestedStack. Thus, if you have one root stack and ten NestedStacks, you effectively have 5,500 resources at your disposal.
Chapter 2: Trade-offs of Using NestedStacks
The initial drawback I have encountered relates to debugging deployment errors in the AWS CloudFormation console. When an error occurs, navigating to the specific NestedStack can be cumbersome. You must enable the "view NestedStack" option and scroll through the details to identify the issue.
To delve into your awsRootStack CloudFormation deployment, you need to access the events section. Here, you will notice that the Logical ID refers solely to the NestedStack. If an error arises during deployment, you must enable "view nested" and search for that ID, as direct access from the Event tab to the NestedStack event view is not available. This limitation is the primary drawback I have observed while using NestedStacks.