Fallback to default value instead of throwing error if SSM parameter not found

[ericxinzhang]

My stack references a SSM parameter value, something like this:

    new cdk.CfnOutput(this, 'Test', {
      value: ssm.StringParameter.valueFromLookup(this, '/test/param'),
    });

When the stack is deployed it's throwing error TestStack failed: Error [ValidationError]: Unable to fetch parameters [/test/param] from parameter store for this account.

Is there a way to suppress the error and fallback to a default value? I am not even sure if CloudFormation supports it.

PS: Ideally I should get the SSM parameter ready but in my scenario I can't when the stack is deployed first time. If it's impossible I am going to write a bash script which calls AWS CLI, fallback to default value on error and export as env var.

[indrora]

CFN Outputs can only come from the body of the cloudformation template. If you have some external resource that is brought in via cloudformation, you can use that, but if the resource doesn't exist then CloudFormation does not have a way to provide defaults.

[ericxinzhang]

Sorry for the confusion. My code above just uses CfnOutput as an example to consume an SSM parameter. It could be any resources. After synth, the CFN template actually has the SSM parameter as an input parameter.

So my question was if CFN could fallback to the default value if SSM parameter is not present, and apparently it can't as you said.

[ybenitezf]

+1 it be nice if possible

[tokarev-artem]

+1

[peterwoodworth]

@github-actions proposed-answer There is no fallback or default value mechanism that can be enabled - if the lookup fails to fetch the parameter for whatever reason, synthesis/deployment will fail.

You could use a workaround by writing your own bash script which will make this call and writing a value to a file (supplying a default value if the call fails of course), and then reading this file when you run your CDK app. We recommend separating these processes - see the Commit cdk.context.json section for more information

You could open a feature request to natively support this feature on the existing context providers, It does seem to contradict a safeguard we have in place to prevent unexpected changes from getting deployed, but if the use case is valid enough then we can consider allowing a default value when failing the lookup.

[github-actions[bot]]

Hello! A team member has marked the above comment as the likely answer to this discussion thread. If you agree, please upvote that comment, or click on Mark as answer. I will automatically mark the comment as the answer next time I check. If this answer does not help you, please downvote the answer instead and let us know why it was not helpful. I will add a label to this discussion to gain attention from the team.

[github-actions[bot]]

Closing the discussion for staleness. Please open a new discussion if you have further concerns.

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.