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.
