Placing all your resources into a single stack is going to create pain for you later on. Moving and renaming resources between stacks can be quite tricky. Once a resource is managed by a CloudFormation stack it’s not possible to remove that resource without deleting it, and it’s not possible to move a resource from one stack to another. Splitting up your resources across multiple stacks can really help. Here are some suggestions on how you can achieve that.

Resources that change together stay together

Your application may consist of an API Gateway with multiple Lambdas and SNS/SQS resources for internal processing. RDS databases with clustering. VPCs with Subnets, Security Groups, etc. These resources are logically grouped and belong in a dedicated stack.

Stateful Resources

Stateful resources such as RDS, S3, DynamoDB, etc should get their own stack. The only way to move or rename these resources is to define a new resource with a different name and copy the data across. By mixing these resources with more volatile resources you risk having to do this. Best to avoid such a scenario.

Configuration Resources

Configuration Resources such as ParameterStore and SecretsManager belong in their own stack. Changes to these resources should not require a redeployment of the application that uses them.

Application Boundaries

Resources that make up the boundary of an application such as API Gateway, SNS, Kinesis, etc should get their own stack. Other applications access these resources through a “public” contract and minimising disruption to these resources is important.

Shared Resources

Any resources shared by multiple applications should get their own stack. VPCs, Subnets, KMS, S3, etc. VPCs cannot be deleted if they are using by any resources. Removing a KMS key means losing access to data, and moving an S3 bucket means creating a new one and copying the data over to the new bucket.

Conclusion

These are some guidelines that have come in handy over time. Comment below with your experiences and recommendations.