Create and Manage AWS CloudFormation Nested Stacks with the CLI – SAP-C02 Study Guide

Purpose of This Lesson

AWS CloudFormation nested stacks let you divide a large infrastructure template into smaller, reusable templates while deploying the result as one logical top-level stack. This lesson demonstrates how to store child templates in Amazon S3 and deploy a parent template using the AWS CLI.

Nested stacks are useful when a solution contains distinct infrastructure layers—for example, a VPC stack and separate subnet stacks—but should still be managed as one overall deployment.

Key Concepts

Parent and child stacks

A parent template declares child stacks using the AWS::CloudFormation::Stack resource type. Each child stack is represented as a resource in the parent template and points to another CloudFormation template through TemplateURL.

A typical structure looks like this:

Parent stack
├── VPC child stack
├── Subnet 1 child stack
└── Subnet 2 child stack

The parent template might contain resources conceptually similar to the following:

Resources:
  VPCStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/example-bucket/vpc.yaml

  Subnet1Stack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/example-bucket/subnet1.yaml
      Parameters:
        VpcId: !GetAtt VPCStack.Outputs.VpcId

The exact URL format can vary, but the child template must be accessible to CloudFormation.

Template organization

A practical decomposition separates infrastructure by responsibility:

• vpc.yaml creates the VPC and exports or outputs its identifier.
• subnet1.yaml creates a subnet using the VPC ID supplied by the parent.
• subnet2.yaml creates another subnet, usually with a different CIDR block.
• main.yaml orchestrates the child stacks and passes values between them.

The child templates can expose values through Outputs. The parent stack can consume those values using nested stack attribute syntax such as:

!GetAtt VPCStack.Outputs.VpcId

This allows resources in one child stack to depend on resources created by another child stack.

S3 and TemplateURL

Nested stack templates are commonly uploaded to Amazon S3 before deployment. The parent template then references the S3 locations.

Example CLI workflow:

aws s3 mb s3://unique-template-bucket-name
aws s3 cp vpc.yaml s3://unique-template-bucket-name/
aws s3 cp subnet1.yaml s3://unique-template-bucket-name/
aws s3 cp subnet2.yaml s3://unique-template-bucket-name/

S3 bucket names are globally unique, so a name that exists in another AWS account or Region cannot be reused. The bucket and object locations must also be usable by CloudFormation in the deployment context.

Deploying the parent stack

The parent stack can be created with the AWS CLI:

aws cloudformation create-stack \
  --stack-name NestedStackExample \
  --template-body file://main.yaml \
  --capabilities CAPABILITY_NAMED_IAM

--template-body file://main.yaml tells the CLI to submit a local parent template. The parent template then causes CloudFormation to retrieve and create the child templates referenced by TemplateURL.

CAPABILITY_NAMED_IAM is needed only when the submitted template creates or modifies IAM resources with custom names. It is not inherently required just because a template uses nested stacks.

Stack lifecycle and visibility

CloudFormation displays the parent and child stacks separately. The child stacks are identified as nested stacks and have names derived from the parent stack and logical resource identifiers.

A successful deployment normally results in:

• The parent stack reaching CREATE_COMPLETE.
• Each child stack reaching CREATE_COMPLETE.
• Outputs being available from the relevant child stacks.
• Dependencies being resolved according to references and resource relationships.

Updates and deletions are coordinated through the parent stack. The parent is the primary orchestration boundary, even though each nested stack has its own resources and events.

Deleting the deployment

The parent stack can be deleted with the CLI:

aws cloudformation delete-stack \
  --stack-name NestedStackExample

Deleting the parent initiates deletion of its nested stacks and the resources they manage, subject to normal CloudFormation deletion behavior and resource retention policies.

Architecture Decision Guide

Requirement	Recommended approach	Reason
Break one large deployment into logical components	Nested stacks	Centralizes deployment while improving template organization
Deploy a reusable infrastructure component independently across many applications	Separate top-level stacks or StackSets	Provides stronger independent lifecycle and reuse boundaries
Pass a VPC ID from one component to another in the same deployment	Child stack Outputs and parent parameter wiring	Creates explicit dependency and value flow
Store child templates for CloudFormation to retrieve	Amazon S3 with TemplateURL	Separates template artifacts from the local CLI submission
Deploy a parent template stored locally	--template-body file://...	The AWS CLI submits the local parent template
Deploy a parent template already in S3	--template-url	Avoids submitting the parent body directly from the local filesystem
Create IAM resources with custom names	Request CAPABILITY_NAMED_IAM	Explicitly acknowledges named IAM resource creation
Clean up an entire nested deployment	Delete the parent stack	The parent coordinates deletion of nested stacks

