## 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.