Purpose of This Lesson

This hands-on lesson demonstrates how to create a nested AWS CloudFormation stack with the AWS CLI. The example separates a VPC and two subnets into individual child templates, stores those templates in Amazon S3, and uses a parent template to assemble them into one deployment.

The workflow is useful for understanding how CloudFormation decomposes infrastructure into reusable components while still managing the overall deployment from a top-level stack.

Key Concepts

Nested CloudFormation stacks

A nested stack is a CloudFormation stack created as a resource within another, top-level stack. The parent template uses resources with the type:

AWS::CloudFormation::Stack

Each nested stack resource references a child template through TemplateURL.

In this exercise, the infrastructure is divided into three child templates:

• vpc.yaml — creates the VPC and exports its VPC ID as an output.
• subnet-one.yaml — creates the first subnet and references the VPC ID.
• subnet-two.yaml — creates the second subnet and references the VPC ID.

The parent template, main.yaml, references the child templates and combines them into one logical deployment.

Parent and child stack relationship

The parent stack coordinates the child stacks. CloudFormation displays the parent and nested stacks separately, while identifying the child stacks as members of the nested deployment. In the example, the resulting stack hierarchy includes the main nested stack, a VPC child stack, and two subnet child stacks.

Template accessibility

The child templates must be available at URLs that CloudFormation can retrieve. This exercise uploads the templates to an Amazon S3 bucket and uses the resulting object URLs in main.yaml.

Outputs and dependencies

The VPC child stack produces a VPC ID output. The subnet templates use that value when creating their subnets. This allows the child templates to remain separated while preserving the required infrastructure relationship.

Hands-On Deployment Workflow

1. Create the child templates

Use AWS CloudShell or another shell environment to create the files. The lesson uses nano; if it is unavailable, it can be installed with:

sudo yum install nano

Create the three files:

nano vpc.yaml
nano subnet-one.yaml
nano subnet-two.yaml

The VPC template defines an AWS::EC2::VPC resource, including a CIDR block and DNS support and DNS hostnames settings. It also adds a name tag and returns the VPC ID as an output.

The subnet templates reference the VPC ID and use distinct CIDR blocks so that the two subnets are created within the same VPC without overlapping one another.

2. Create an S3 bucket

Create or select an S3 bucket for the child templates. The bucket name must be globally unique, so a bucket name used in another account may not be available in your account.

The AWS CLI command pattern is:

aws s3 mb s3://bucket-name

Replace bucket-name with a unique bucket name.

3. Upload the child templates

Copy each child template to the bucket with aws s3 cp:

aws s3 cp vpc.yaml s3://bucket-name
aws s3 cp subnet-one.yaml s3://bucket-name
aws s3 cp subnet-two.yaml s3://bucket-name

Verify in Amazon S3 that all three objects are present before building the parent template.

4. Retrieve the object URLs

Use the URL-retrieval command from the course exercise to obtain the URLs for the three uploaded objects. Copy the URLs individually into the corresponding nested stack resources in main.yaml.

The important implementation detail is that every TemplateURL in the parent template must point to the correct child template object. A wrong filename, bucket name, region-related URL, or object path can prevent CloudFormation from retrieving the child template.

5. Create the parent template

Create the parent template in the working directory:

nano main.yaml

The parent template contains three AWS::CloudFormation::Stack resources. Each resource references one of the S3-hosted child templates. The subnet stack resources also use the VPC stack’s output so that the subnets are associated with the VPC created by the VPC child stack.

6. Deploy the parent stack

Create the stack using the AWS CLI:

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

The file:// prefix tells the CLI that main.yaml is a local file. The command returns a stack ID when the request is accepted. Acceptance of the request does not necessarily mean that all resources have finished creating; deployment status must still be checked.

CAPABILITY_NAMED_IAM is included in the exercise’s deployment command because the template is being submitted with named IAM capability acknowledgement. Use the capability setting required by the template being deployed.

7. Verify the deployment

Monitor the stack in the CloudFormation console or query it with the CLI. The parent stack and its nested child stacks should progress through CloudFormation states such as CREATE_IN_PROGRESS and eventually reach CREATE_COMPLETE if successful.

Verify that:

• The parent stack exists.
• The VPC child stack completed successfully.
• Both subnet child stacks completed successfully.
• The VPC child stack produced its VPC ID output.
• Each subnet child stack produced its subnet ID output.
• The resulting VPC and subnets are visible in the Amazon VPC console.

8. Clean up the resources