Exam-Relevant Takeaways

• AWS::CloudFormation::Stack is the resource type used to define a nested stack.
• TemplateURL identifies the child template used by a nested stack.
• Child templates are commonly stored in Amazon S3.
• Nested stacks are useful for modularity and managing template complexity; they are not the same as cross-stack exports or StackSets.
• A child stack can publish values through Outputs.
• The parent can retrieve a nested stack output with Fn::GetAtt, for example !GetAtt ChildStack.Outputs.OutputName.
• Resources in dependent child stacks should be connected through parameters, outputs, and references rather than hardcoded identifiers.
• The parent stack and nested stacks appear as separate CloudFormation stack entities and events.
• Deleting the parent normally initiates deletion of the nested stacks and their resources.
• CAPABILITY_NAMED_IAM relates to named IAM resources, not to nested-stack functionality itself.
• CloudFormation must be able to access the child template objects referenced by TemplateURL.

Common Exam Traps

Confusing nested stacks with cross-stack references

Nested stacks are components managed within a parent stack. Cross-stack references connect independent top-level stacks, commonly through exports and Fn::ImportValue. Choose nested stacks when the components belong to one coordinated deployment hierarchy.

Assuming every nested stack must be independently deployed

The parent stack is the orchestration point. Although nested stacks have their own identities and events, their lifecycle is normally controlled through the parent template.

Forgetting template accessibility

A local parent template does not make its child templates local to CloudFormation. The child templates referenced by TemplateURL must be stored at accessible locations, typically Amazon S3.

Treating S3 bucket names as account-local

S3 bucket names are globally unique. A deployment procedure that hardcodes a commonly used bucket name can fail even when the name is unused in the current account.

Adding CAPABILITY_NAMED_IAM automatically

The capability flag is required when the template creates or modifies custom-named IAM resources. Nested stacks alone do not require it.

Hardcoding dependencies between components

A subnet template should receive the VPC ID through a parameter wired to the VPC child stack’s output. Hardcoded VPC IDs reduce portability and can cause deployments to target the wrong environment.

Ignoring deletion behavior

Deleting the parent can delete the nested resources. Check retention policies and protect important data resources before using cleanup commands in production.

Real-World Engineer Notes

• Use versioned or immutable S3 object locations for production template artifacts so a stack update does not unexpectedly consume a changed child template.
• Enable appropriate S3 security controls, such as Block Public Access and encryption. Do not make CloudFormation templates public merely to simplify access.
• Keep parent templates focused on orchestration, parameters, dependencies, and outputs. Put component-specific resources in child templates.
• Use consistent naming and logical IDs because nested stack names are derived from the parent context and can become difficult to interpret in large environments.
• Test parent and child templates with CloudFormation validation and deployment checks before rolling out changes.
• Consider separate top-level stacks when teams need independent ownership, deployment schedules, or deletion boundaries.
• For multi-account or multi-Region rollout of a common template, evaluate AWS CloudFormation StackSets rather than using nested stacks as a distribution mechanism.
• Monitor both parent and child stack events when troubleshooting. A failure in a child stack can cause the parent operation to fail or roll back.

Quick Reference Summary

Child template location: Amazon S3
Nested stack resource: AWS::CloudFormation::Stack
Child template property: TemplateURL
Child-to-parent data: Outputs
Parent-to-child data: Parameters
Nested output access: !GetAtt ChildLogicalId.Outputs.OutputName
Create parent: aws cloudformation create-stack
Delete parent: aws cloudformation delete-stack

Nested stacks provide hierarchical organization and coordinated lifecycle management. They are most appropriate when multiple infrastructure components form one logical application or environment deployment.

Flashcards

1. Q: What CloudFormation resource type creates a nested stack?

A: AWS::CloudFormation::Stack.

