## CloudFormation Nested stacks How to organize tens of serverless functions into CloudFormation stacks? There are two principles I've found useful. Let's say we are developing a system that ingests data from 5 different SaaS platforms. For each platform we have a connector. The connector consists of lambdas, SQS, triggers, parameters, etc, and what not. How to organize these resources into Cloudformation stacks? ### 1. Put resources that are related to each other into one independent stack All connectors are quite indepednent. So we put all the resources that are related to each other into one Cloudformation stack. With 5 connector, we end up with 5 CloudFormation templates. Advantages: - highly cohesive templates with loose inter-template coupling - stacks can be deployed independently to each other. Disadvantage: cumbersome deployment - one needs to deploy multiple stacks, this could be technically cumbersome, boilerplate - the system is prone for letting ### 2. Put stacks together using nested stacks Advantage: - all the advantages of using #1 - plus, conveniently deploy only one stack - less boilerplate ```yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: AWS infra for business intelligence Resources: InvoicingConnector: Type: AWS::CloudFormation::Stack Properties: TemplateURL: './invoicing-connector.yml' UserFeedbackConnector: Type: AWS::CloudFormation::Stack Properties: TemplateURL: './user-feedback-connector.yml' PaymentConnector: Type: AWS::CloudFormation::Stack Properties: TemplateURL: './payment-connector.yml' CustomerUsageConnector: Type: AWS::CloudFormation::Stack Properties: TemplateURL: './customer-usage-connector.yml' CRMConnector: Type: AWS::CloudFormation::Stack Properties: TemplateURL: './crm-connector.yml' ``` Migrating to nested stacks: Note that this will mean that we either import the existing resources into the new stack (quite cumbersome) or re-create all the resources (which means new endpoints and API keys). I imagine the latter is the simplest and will involve only limited downtime, but the deployment needs to be managed a bit more than usual.