Modularizing CloudFormation Templates

Welcome. This lesson explains how to modularize AWS CloudFormation templates to improve separation of concerns, reusability, and team collaboration. By splitting a large, monolithic template into smaller, focused modules—networking, compute, IAM, storage—you get faster deployments, clearer ownership, and easier maintenance. An analogy: a car factory produces multiple models from standard chassis and configurable engines and interiors. In CloudFormation, the chassis maps to core infrastructure (for example, VPC and IAM), while engines and interiors are modular stacks teams can develop independently. Below is an example architecture that can benefit from modularization.

A diagram titled "Modularization in AWS CloudFormation" showing an AWS Cloud layout with a VPC across two Availability Zones containing NAT Gateways, Amazon EC2 Auto Scaling, auto scaling groups and instances. Two module labels on the right read "Network" and "Compute."

Extract the networking layer into one template, compute into another, and IAM into a third. Smaller templates are easier to version, test, and reuse across environments.

A slide titled "Modularization in AWS CloudFormation" showing a large CloudFormation/template icon on the left with an arrow pointing to three smaller template icons on the right, each tagged with a cloud/module badge. The graphic illustrates breaking a monolithic CloudFormation template into multiple modular templates.

Benefits

Reuse modules across environments and accounts.
Reduce template complexity and stack operation time.
Improve team autonomy and parallel development.
Scale and evolve parts of your infrastructure independently.

Core modularization techniques There are three primary approaches to modularize CloudFormation templates:

Technique	When to use	Key benefit
Nested Stacks	Tightly-coupled components with hierarchical organization	Single parent provides a consolidated view and lifecycle control
StackSets	Consistent resources across multiple AWS accounts and Regions	Centralized deployment from an administrator account
Cross-Stack References	Loose coupling where stacks share outputs (e.g., VPC IDs)	Avoid duplication and allow independent lifecycle of stacks

A slide titled "CloudFormation – Modularization Techniques" showing three numbered techniques: 1) Nested Stacks, 2) Stack Sets, and 3) Cross-Stack References, each with a brief description of how they organize or share CloudFormation resources.

Nested stacks A nested stack is a CloudFormation stack created as a resource within a parent stack. Use nested stacks when you want a hierarchical composition and tighter coupling—examples include grouping IAM, networking, or compute modules under a single parent. Advantages:

Reusable modules across parent stacks.
Clear, hierarchical management and visibility.
Updates scoped to the nested stack reduce unintended impact.

A presentation slide titled "Nested Stacks – Benefits" showing a diagram of a parent stack linked to two child stacks. On the right are three labeled benefit boxes with icons: Reusability, Simplifies management, and Enables hierarchical organization.

StackSets StackSets enable deploying a single CloudFormation template from an administrator account to multiple target accounts and Regions. StackSets create stack instances in targets; each stack instance represents a stack in a specific account and Region. Use StackSets for standardized infrastructure (for example, baseline networking or IAM guardrails) across many accounts and Regions.

A diagram titled "Stack Sets" showing an administrator account creating a Stack Set that deploys a regional resource (stacks) to multiple target accounts across two regions. Arrows illustrate the Stack Set pushing identical stack instances into Target Account A, Target Account B, and other accounts in each region.

A stack instance tracks the deployment intent for a specific account and Region. The instance can exist even if the underlying stack creation fails—the stack instance records the desired state and operation status.

A diagram titled "Stack Instance" showing a Stack Set branching into three operations—Create, Update (Preferences/Tags), and Delete—each producing rows of pink stack icons. The Delete branch shows stacks marked with red Xs to indicate removal.

Cross-stack references Cross-stack references let one stack export outputs and other stacks import those values. This is useful when multiple stacks must share foundational resources such as a VPC ID or subnet IDs without duplicating resource definitions. Typical flow:

A Networking stack exports VpcId and subnet IDs.
Database or Application stacks import those exports using Fn::ImportValue/!ImportValue.

A slide titled "Cross-Stack References – Benefits" showing a VPC Stack exporting an Output that is imported by a Database Stack. The bottom lists benefits: reduces duplication, ensures consistency, and improves scalability.

Example: exporting a VPC ID (networking stack)

Outputs:
  VpcId:
    Description: VPC ID
    Value: !Ref MyVPC
    Export:
      Name: !Sub "${AWS::StackName}-VpcId"

Example: importing that VPC ID in another stack

Resources:
  MyDBSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: Subnets for RDS
      SubnetIds:
        - !ImportValue
          Fn::Sub: "${NetworkStackName}-PrivateSubnetA"
        - !ImportValue
          Fn::Sub: "${NetworkStackName}-PrivateSubnetB"

Note: the import syntax can be Fn::ImportValue or the short !ImportValue; the exporter must define an Export.Name and importing stacks must reference that exact exported name. Best practices and operational considerations

Use consistent, discoverable export names (for example, stackname-vpcid or a predictable prefix) and version modules in Git or a shared S3 bucket so teams can find and reuse stable templates.

Track exports centrally so other teams can discover importable values.
Avoid circular dependencies between stacks—Stack A must not import values from Stack B if Stack B imports values from Stack A.
Choose nested stacks for tightly-coupled, hierarchical resources. Choose cross-stack references for independent lifecycles with shared values.
Use StackSets for governance and consistent deployments across accounts and Regions; don’t use StackSets for ad-hoc, one-off pushes.
Export names must be unique per AWS Region and account—plan naming to avoid collisions.
You cannot change an export name while other stacks import it. To rename, remove all imports first, then update the exporter.
Deleting a stack that is still exporting values imported by others will fail—inspect relationships before deleting.

Be cautious when updating or deleting exported values. If another stack imports them, the exporter cannot be deleted and its export name cannot be changed until all imports are removed.

Other practical recommendations

Keep templates focused—split logical components into separate modules.
Aim to keep each template to a few hundred resources where practical; very large templates increase stack operation time and approach service limits.
Store modular templates in version control (Git) and/or a centralized S3 bucket for stable, reproducible references.
Consider higher-level tooling (for example, the AWS Cloud Development Kit) for programmatic composition of reusable constructs and better modularity.

You can also use the AWS CLI to inspect exports and imports:

Command	Purpose
`aws cloudformation list-exports`	List all exports in the account/Region
`aws cloudformation list-imports --export-name <name>`	Show stacks importing a specific export

A slide titled "Best Practices" showing five numbered recommendations about exports and stacks. It lists: use clear/consistent export names, manage exports centrally, avoid circular dependencies, use nested stacks for tight coupling, and use StackSets for cross-region/multi-account scenarios.

Limitations and troubleshooting tips

Export names are unique per Region and account—name collisions will prevent export creation.
You cannot update an export name while there are active imports.
Stack deletion fails if another stack imports one of its exports.
Diagnose relationships using the CloudFormation console or AWS CLI (list-exports, list-imports) to identify who depends on an export.

A presentation slide titled "Limitations and Considerations" showing three checklist items about cloud stack exports: export names must be globally unique within a region, export names can't be updated without deleting references, and stack deletions fail if another stack is importing a value. The slide is copyrighted to KodeKloud.

Summary

Modularize CloudFormation templates to improve reuse, maintainability, and team autonomy.
Use nested stacks for hierarchical, tightly-coupled deployments and consolidated management.
Use StackSets to deploy identical templates across multiple accounts and Regions from a single administrator account.
Use cross-stack exports/imports to share resource identifiers while keeping stacks independently manageable.
Plan export names, avoid circular dependencies, version modules, and use the CloudFormation console or CLI to inspect and troubleshoot relationships.

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

Modularizing CloudFormation Templates

Watch Video