1. Q: Which property identifies the child template?

A: TemplateURL.

1. Q: Where are nested child templates commonly stored?

A: Amazon S3.

1. Q: How does a child stack expose a VPC ID?

A: Through an Outputs declaration.

1. Q: How can a parent access a nested stack output?

A: With Fn::GetAtt, such as !GetAtt VPCStack.Outputs.VpcId.

1. Q: How should a subnet child stack receive the VPC identifier?

A: As a parameter passed by the parent stack from the VPC child stack’s output.

1. Q: Does nested-stack usage alone require CAPABILITY_NAMED_IAM?

A: No. The capability is associated with creating or modifying named IAM resources.

1. Q: What happens when the parent stack is deleted?

A: CloudFormation normally initiates deletion of the nested stacks and their managed resources.

1. Q: What is the main benefit of nested stacks?

A: Modularizing a complex deployment while retaining centralized orchestration.

1. Q: How do nested stacks differ from StackSets?

A: Nested stacks organize components inside one stack hierarchy; StackSets deploy stacks across multiple accounts and/or Regions.

Practice Questions

Question 1

A company has a parent CloudFormation template that creates a VPC child stack and two subnet child stacks. The subnet templates need the VPC ID created by the VPC template. What is the best design?

A. Hardcode the VPC ID in each subnet template
B. Export the VPC ID from the VPC child stack and import it with Fn::ImportValue
C. Add the VPC ID to the VPC child stack’s Outputs and pass it as a parameter from the parent
D. Store the VPC ID in an S3 object and have the subnet templates retrieve it

Correct answer: C

The parent can read the nested stack output and pass that value to the subnet child stacks through parameters. This keeps the components portable and explicitly models the dependency. Cross-stack exports are more commonly used between independent top-level stacks.

Question 2

An administrator submits main.yaml locally with aws cloudformation create-stack. The parent stack fails because CloudFormation cannot retrieve subnet.yaml. The child template is present in the administrator’s local directory. What is the most likely issue?

A. Nested stacks cannot use YAML templates
B. The child template must be available at the location specified by TemplateURL
C. The AWS CLI requires CAPABILITY_AUTO_EXPAND for every nested stack
D. The parent must be uploaded to S3 before any child can be used

Correct answer: B

CloudFormation retrieves a child template from the TemplateURL location. Having the file locally is insufficient unless the parent references an appropriate accessible location, such as an S3 object.

Question 3

A deployment command includes --capabilities CAPABILITY_NAMED_IAM, but the templates create only a VPC and subnets. Which statement is most accurate?

A. The flag is mandatory for all nested stacks
B. The flag is required for all EC2 resources
C. The flag is relevant when the templates create or modify named IAM resources
D. The flag allows CloudFormation to access private S3 buckets

Correct answer: C

CAPABILITY_NAMED_IAM acknowledges that a template may create or modify IAM resources with custom names. It is unrelated to VPC creation, nested-stack access, or S3 permissions.

Question 4

A platform team wants a VPC component to be deployed once and independently updated by several application teams, each with separate ownership and deletion controls. Should the VPC be implemented as a nested stack in every application parent stack?

A. Yes, because nested stacks are always the preferred reuse mechanism
B. Yes, because nested stacks automatically share resources between parent stacks
C. No, an independently managed top-level stack or another reusable distribution pattern is more appropriate
D. No, because CloudFormation cannot create VPCs in nested stacks

Correct answer: C

Nested stacks are best when components belong to one coordinated parent deployment. Independent ownership and lifecycle boundaries generally favor separate top-level stacks, possibly combined with exports, pipelines, or StackSets depending on the distribution requirements.

Question 5

An engineer deletes the parent stack to clean up a test environment. Some resources remain. Which explanation should be investigated first?

A. Nested stacks are never deleted with their parent
B. The deletion may be affected by resource retention policies or resources that failed deletion
C. CloudFormation automatically converts nested stacks into StackSets
D. The parent stack deletion command affects only the parent metadata

Correct answer: B

Nested stacks are normally included in the parent lifecycle, but DeletionPolicy, UpdateReplacePolicy, service-specific constraints, or deletion failures can leave resources behind. Review stack events and resource policies when cleanup is incomplete.