This has been asked & answered in a couple of contexts, but I can’t yet see the underlying principles for when it makes sense to create separate stacks – and how these should correlate to services. I’d like to create an architecture that is - • event-first, with autonomous services that communicate async through tools like EventBridge • allows services to be developed and deployed independently/safely of one another This seems to suggest that each service should have its own stack, with some stacks serving common resources (e.g. an Event Hub). Would this near 1:1 service:stack approach be too granular or expensive in effort/costs? Is there a better way to achieve the independence of services above that also consolidates or simplifies the infrastructure stacks?

I generally follow this begrudgingly. It's more organized to have a stack per service. I don't love the chaos of cross stack dependencies but that's entirely a cloud formation issueb

Awesome, thanks Dax. Does your structure end up something like this - or do you pull the stacks inside the service directories for other reasons?

/frontend
/stacks
- index.js
- ServiceNameOneStack.js
- ServiceNameTwoStack.js
- ...
- FrontendStack.js
- EventHubStack.js
/src
- /packages
- /utils
- /services
  - /serviceNameOne
  - /serviceNameTwo
  - /serviceName...

As of now I keep the stacks in the root stacks folder. Not sure if this will stay long term. My project follows the typescript-monorepo example

Yeah just some context. Historically folks have avoided creating multiple stacks until they hit the resource limit per stack. It’s just that with CDK it’s easier to reference resources across stacks, so people feel more comfortable having multiple stacks.

And with the way CF works - I would split them into seperate stacks in your case - so that they are trully independent from each other.