CODEWITHSUNDEEP
aws-cloudformationaws-cdk
froi
froi

Reputation: 7788

Circular dependency between AWS Cloudformation stacks bad practice?

Just to clarify, I'm not pertaining about circular dependencies on the resource level.

I'm talking about 2 separate stacks, lets say Stack A and Stack B. Overtime they developed bi-directional dependencies to each other. Stack A imports resources from Stack B and vice versa. And they work fine.

My worry is, the re-deployability aspect of the stack. Like if we decide to deploy it on another account, they will fail to deploy since they need the other stack's resources to work.

Chicken and Egg problem basically.

Question is, should this situation be avoided? Or it's just a normal way of doing things?

Upvotes: 5

Views: 3346

Answers (1)

lynkfox
lynkfox

Reputation: 2400

If you find yourself using any of the cdk "from" methods (fromAttributes, fromArn, ect) to import an existing resource into a stack, you need to take a long hard look at your stacks.

If they must be linked, then you should make all these stacks Nested Stacks under a common stack above them - and instead of using from, pass them as parameters into the stack creation: ie: (in python)

my_starting_stack = MyStartingStack(self, "StackID")
my_second_stack = SecondStack(self, "SecondID", special_bucket=my_starting_stack.special_bucket)

as long as both stacks are cdk.NestedStacks (python, but the nested stack class is available in all languages) and contained within the same stack then they will a) be deployed together always and b) not end up with any dependency locks by passing constructs between them

If they must be able to be deployed independently - and in theory, without the other one existing at all - then you should be adding some form of interaction layer between them - a REST Api or Websocket or something.

Ask yourself this question. If tomorrow you had to deploy one stack on one account and the other in an entirely different account, would they still be able to work? From your description the answer is no, and therefor they are too tightly coupled.

If an interaction layer (api) feels like overkill and they never need to be deployed independently, than make them NestedStacks in a single common main stack is the best practice for sharing resources between stacks.

Do note there are some situations where you dont have a choice.

If you are in an organization that has multiple aws accounts, one for each product (a common structure) you may have things that are automatically added to that account - such as VPC that is already hooked up to the other VPCs in other accounts when that account was created for your team. - These are situations where you have no choice. You cannot control that VPC, you cannot change it, and most certainly you don't want to create a new one every time you deploy a new stack. So importing this is a situation where the 'from' methods are valid usage.

Upvotes: 2

Related Questions