aws-sam-cli: sam build fails when providing a function LayerArn with a reference to a SSM::Parameter CF param

I get that using --parameter-overrides works, but it’s a really non-intuitive way to need to get sam build to work when we want to pass any AWS::SSM parameter types.

It may make sense for sam build to ignore some validation. To build, we don’t need this Ref resolved.

This is exactly how it should behave if the Ref is an AWS::SSM::* parameter. I would imagine a reasonable person wouldn’t expect the parameter value be resolved at build time. Or at the very least, if sam build detects this type of parameter, it should output some kind of warning about needing to use a --parameter-override to pass the validation.

Otherwise, one has to search Github issues to find this solution.

For clarity for anyone else fighting this bug the following literally got me working:

sam build --parameter-overrides param1=arn:::::::1 param2=arn:::::::1

@mindrunner

It is marked as Beta and there seems no support from the devs here. It might even be a stale/dead project.

We are doing our best to keep all issues updated. We also made a release on Friday: https://github.com/awslabs/aws-sam-cli/releases So the project is far from dead.

@christophsteiner Assuming the SSM Value is a Parameter in the CloudFormation Template, you can add --parameter-overrides ParameterKey=MyParam1,ParameterValue=MyValue1 or --parameter-overrides MyParam1=MyValue1. For build, it just has to be a valid layer ARN. It does not have to exist, since we do not do anything with it but validate it is an ARN.

I am trying to work around this to get our CI/CD running again. However, passing --parameter-overrides to sam build does not help at all.

Error: <string> is an Invalid Layer Arn. is what I always get. No matter what parameters I pass for overriding.

My deployment script is bloated by workarounds for sam and cloudformation. Is this supposed to be production ready? I cannot believe, I need to maintain two different versions of --parameter-overrides for sam and aws-cli.

Is there any option to not use sam? Can I use other tools for building?

This issue is more impacting after nested stack feature was released in 1.20.0, see #2763

@dougmolineux

Actually this does work in version 1.18 for me

• !Sub ‘arn:aws:lambda:${AWS::Region}😒{AWS::AccountId}:layer:my-layer:${MyVersionNumberParameter}’

If you add a default numeric value for MyVersionNumberParameter in your template.

Just my two cents. This is extremely impactful to major deployments which share a common library, and which won’t all be deployed with substacks. This should be a must have for enterprise organizations which want to have organizational reference layers.

I am another wishing for a fix/change for this as well…

sam --version: 0.17.0

Using SSM parameters for SAM template parameters is VERY nice. Not validating the Ref would be very OK in the sam build step since I ASSUME the build is there to pack up your code nicely into a package to be upload-able to S3.

Since you are not bundling up the Layers themselves in the code in the SAM Build Step, it makes sense to at least ignore the Layers property of AWS::Serverless::Function.Properties.

So, I hope to hear that this is something to be fixed in a new-er version in the near future. I prefer to keep my sam build steps pretty clean and in line with all of the ‘default’ parameter settings.