When the exercise is complete, delete the parent stack rather than deleting child stacks independently:

aws cloudformation delete-stack \
  --stack-name nested-stack-example

Deleting the parent stack initiates cleanup of the nested resources managed as part of that deployment. Confirm that deletion completes before considering the environment removed.

Exam- or Assessment-Relevant Takeaways

• A nested stack is represented in a parent template by AWS::CloudFormation::Stack.
• A nested stack resource normally references its child template with a TemplateURL.
• Child templates hosted in Amazon S3 must be available at the URLs supplied to the parent template.
• A parent stack can coordinate multiple child stacks, such as separate VPC and subnet components.
• Outputs from one child stack can provide values needed by another child stack.
• aws cloudformation create-stack accepts a local parent template with --template-body file://main.yaml.
• A successful create-stack API response indicates that the request was accepted; inspect stack events or status to determine whether provisioning completed.
• The parent stack should be the primary management and cleanup boundary for the nested deployment.
• CAPABILITY_NAMED_IAM is a deployment acknowledgement supplied in the exercise’s CLI command; capabilities must match the template’s requirements.

Tool / Feature Decision Guide

Situation	Recommended choice	Reason
You need to assemble several CloudFormation components into one deployment	Use a parent stack with nested AWS::CloudFormation::Stack resources	The parent provides a single coordinating deployment while components remain separated
The parent template must reference child templates	Store the child templates in an accessible location such as Amazon S3 and use TemplateURL	CloudFormation needs a retrievable URL for each child template
You are testing the exercise interactively	Use AWS CloudShell with nano and the AWS CLI	The shell provides a convenient environment for creating files and running commands
A child resource depends on an identifier created by another child stack	Expose the identifier as an output and pass or reference it from the dependent stack	This preserves the dependency between separated templates
You need to remove the complete exercise environment	Delete the parent stack	The nested deployment is managed through the top-level stack
You need to troubleshoot whether the deployment actually finished	Check CloudFormation stack status and events, not only the CLI response	An accepted create request can still result in later resource failure

Common Traps / Misconceptions

• Confusing a nested stack with a standalone stack: The child stacks are still visible as stacks, but they are created and managed as resources of the parent deployment.
• Using local paths for child templates: The parent template’s child references need URLs, not merely local filenames. Upload the child templates and update every TemplateURL.
• Assuming the returned stack ID means success: create-stack returning a stack ID means the request was accepted. Creation can still fail afterward.
• Using a non-unique S3 bucket name: S3 bucket names are globally scoped, so a name that worked in another account may already be unavailable.
• Uploading only some child templates: All templates referenced by main.yaml must exist at the expected S3 locations.
• Using overlapping or incorrect subnet CIDR blocks: The subnet templates must reference the intended VPC and use valid, distinct CIDR ranges.
• Deleting child stacks first: Treat the parent as the deployment boundary and use the parent stack for cleanup.
• Forgetting the capability option: If the deployment command requires an IAM capability acknowledgement, omitting it can prevent stack creation.

Real-World Engineer / Analyst Notes

• Keep parent templates focused on orchestration and place logically separate resources in child templates.
• Use descriptive child stack names and outputs so that dependencies are easy to understand during troubleshooting.
• Confirm S3 object names and URLs carefully; template-location errors occur before the underlying VPC or subnet logic can be evaluated.
• Review CloudFormation events when a nested deployment fails. The parent status may summarize the failure, while the child stack event identifies the specific resource or template problem.
• Nested stacks can improve organization, but they also introduce another layer of dependencies and status reporting. The parent-child relationship should be documented.
• Delete test stacks and associated supporting artifacts when finished. Stack deletion does not necessarily mean every separately created artifact, such as the S3 bucket or uploaded templates, is automatically removed.

Quick Reference Summary

Child templates: vpc.yaml, subnet-one.yaml, subnet-two.yaml
Parent template: main.yaml
Child template location: Amazon S3
Nested resource type: AWS::CloudFormation::Stack
Deployment command: aws cloudformation create-stack
Local template option: --template-body file://main.yaml
Capability in exercise: --capabilities CAPABILITY_NAMED_IAM
Cleanup command: aws cloudformation delete-stack
Primary verification: CloudFormation status/events and VPC resources

Flashcards

Q: A parent CloudFormation template must create a VPC stack and two subnet stacks. Which resource type should represent each child stack?

A: Use AWS::CloudFormation::Stack resources in the parent template. Each resource references its child template through a TemplateURL.

