Redesign to lower amount of stacks for CDK pipeline?

[MaximilianSchon]

We are currently building an application with CDK (NodeJS) and have been doing deploys manually with cdk deploy. We are now in a phase where we would like to start deploying the application more formally with a CI/CD pipeline, so we decided to use CDK pipelines as I feels it gives me the most benefit. Sadly we have way too many stacks for that to work.

Currently we divide our stacks into:

• necessary setup (authorizer, api gateway, domains, certificates and lambda layers) (one stack)
• events (contains an eventbridge rule and at least one handler of that rule) (one stack per event, about 200)
• models (contains routes for that models api gateway, dynamo table, eventbus, lambdas) (one stack per model, about 100)
• util (basically anything that is not a model or an event, could probably get thrown into the "necessary setup") (one stack per "utility", about 15)

What this leads to is us having a ton of actions (likely in the 700s), which means we exceed the number of actions we are allowed to have when using AWS CodePipeline by a lot (we also have about 250 FileAssets), and we would like to first deploy a test environment and later deploy that to prod, meaning that we are likely looking at 1500 actions.

What would be the most reasonable course of action?

I am currently looking at:

• Setting up a manual pipeline which just simply deploys everything (cdk deploy --all)
• Redesign the system to decrease the amount of stacks

[peterwoodworth]

You could always request a limit increase above the default 500 action limit per pipeline

Else, I'd be interested to hear why you need one stack per event / model? Are there any potential ways you could refactor this down?

[MaximilianSchon]

Thank you for your reply!

The total actions per pipeline does not seem to be adjustable, sadly.

We don't particularly need it, but it made sense for the design we had. We also kept hitting other limits, such as the maximum nested stacks, maximum policy size (not sure if it was related) and also hitting request limits in API Gateway (429) because it was deploying the nested stacks too quickly (at an earlier stage, which was solved by splitting everything into their own stacks).

Since we have about 250 lambdas which uses the NodejsFunction construct (so far), we will likely hit the limit again once we get to 500, so we decided against refactoring.

Is there a possibility for CDK to split the build into larger actions once it reaches 500? For example by deploying two stacks in one action (if that is not a limitation by CF)?

[peterwoodworth]

These quotas are fixed and cannot be changed

Ah, you're right, unfortunate.

Is there a possibility for CDK to split the build into larger actions once it reaches 500? For example by deploying two stacks in one action (if that is not a limitation by CF)?

I don't think this is possible, no. My understanding is that all actions have to be defined on the actual pipeline resource in the cloudformation template. i'm not sure if actions could be combined either

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.

[maslick]

Same here. We’re using the CDK Pipelines framework. Currently, our CodePipeline, which was created using the ‘opinionated’ CDK Pipelines framework, generates 445 assets for deployment to the target account. As a result, we’re reaching the 500-resource limit imposed on the CloudFormation stack that defines the CI/CD pipeline.