You have a CloudFormation stack with 300+ resources including VPCs, RDS clusters, and ECS services. Deploying changes takes 45 minutes and rollbacks are painful. How do you restructure using nested stacks and cross-stack references?
Quick Answer
Split the monolithic stack into layered nested stacks by resource lifecycle (networking, data, compute, application). Use cross-stack references via Exports/Imports for shared values. Implement a parent stack that orchestrates deployment order, and use change sets to validate changes before applying.
Detailed Answer
Nested Stack Architecture
Nested stacks allow you to break a monolithic template into modular, reusable child templates. The parent stack references child stacks using AWS::CloudFormation::Stack resources. Each child stack has its own lifecycle and can be updated independently. Structure your hierarchy by deployment frequency and blast radius: networking (rarely changes) at the bottom, databases (occasional changes) in the middle, application services (frequent changes) at the top.
Cross-Stack References
For values shared between independent stacks (not nested), use CloudFormation Exports and Fn::ImportValue. The networking stack exports VPC ID, subnet IDs, and security group IDs. The database stack imports VPC ID and exports connection endpoints. The application stack imports both. Important limitation: you cannot delete or modify an exported value while any other stack imports it. This creates a coupling that requires careful management.
Operational Improvements
With layered stacks, a change to an ECS service only updates the application stack (minutes) instead of the entire infrastructure (45 minutes). Rollbacks are faster because they're scoped to the affected layer. Each layer can have its own update policy and rollback configuration. Use DependsOn between nested stacks to enforce deployment ordering.
Migration Strategy
Migrating from a monolithic stack to nested stacks requires careful planning. You cannot simply split resources into new stacks because CloudFormation would try to delete resources from the original stack. Instead: (1) Add DeletionPolicy: Retain to all resources, (2) Create new stacks that import existing resources using aws cloudformation import, (3) Remove resources from the original stack, (4) Verify state consistency.