AWS-CDK: Single stack vs. Multiple stacks?

3
votes

I keep seeing different implementations on aws-cdk, and I want to know if there is a preferred convention.

  1. Single stack. This makes sense if all the resources are related (i.e., a Lambda and an IAM role should be in the same stack, not in different ones). However, this has the problem of the 200 resource limit, which can be a problem once you start creating alarms for each table and whatnot.

  2. Multiple stacks. This makes sense because it compartmentalizes the application nice and easy (i.e. all DDB in one stack, all IAM roles in another). However, I've had a bunch of issues with ChangeSets versions when there's dependencies among stacks (My Lambda stack depends on my IAM stack, but the Lambda stack used the old ChangeSet from IAM, so now I can't update my stuff). I ended up taking the single stack approach because of constant issues with this.

I would like to know the opinions on this; I would have expected to find a rule of thumb here, but so far I haven't come across one.

Thanks!

1
aws-cdk
Are you using nested stacks or just a whole new stack? – moltar
Right now I just use one big stack which contains everything I need. But thinking about scalability, this will be a problem with the 200 resource limit... – josmolin
fwiw, the resource limit was recently increased from 200 to 500. aws.amazon.com/about-aws/whats-new/2020/10/… – Nick Cox

1 Answers

1
votes

CloudFormation stacks aim to be updated atomically. That is either all updates to the stack complete successfully or all updates are rolled back. I use the following check list as rule of thumb when grouping infrastructure components into stacks:

  • if the stack update fails, would I want to rollback all resources
  • is it likely to use some resources from this stack in another stack
  • are the resources I'm about to add functionally related e.g. the refer to same business capability

If the answer to any of the above is yes I tend to extract the resources into separate stacks.