0

Currently setting up CDK from scratch here and looking for justification and best practices from the trenches. I have multiple apps which I will naturally have my CDK code and the app code in one repo (reeping the benefits of synonymous languages for app and infra code).

But I am looking for tips on that generic infra. Think the Sec Hub setup, Config rules, Alerting stacks, etc. Basically anything that does not have the app as a dependant. How would you:

  • structure the repo (multiple apps, stacks or stages ?)
  • deploy these if you don't want to risk redeploying all when updating one ?
  • tie this into CI/CD somehow ? If so, how ?

My thought is: one git repo (aws_infra for example), one CDK app, under which I have multiple stacks. Each stack represents a service. Then just deploying it with cdk deploy $yourstackname (or CI/CD equivalent), I guess if I define stacks with different environments, it can be deployed to multiple... well, environments. Interested to hear how it would be best set up for

DimitriosK
  • 38
  • 6

1 Answers1

0

You have almost answered you own question. I prefer to use one repository with a single CDK app with multiple stacks which then consist of constructs. We use stacks to separate independent blocks of code, such as a network-stack, a logging-stack, database-stack, application1-stack etc. such that we can deploy the stuff that changes often together. It is a hassle to pass parameters between stacks to be careful to not split two things that should be together.

I recommend to read the documentation page for best practices using CDK. The section Construct best practices will answer many of your questions.

Regading CI/CD, you could set up something that chooses the stack to deploy depending on what folders have changed in a given PR.

Trygvi Laksafoss
  • 306
  • 1
  • 6
  • 1
    Thank you, I've scoured most resources on suggested best practices, the AWS one being my bible. From your answer I take it that generic infrastructure (that is not linked to any overarching product) would follow the same idea. Set up a central repo and have every resource that is not tied to another in their own Stack. Great pointer on CI/CD, that was sort of my idea when it comes to automating the bigger generic infrastructure deployment. – DimitriosK May 30 '23 at 09:47