IMO the limits of CloudFormation are a bigger pain point than they're made out to be here. The limit of 200 resources per stack is easy to hit, and so is the 450KB template size limit (well, it's possible at least). It's frustrating to need to spread a single service across three stacks because it has a lot of API Gateway endpoints. The real answer is nested stacks, but those still count towards the (raisable) total stack limit of 200.
At least there isn't the limit of 50KB for SAM templates anymore [1]. That was a ridiculous limit, especially as nested templates aren't possible with SAM yet [2].
Exactly. Stack imports/exports was launched to address the shortcomings of nested stacks. Avoid using nested stacks in favor of stack imports/exports. Actually, avoid both nested stacks and stack imports/exports in favor of SSM parameters.
200 resources is way way too many for a single template. Split up your API Gateway API resources, methods, and models into multiple stacks. One stack for the API, another group of stacks for the API resources, methods, models, and another stack for your API deployments.
I'm guessing it's heavily dependent on what you're using it for, what kind of resources are you describing in CFN?
In my case, it's Lambda + API Gateway that's the main culprit. For each endpoint in an API, there's a resource for the lambda itself, and a managed policy, role, log group, subscription filter, API resource, method, lambda permission, model, and additional OPTIONS method for CORS purposes. With a setup like that, you can hit the limit with a moderately-sized API.
or you can utilize exported resources, like the article describes, and append your API endpoints to the "master" API Gateway resource that is not even in the same stack.
Yes, that's the solution we came up with. One stack with lambdas, managed policies, roles, user pool, etc; one stack with the APIGateway::RestApi and some resources and methods, and then another stack with yet more resources and methods. This works, but I don't think it's a great solution. Wouldn't it be preferable to have one stack that encompasses the whole API for one service?
