(ssm): Dynamic SSM parameter reference introduced in #14205 doesn't work for lists

In CDK 1.101.0 a breaking change was introduced (PR #14205): References to SSM parameters now don’t use CFN parameters of type AWS::SSM::Parameter::Value<String>, but use dynamic resolution using {{resolve:ssm:...}}. This way, no CFN function can be applied on the parameter value, because as it seems those are evaluated before the parameter resolution.

For us, this means we cannot import any list values from SSM parameters, because Fn::Split cannot be applied.

Reproduction Steps

    const getStringListParam = (name: string) => {
      return Fn.split(',', StringParameter.valueForStringParameter(scope, `${basePath}/${name}`));
    };

    const vpc = Vpc.fromVpcAttributes(scope, id, {
      vpcId: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/VpcId`),
      availabilityZones: getStringListParam('AvailabilityZones'),
      privateSubnetIds: getStringListParam('PrivateSubnetIds'),
      privateSubnetRouteTableIds: getStringListParam('PrivateSubnetRouteTableIds'),
    });

What did you expect to happen?

The code above works perfectly fine up to aws-cdk version 1.100.0

What actually happened?

In 1.101.0, the above code renders to

              "Fn::Split": [
                ",",
                "{{resolve:ssm:/platform/vpc/default/PrivateSubnetIds}}"
              ]

what is failing in Cloudformation (IDs obfuscated):

The subnet ID 'subnet-1111111,subnet-222222' is not valid (Service: AmazonElasticLoadBalancing; Status Code: 400; Error Code: InvalidSubnet; Request ID: 1111-2222-3333-4444-5555; Proxy: null)

Environment

• CDK CLI Version : 1.101.0
• Framework Version: 1.101.0
• Node.js Version: v10.19.0
• OS : Ubuntu 20.04.2 LTS
• Language (Version): TypeScript

---

This is 🐛 Bug Report

[tomas-mazak]

@jogold @MrArnoldPalmer sorry if this is off topic but I think that this issue also shows a little gap in CDK tests - the tests assert that “code renders to expected CFN template” but not whether such template is valid and semantically correct - it would be awesome if CloudFormation could be run in some dry-run mode, where it would call the tester’s mock API instead of the actual resource providers … with assertions like: “creation of ABC resource was requested with XYZ parameters”. What do you think?

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.