Nested stacks for modularity in AWS - Step-by-Step Execution

Process Flow - Nested stacks for modularity

Start Main Stack

↓

Define Nested Stack Resources

↓

Create Nested Stack Template

↓

Deploy Nested Stack

↓

Nested Stack Creates Resources

↓

Main Stack References Nested Stack Outputs

↓

Complete Deployment

The main stack defines and deploys nested stacks as separate templates, each creating modular resources. Outputs from nested stacks can be referenced by the main stack for integration.

Execution Sample

AWS

MainStack:
  Resources:
    NestedStack1:
      Type: AWS::CloudFormation::Stack
      Properties:
        TemplateURL: nested1.yaml

NestedStack1:
  Resources:
    MyBucket:
      Type: AWS::S3::Bucket

Main stack deploys a nested stack which creates an S3 bucket as a modular resource.

Process Table

Step	Action	Stack	Resource Created	Output Produced	Notes
1	Start deployment	MainStack	None	None	Main stack deployment begins
2	Create NestedStack1 resource	MainStack	NestedStack1 (AWS::CloudFormation::Stack)	None	Nested stack resource defined in main stack
3	Deploy NestedStack1	NestedStack1	S3 Bucket (MyBucket)	BucketName	Nested stack creates S3 bucket resource
4	NestedStack1 outputs BucketName	NestedStack1	None	BucketName: mybucket-123	Output exported for main stack
5	MainStack references NestedStack1 output	MainStack	None	BucketName from NestedStack1	Main stack can use nested stack outputs
6	Complete deployment	MainStack	NestedStack1 and MyBucket	Outputs available	Deployment finished successfully

💡 All nested stacks deployed and outputs referenced; deployment complete

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
MainStack.Resources	{}	{"NestedStack1": "Defined"}	{"NestedStack1": "Deploying"}	{"NestedStack1": "Deployed"}	{"NestedStack1": "Deployed"}
NestedStack1.Resources	N/A	N/A	{"MyBucket": "Created"}	{"MyBucket": "Created"}	{"MyBucket": "Created"}
Outputs.BucketName	N/A	N/A	N/A	"mybucket-123"	"mybucket-123"

Key Moments - 3 Insights

Why does the main stack not create the S3 bucket directly?

Because the S3 bucket is created inside the nested stack (see Step 3 in execution_table), allowing modular separation of resources.

How does the main stack get information about resources created in nested stacks?

Nested stacks export outputs (Step 4) which the main stack references (Step 5) to integrate resources.

What happens if a nested stack deployment fails?

The main stack deployment will fail or roll back because nested stacks are part of the main stack's resource graph.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the S3 bucket created?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Resource Created' column in execution_table rows

According to variable_tracker, what is the state of NestedStack1.Resources after Step 3?

A Undefined

B {}

C {"MyBucket": "Created"}

D {"NestedStack1": "Defined"}

💡 Hint

Look at NestedStack1.Resources row and After Step 3 column

If NestedStack1 did not output BucketName, what impact would it have on the main stack?

A Main stack could not reference the bucket name output

B Nested stack would fail to deploy

C Main stack would create the bucket instead

D No impact, outputs are optional

💡 Hint

Refer to Step 4 and Step 5 in execution_table about outputs and references

Concept Snapshot

Nested stacks let you split big infrastructure into smaller templates.
Main stack deploys nested stacks as resources.
Nested stacks create modular resources independently.
Outputs from nested stacks can be used by main stack.
This improves reusability and organization.
Deployment is atomic: nested stacks are part of main stack.

Full Transcript

Nested stacks help organize cloud infrastructure by splitting it into smaller templates. The main stack defines nested stacks as resources and deploys them. Each nested stack creates its own resources, like an S3 bucket. Nested stacks can output values, such as the bucket name, which the main stack can reference. This modular approach improves clarity and reuse. Deployment proceeds step-by-step: main stack starts, nested stacks deploy their resources, outputs are produced, and main stack uses those outputs. If any nested stack fails, the whole deployment fails. This ensures consistency and modularity in cloud infrastructure management.

Practice

1. What is the main benefit of using nested stacks in AWS CloudFormation?

easy

A. They replace the need for IAM roles.

B. They automatically increase server CPU capacity.

C. They break large templates into smaller, reusable parts.

D. They encrypt all data stored in S3 buckets.

Solution

1. Step 1: Understand the purpose of nested stacks

   Nested stacks allow splitting a big CloudFormation template into smaller templates for easier management.

2. Step 2: Compare options with this purpose

   Only They break large templates into smaller, reusable parts. describes breaking large templates into reusable parts, which matches nested stacks' main benefit.

3. Final Answer:

   They break large templates into smaller, reusable parts. -> Option C

4. Quick Check:

   Nested stacks = modular templates [OK]

Hint: Think modular: nested stacks split big templates [OK]

