How to break existing CloudFormation stack into separate nested stacks, moving existing resources under nested stack

Question

Problem:

Recently we encountered a problem with respect to maximum number of resources that you can declare in a single CloudFormation template. A template can support a maximum of 200 resources and we are very close to reach that limit.

To specify more resources, we need to separate our template into multiple templates by using Nested Stacks, We are evaluating a best approach to breakdown the template.

Our approach:

We have created a nested stack from our main stack and removed some of the resources from main stack and added them into new nested stack.

Error:

We encountered an error in nested stack e.g.

Resource already exists in Root stack

1. Is it possible to break our main template into nested stacks with existing resources? i.e move our existing resources under nested stack? or we just need to add new resources into nested stack and keep our main stack as it is with existing resources ?

2. We already reached 200 resource limit so it's difficult to add more nested stacks as well.

Resources in template,

We roughly have 100 CloudWatch alarms, DynamoDB tables, Lambda's, ES, KMS, S3 and other resources, we wan't to separate them into nested stacks specific to resource types.

Answer 1

You can't 'incorporate' existing resources into new CloudFormation stacks. If you move resources into a nested stack and add the nested stack to your root template, it will try to create new resources in the nested stack first, then delete the old resources in the root stack as part of the cleanup process. As such if the new resources have the same names (and duplicate names are not allowed) then the update will fail.

The solution to this is to deploy the stack in two stages, first removing the resources from the root stack, and then adding them to the nested stack. This will result in a short time when those resources are missing from your environment, but if you keep the migrations small it should only be for a few minutes.

Resources which contain state (like DynamoDB, KMS, S3, etc) are much harder to migrate in this fashion because the data is obviously lost when you delete them. You either need to do a full migration process, creating a new resource with a different name in the nested stack, migrating data over, updating your application to use the new resource, and finally deleting the old resource, or accept that that's probably far too much work for an internal refactor and leave those resources in the root template.