Q: Why are the VPC and subnet definitions split into separate child templates in this exercise?

A: Splitting them separates infrastructure components while allowing the parent stack to coordinate one overall deployment. The VPC output can still be used by the subnet stacks.

Q: Where should the child templates be uploaded before deploying the parent template, and why?

A: Upload them to an accessible Amazon S3 bucket because the parent template references each child template by URL.

Q: What is the deployment command pattern for a local parent template named main.yaml?

A: Use aws cloudformation create-stack --stack-name <name> --template-body file://main.yaml, adding the required capabilities option when applicable.

Q: What does the file:// prefix mean in --template-body file://main.yaml?

A: It tells the AWS CLI that the CloudFormation parent template is a local file in the current working environment.

Q: A create-stack command returns a stack ID immediately. What should you do next?

A: Monitor CloudFormation status and events. The returned ID confirms that the request was accepted, not that every resource has completed successfully.

Q: How does a subnet child stack know which VPC to use?

A: The VPC child stack exposes the VPC ID as an output, and the parent deployment passes or references that value for the subnet stack.

Q: What is the decisive difference between the parent stack and a child stack in this design?

A: The parent stack orchestrates the nested resources and acts as the main deployment boundary; child stacks contain the separated infrastructure components.

Q: You receive an error indicating that CloudFormation cannot retrieve a nested template. What should you check first?

A: Verify that the template was uploaded to S3 and that its TemplateURL has the correct bucket, object path, filename, and accessible URL.

Q: Why might creating an S3 bucket work in one account but fail in another with the same name?

A: S3 bucket names must be globally unique, not merely unique within an account. Choose another name if the requested name is already taken.

Q: Which stack should normally be deleted to clean up the nested deployment?

A: Delete the parent stack. It is the top-level management boundary for the nested child stacks and their resources.

Q: What outputs should be visible after this exercise completes successfully?

A: The VPC child stack should output a VPC ID, and each subnet child stack should output its subnet ID.

Practice Questions

Question 1

An engineer runs the following command and receives a stack ID, but the CloudFormation console later shows a nested stack failure. Which interpretation is correct?

A. The stack ID proves all resources were created successfully.
B. The stack ID confirms only that the create request was accepted; status and events must be checked.
C. The stack ID means the child templates were automatically copied into the account.
D. The stack ID indicates that the parent stack bypassed child stack validation.

Correct answer: B

The CLI response indicates that CloudFormation accepted the request. Later stack status and events determine whether the parent and child resources completed successfully.

Question 2

A main.yaml parent template references subnet-one.yaml and subnet-two.yaml, but only vpc.yaml was uploaded to S3. What is the most likely result?

A. CloudFormation creates both subnets from the VPC template automatically.
B. The parent stack ignores the missing child templates.
C. The nested deployment fails because referenced child templates cannot be retrieved.
D. CloudFormation stores the missing templates in the parent stack automatically.

Correct answer: C

Every child template referenced by a nested stack resource must exist at the URL specified in the parent template.

Question 3

You need two subnet child stacks to create subnets in the VPC created by a separate VPC child stack. Which design best matches the lesson?

A. Hard-code an unrelated VPC ID in both subnet templates.
B. Expose the VPC ID from the VPC child stack and use that output for the subnet stacks.
C. Create the subnets first and let CloudFormation discover the VPC afterward.
D. Place the subnet templates in a different S3 bucket without changing the URLs.

Correct answer: B

The VPC stack output provides the identifier needed to connect the subnet stacks to the correct VPC while keeping the templates separated.

Question 4

An engineer wants to remove the complete nested deployment after testing. Which command and target are the best choice?

A. aws cloudformation delete-stack --stack-name <child-subnet-stack>
B. aws s3 rm s3://<bucket-name> only
C. aws cloudformation delete-stack --stack-name <parent-stack>
D. Delete the VPC manually in the VPC console first

Correct answer: C

The parent stack is the top-level deployment boundary. Deleting it initiates cleanup of the nested deployment; separately created S3 artifacts may still require their own cleanup.

WordPress Metadata

Suggested Slug:
create-nested-cloudformation-stack-aws-cli

Meta Description:
Learn how to build, publish, deploy, verify, and delete a nested AWS CloudFormation stack using AWS CloudShell, Amazon S3, and the AWS CLI.

Tags:
AWS CloudFormation, nested stacks, AWS CLI, AWS CloudShell, Amazon S3, infrastructure as code, VPC, subnets, CloudOps, SOA-C03