Parameter Store for cross stack references #309
Labels
management/tracking
status/stale
The RFC did not get any significant enough progress or tracking and has become stale.
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
The text was updated successfully, but these errors were encountered: