Parameter Store for cross stack references
corrjo opened this issue · comments
Description
(see: aws/aws-cdk#13184, aws/aws-cdk#13804)
Cloudformation exports work really well for consuming properties of long lived resources, like vpc or subnet ids, however when you have a cdk app with stacks and resources that have variable lifecycles, using exports can lead to a rough time with stacks or resources being locked because something is consuming its export leading to having to do something like https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references
How I handled this in CFN
Before using cdk, this was an issue that would pop up on occasion and this led me and my team to make broader use of nested stacks, and parameter store.
Nested stacks worked well enough, but it ended up requiring a lot of planning and overhead since passing values between nested stacks at the same level or more than 1 level deep becomes a bit convoluted, hence parameter store to the rescue.
Creating standardized parameter store paths for values based on the app or service we were deploying and consuming those cross stack using the native cloudformation parameter store parameter type gave us a lot of flexibility, allowed us to update resources as we needed and run the stack update on the consuming stacks to pick up new values
I believe using parameter store as the default method for sharing values across different stacks in the same app makes makes the most sense in cdk.
Working Backwards
When passing objects or values between stacks, instead of the producer stack creating a cfn export, it creates a ssm parameter store parameter. The consuming stack then consumes that parameter and the value is resolved with a !Ref
Roles
- Driver (drives the proposal to completion): @corrjo
- Approver(s): (assigned by CDK team)
Is this just bypassing the safety mechanism that CFN offers? If I have a Lambda in Stack A that imports an IAM Role from Stack B and sticks it in some env variable, even if you dynamically update the reference in the stack defnition, my active lambdas will still be using the old value and will fail assuming you deleted the old role.
Looking at https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references, isn't another option to cdk deploy --exclusively {consuming stack} to remove the reference, then proceed with the update of the rest of the stacks?
Duplicate of #82