SSM - parameter path and value changes are not updated in the stack.
See original GitHub issueThere are two ways of resolving ssm parameters (as long as it isn’t a secure parameter):
ssm.StringParameter.valueForStringParameter
ssm.StringParameter.fromStringParameterAttributes
They behave differently, but according to the documentation I would expect them to behave the same.
-
Test by changing paths ie: change the SSM path from one deployment to the next. Retrieving by value does what I expect - it updates values when the path changes.
Retrieving by attributes does not. The value in the stack will not change. -
Test by changing values it doesn’t matter what we change, the values in the stack do not change.
Reproduction Steps
https://github.com/brettswift/cdk-ssm-test
follow the README.md
shell scripts are there to demonstrate everything.
Environment
- **CLI Version 😗*1.36.1
- Framework Version:
- **OS 😗*OSX
- **Language 😗*typescript
This is 🐛 Bug Report
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:6 (1 by maintainers)
Top Results From Across the Web
How can I update a stack parameter which was set by an SSM ...
I have an SSM parameter value set with a value I want to use in a CFN ... do not update the environment...
Read more >Working with parameter versions - AWS Systems Manager
Create and reference parameter versions to use in API commands and SSM documents. ... In the Value box, enter a new value, and...
Read more >How to update existing SSM Parameter with AWS CDK
My use case: In first stack I am creating SSM parameter. In the second stack want to update(change) it. One of solution that...
Read more >Fixing CloudFormation SSM parameter drift
To workaround this, you'll have to update the timestamps of the affected SSM parameters in the template. First, open the stack in CloudFormation ......
Read more >SSM parameters in AWS automation
When the lambda stack update is launched, CloudFormation retrieves the current parameters values from SSM and applies to resources. Obviously, ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
After testing this the only scenario that I could reproduce was the first one - changing the parameterName. It looks like this is due to the way CloudFormation (and CDK) handles parameters, i.e. by default
cdk deploy
uses--previous-parameters
which tells CloudFormation to use the previous parameter value (the parameter name in this case).When you use
valueForStringParameter
CDK generates a logicalId that includes theparameterName
. So when you change the parameter name the logicalId changes which causes CloudFormation to see it is a different (new) resource and it fetches the new value. https://github.com/aws/aws-cdk/blob/main/packages/@aws-cdk/aws-ssm/lib/parameter.ts#L441-L441When you use
fromStringParameterAttributes
the logicalId is set to whatever you provide as the constructid
. When theDefault
for a parameter of typeAWS::SSM::Parameter::Value<String>
changes, it does not cause CloudFormation to fetch the new value, because of the--previous-parameters
options. If you instead runcdk deploy --no-previous-parameters
you should see the new value being used.There are a couple of workarounds that you can use.
--no-previous-parameters
when you update the parameter name.id
to have CloudFormation treat it as a different resource.A permanent solution to this may be to update the
fromStringParameterAttributes
to generate a logicalId the say way thatvalueForStringParameter
does.doesnt work for me