Getting organized my multi-App CDK Scripts
As AWS Solutions Architects, we work with lot of CDK code. Getting it organized for multiple resources and apps can be challenging. Through trial and error, I found an effective pattern managing multiple apps, which I'd like to share.
Rodrigo Asensio
Amazon Employee
Published May 20, 2025
Last Modified May 28, 2025
Trust me, having a clean project structure makes life so much easier. Here's how I organize mine:
I'm not a fan of the "lib" directory but is what CDK uses by default. As developer, I would prefer a "src" but I'm sticking to standards here.
I found that breaking everything into smaller, logical stacks saved me tons of headaches later. Here's what worked for me:
- I separate my resources into focused stacks
- I keep shared stuff (like VPCs) in common stacks
- I use stack props to pass information between stacks
Starting with multiple repos "because in the future we might need it" is usually a bad idea. If for some reason, later on you actually have the need to change things, it will be a great problem to have, but for now, keep it simple.
If you are a solo dev or work for a company, at least you want to have 2 environments. If you are a big enterprise, I bet you have 2+. Here's a neat trick I use for handling different environments:
I learned the hard way that you need a solid deployment strategy. Here's what I do now:
I leverage AWS CodePipeline for my deployments. It's been a game-changer for me, especially when managing multiple environments. If you want to learn more about it, here's the doc. Continue reading for the more simple approach.
I created this super simple and effective deployment script:
I've found these approaches really helpful:
- I keep my context variables in cdk.json
- I separate my environment configs into different files
- For sensitive stuff, I use AWS Systems Manager Parameter Store, for example:
Let me tell you, good testing saves you from late-night emergencies. I make sure to write unit tests for my constructs. There are no excuses today with the help of AI. You can leverage Amazon Q Developer for this.
Here's what keeps me sane with version control:
- I commit when I have a meaningful working feature or code.
- Depending the project, If I work solo, I use only 1 main branch with both environments. Probably not the smartest idea if you work with peers, then you should move to a dev and main branches and each developer, branch out their feature, same as you do to code an app.
- In team environments, I always tag my production releases
- I maintain a changelog (future me always thanks past me for this). Writing commit or changelog messages is not easy, but again, today you can leverage AI to do it.
We get tempted to over engineer stuff for the future, but most likely that future won't happen. What you can do today is keep things simple, easy to understand and well organized. If the future need for a more complex organization arises, then you will have a shorter path to get there if you come from simplicity.
Rodrigo Asensio is an AWS Sr SA Manager with 30y of experience working with Education ISVs
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.