Common Mistakes:

• Confusing nested stacks with scaling features
• Assuming nested stacks handle encryption automatically
• Mixing nested stacks with IAM role functions

2. Which syntax correctly defines a nested stack resource in a CloudFormation template?

easy

A. "Type": "AWS::Lambda::Function",
"Properties": {"Handler": "index.handler"}

B. "Type": "AWS::S3::Bucket",
"Properties": {"BucketName": "nested-stack"}

C. "Type": "AWS::EC2::Instance",
"Properties": {"ImageId": "ami-123456"}

D. "Type": "AWS::CloudFormation::Stack",
"Properties": {"TemplateURL": "https://s3.amazonaws.com/mybucket/mystack.yaml"}

Solution

1. Step 1: Identify nested stack resource type

   The resource type for nested stacks is AWS::CloudFormation::Stack.

2. Step 2: Check the properties for nested stack

   Nested stacks require a TemplateURL property pointing to the child template location.

3. Final Answer:

   "Type": "AWS::CloudFormation::Stack", "Properties": {"TemplateURL": "https://s3.amazonaws.com/mybucket/mystack.yaml"} -> Option D

4. Quick Check:

   Nested stack resource = AWS::CloudFormation::Stack [OK]

Hint: Nested stack resource type is AWS::CloudFormation::Stack [OK]

Common Mistakes:

• Using S3 bucket or EC2 instance types for nested stacks
• Omitting TemplateURL property
• Confusing Lambda function syntax with nested stacks

3. Given a parent stack that passes a parameter VpcId to a nested stack, what will happen if the nested stack template does NOT declare VpcId as a parameter?

medium

A. The nested stack deployment will fail with a parameter validation error.

B. The nested stack will ignore the parameter and deploy successfully.

C. The parent stack will automatically create the missing parameter.

D. The nested stack will use a default VPC ID automatically.

Solution

1. Step 1: Understand parameter passing in nested stacks

   Parameters passed from parent to nested stack must be declared in the nested stack template.

2. Step 2: Consequence of missing parameter declaration

   If the nested stack does not declare the parameter, CloudFormation cannot map the value, causing deployment failure.

3. Final Answer:

   The nested stack deployment will fail with a parameter validation error. -> Option A

4. Quick Check:

   Missing nested stack parameter = deployment error [OK]

Hint: Nested stack must declare all passed parameters [OK]

Common Mistakes:

• Assuming parameters are optional in nested stacks
• Thinking parent stack auto-creates missing parameters
• Believing nested stacks use default values without declaration

4. You have a nested stack that fails to update because the child stack template URL is incorrect. What is the best way to fix this error?

medium

A. Delete the parent stack and recreate it from scratch.

B. Update the parent stack template to use the correct TemplateURL for the nested stack.

C. Change the nested stack resource type to AWS::S3::Bucket.

D. Remove the nested stack resource from the parent template.

Solution

1. Step 1: Identify cause of failure

   The error is due to an incorrect TemplateURL in the parent stack referencing the nested stack template.

2. Step 2: Correct the TemplateURL

   Fixing the TemplateURL in the parent stack template ensures CloudFormation can find and deploy the nested stack correctly.

3. Final Answer:

   Update the parent stack template to use the correct TemplateURL for the nested stack. -> Option B

4. Quick Check:

   Fix TemplateURL in parent stack to fix nested stack update [OK]

Hint: Fix TemplateURL in parent template to fix nested stack errors [OK]

Common Mistakes:

• Deleting entire parent stack unnecessarily
• Changing resource type incorrectly
• Removing nested stack resource instead of fixing URL

5. You want to create a modular infrastructure with nested stacks where a VPC stack outputs a VpcId and a subnet stack needs this VpcId as input. How should you connect these stacks to ensure modularity and correct parameter passing?

hard

A. Use Outputs in the VPC stack and pass them as Parameters to the subnet nested stack in the parent template.

B. Hardcode the VPC ID in the subnet stack template directly.

C. Deploy the subnet stack separately without any parameters.

D. Merge both VPC and subnet resources into a single large template.

Solution

1. Step 1: Use Outputs to share data from VPC stack

   The VPC nested stack should declare an Output for VpcId to share it externally.

2. Step 2: Pass Output as Parameter to subnet stack

   The parent stack template passes the VPC stack's VpcId Output as a Parameter to the subnet nested stack, maintaining modularity.

3. Final Answer:

   Use Outputs in the VPC stack and pass them as Parameters to the subnet nested stack in the parent template. -> Option A

4. Quick Check:

   Outputs to Parameters connect nested stacks modularly [OK]

Hint: Connect stacks via Outputs and Parameters in parent template [OK]

Common Mistakes:

• Hardcoding values breaking modularity
• Deploying stacks separately without parameter passing
• Combining all resources in one big template losing modularity