CloudFormation Multi-Stack Architecture

In my previous post, I have talked about deploying a CloudFormation nested stack. Here I will discuss how I made that nested stack work and the differences between a nested stack and cross-stack references.

Multi-Stack Architecture

Most simple projects will use a single CloudFormation stack. This has all the resources together in the same stack. All of the resources are isolated from other stacks and are created, updated and deleted together. None of the resources are shared between any other stacks.

There is nothing wrong with this single template approach for smaller projects. There is the potential to hit the 500 resource limit per stack, and if creating multiple similar stacks, each one would need to have the same resource duplicated per stack. Such as creating a VPC for each stack. That VPC resource would need to be copied into each stack, duplicating code.

The multi-stack architecture enables resources to be split up per stack, it also allows for resources to be shared between stacks. Multi-stack architecture can even allow for base resources to be created in one stack and shared with other stacks. Such as a VPC where other stacks will share the same VPC and build their resources onto that VPC.

Multi-Stack Architecture – Nested Stacks

Each nested stack will have a root and parent stack. The root and parent stack shown in the diagram as the top stack. The root stack is created manually, by either a human or software process. This stack spawns the VPC and SG stacks. It is important to be aware that the child stacks such as VPCStack or SGStack can also be parent stacks and spawn other child stacks. This will give a hierarchy with the root stack sat at the top.

Inside the VPCStack there are two resources, one for each child stack for the VPC and SG. These templates are stored in S3 and can be reused many times by other nested stacks. The nested stacks will create brand-new resources each time they are used. The VPC or SG will not be shared between stacks. Only the code to create the resource is shared, meaning less duplication in writing, but not in actual resources created in the AWS account.

There are two parameters referenced by the SGStack. These are outputs from the VPCStack, one for VPCId and the other for PublicSubnetA. Those output parameters are then imported into the SGStack. Outputs between child stacks are passed via the root or parent stack.

The stack forms a single solution and is lifecycle linked, meaning that all the resources are created, updated and deleted together. To share resources between stacks that are not lifecycle linked this would be cross-stack references.

Multi-Stack Architecture – Cross-Stack References

Cross-stack references are used when there is a requirement for resources to be shared between stacks. For example, creating a single shared VPC for multiple environments.
Stacks are isolated by default, however there is a way to reference parameters between stacks, although there are limitations to be aware of.

Values are exported to an exports list in the region the stack has been created in. The exports list is isolated per region and per account. Each value must be uniquely named and may then be imported into other stacks using Fn::ImportValaue

Below is an example of a cross-stack reference. This is the same as the nested stack, where there is a VPC created in one stack and a security group created in another stack. The VPC and a public subnet is passed from the VPC stack to the security group stack.

The VPC is being shared out to any other stacks that import the VPC ID parameter and use it.
The important part of the VPC Stack is the outputs, the Export key