Passionate Engineer
Passionate Engineer

Reputation: 10412

Cloud Formation multiple vs one stack

What’s the best approach for separating CloudFormation stacks? I’m currently separating my stacks by ecs-cluster, elasticache, alb with default target group and ecs service with target group registration to existing alb and SNS subscription. All of them are reliant on CF Import Export. Is this ideal as opposed to one single stack?

The reason why I’m having separate SNS subscription stack is that I need to subscribe and reuse them on multiple topics and I don’t want to create subscription for each ASG, ALB and Elasticache stack.

Also with ECS I can drop ECS service into available clusters of my choice if I have the stacks separated.

Any ideas on best approach here or is this the correct way?

If you look at AWS CloudFormation Best Practices, it states that we need to "Organize Your Stacks By Lifecycle and Ownership". Given they all have different Lifecycle (ie. ALB vs ECS. ECS changes are a lot more often then ALB similar applies for ECS Cluster instances) does it make sense to separate in this way then?

Upvotes: 2

Views: 1200

Answers (1)

Arafat Nalkhande
Arafat Nalkhande

Reputation: 11708

Definitely having sub stacks is a better option compared to having a single stack for multiple reasons

  1. Maintenance is much easier. In programming analogy it is similar to having your functionality split across multiple classes as against to coding everything in one single class
  2. There can be clear separation of concerns and ownership. As the AWS CloudFormation Best Practices page suggests the DB guys can take ownership of DB sub stack and the site admins can take ownership of auto scaling and load balancing sub stack
  3. There are better chances of you staying within the limit for 'Template body size' which happens to be 460,800 bytes

As about how do you decide what all sub stacks to use I think you have almost got it right. You might consider having a roles substack as well

Upvotes: 1

Related Questions