CloudFormation structuring & splitting of resources between stacks


A customer maintains one large CloudFormation template per application they deploy. They are currently running into challenges where deployed resources in the stack do not all share the same lifespan. By changing the stack, or deleting + redeploying the stack, the change in IDs has downstream impacts to other applications/components.

How have other customers managed this? Do we have any relevant resources (i.e. blog post, videos, documentation, etc) that would be useful to share with our customer on this topic?

asked 4 years ago1087 views
1 Answer
Accepted Answer

That's a big topic with a lot of options.

  • Exporting and Importing values is one way to share values between stacks. The benefits and weaknesses of this process is that you can't change any values that are exported if another stack is importing them. This helps prevents changing those resources (example: maybe a RDS endpoint string) with instances running in it. The downside is that if you want to change something upstream you can't do it without breaking those dependencies first.
  • If you are going to break apart the stacks you can do nested stacks. This allows you to change those dependencies into parameters and outputs and pass the values between the stacks.
  • Another way to do this is to share values via SSM Parameter store. This approach is more technically complex because you are having to deal with the downstream impact yourself.

Based on what I'm seeing i would recommend using nested stacks and prefer splitting application layers across stacks.

answered 4 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions