chore(ssm): latest parameter value with dynamic reference

[jogold]

CloudFormation now allows referencing the latest Systems Manager parameter
values in templates without specifying parameter versions using dynamic
references.

Remove the "trick" with the Parameter using a default value.

See https://aws.amazon.com/about-aws/whats-new/2021/04/now-reference-latest-aws-systems-manager-parameter-values-in-aws-cloudformation-templates-without-specifying-parameter-versions/

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[jogold]

⚠️ This will influence the following behavior:

aws-cdk/packages/aws-cdk/lib/api/deploy-stack.ts

Lines 220 to 227 in 7966f8d

	if (await canSkipDeploy(options, cloudFormationStack, stackParams.hasChanges(cloudFormationStack.parameters))) {
	debug(`${deployName}: skipping deployment (use --force to override)`);
	return {
	noOp: true,
	outputs: cloudFormationStack.outputs,
	stackArn: cloudFormationStack.stackId,
	stackArtifact,
	};

and

aws-cdk/packages/aws-cdk/lib/api/util/cloudformation.ts

Lines 427 to 432 in 7966f8d

	public hasChanges(currentValues: Record<string, string>): boolean {
	// If any of the parameters are SSM parameters, deploying must always happen
	// because we can't predict what the values will be.
	if (Object.values(this.formalParams).some(p => p.Type.startsWith('AWS::SSM::Parameter::'))) {
	return true;
	}

= stacks that previously had Parameters with default values to reference latest SSM parameters where never skipped now they will be...

[jogold]

⚠️ This will influence the following behavior:

aws-cdk/packages/aws-cdk/lib/api/deploy-stack.ts

Lines 220 to 227 in 7966f8d

	if (await canSkipDeploy(options, cloudFormationStack, stackParams.hasChanges(cloudFormationStack.parameters))) {
	debug(`${deployName}: skipping deployment (use --force to override)`);
	return {
	noOp: true,
	outputs: cloudFormationStack.outputs,
	stackArn: cloudFormationStack.stackId,
	stackArtifact,
	};

and

aws-cdk/packages/aws-cdk/lib/api/util/cloudformation.ts

Lines 427 to 432 in 7966f8d

	public hasChanges(currentValues: Record<string, string>): boolean {
	// If any of the parameters are SSM parameters, deploying must always happen
	// because we can't predict what the values will be.
	if (Object.values(this.formalParams).some(p => p.Type.startsWith('AWS::SSM::Parameter::'))) {
	return true;
	}

= stacks that previously had Parameters with default values to reference latest SSM parameters where never skipped now they will be...

Decided to not skip deploy if a {{resolve:ssm:param}} is detected in the template.

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 13909c5
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mjgp2]

Hi @jogold

This change doesn't work if you are trying to update a stack without changing the template, because CF does not register these {{ssm}} template values as parameters, and so will not you create a changeset because it thinks nothing has changed as it doesn't seem to be smart enough to determine that there is a change? This fundamentally breaks a CI pattern we have where we are updating the SSM value for a ECR image, and then updating the stack using the current template via AWS CLI.

[jogold]

@MrArnoldPalmer what do you think?

I understand how it breaks things here for this use case but on the other hand the new behavior is more deterministic which is more in line with how the CDK normally behaves?

@mjgp2 how are you updating the SSM value? manually and then you don't want to copy the new version in your stack?

[mjgp2]

SSM values can be updated by a whole bunch of processes within Ops. The main thing for us it to be able to apply these SSM parameters to an existing cloudformation stack as part of automation (such as CI or release processes) but guarantee no change in the stack other than the parameters. Difference IAM roles are allowed to update certain SSM parameters than update a stack.

It seems fundamentally that perhaps this is a cloudformation issue, because my expectation (even without using CDK) would be that I can refresh the parameters in a stack. This inline syntax does not allow it.

As this is a breaking change I would very much suggest that there is the option for either underlying CF template to be generated while CF sorts out the differences between the parameter behaviour and the inline template behaviour.

[mjgp2]

Thanks for this @jogold - I'm not sure that the CF team realises this difference in behaviour. Seems very odd!