(aws-ssm): valueFromLookup should have an option to skip context caching

[cynicaljoy]

When using ssm.StringParameter.valueFromLookup() I would like to have the option to not store the value of the parameter in the cdk context so the parameter is resolved every time that I synth.

Use Case

In particular, I store the value of which ECR Image Tag should be deployed in my Task Definition for my Fargate Service. Currently, if I forget to cdk context --reset ... then I can potentially deploy a previous version of the application. If I was able to skip storing the value in the context I would not have to manage this risk.

Proposed Solution

ssm.StringParameter.valueFromLookup(this, '/my/ssm/parameter', { skipContext: true });

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[mrpackethead]

There may in fact be many cases where it might be useful to have this option. not just for ssm lookups but any context lookup

[wr-cdargis]

The workaround I've been using is to build the reset into the CI/CD pipeline:

Synth = new ShellStep("Synth", new ShellStepProps
{
    InstallCommands = new[]
    {
        "npm install -g aws-cdk"
    },
    Commands = new[]
    {
        "cdk context --reset key"
    }
})

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[mixtah]

I have a similar use case and want to know if this is being explored any time soon?

[gautamdevendra]

any progress? similar issue here

[andreialecu]

PR at #29372 to add this

[samson-keung]

@cynicaljoy @andreialecu There is a token provided by CFN - {{resolve:ssm:parameter-name:version}} - which resolve the value at deployment time (link to doc). It can be used in CDK as well by calling ssm.StringParameter.valueForStringParameter(...) (link to doc). Does that solve your use case?

[cynicaljoy]

The desired result is being able to:

1. Create SSM parameter '/my/ssm/parameter'
2. Use ssm.StringParameter.valueFromLookup(this, '/my/ssm/parameter') in my CDK stack
3. cdk deploy
4. Update SSM parameter value
5. Make no code changes and don't require me to remember to run a cdk context --reset
6. cdk deploy -- new value is used.

Having to explicitly add the version means that we need to go through PR review every time we want to change an SSM parameter value 🤢

[samson-keung]

I see. Thank you for adding your use case. I tested the behaviour of the valueForStringParameter approach and I was able to deploy with latest parameter value without code change. Here is my testing stack:

export class SsmStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, {
      ...props,
      stackName: 'SsmStack'
    });


    const alarm = new Alarm(this, 'TestAlarm', {
      metric: new Metric({
        namespace: StringParameter.valueForStringParameter(this, 'my_param'),  // <-- No version is specified
        metricName: 'my-metric-name'
      }),
      threshold: 0,
      evaluationPeriods: 1,
    })
  }
}

Then I do the following:

1. Perform initial deployment of the stack
2. Verified that Alarm use namespace value1
3. Go to SSM to update the value of my_param to value2.
4. Without changing code, run cdk deploy.
5. Verified CFN proceed to updating the stack
6. Verified the Alarm uses new namespace value2

But I stand corrected that valueForStringParameter actually does not use the {{resolve:ssm:parameter-name:version}} token under the hood. It uses stack parameters instead.

[cynicaljoy]

I anticipate this changed somewhere along the way since I reported the issue. TBTH I don't use CDK day-to-day anymore...not by choice 😢

If others can confirm, this issue could be closed.

[samson-keung]

No worries @cynicaljoy. Really appreciate you spending time to reply even though not using CDK day-to-day anymore. I just wanted to understand the requirements more, hence, wanted to dive deep into use cases. Thank you!