Amplify-cli: So Lambda Layers are not multienv and not actually deleted after remove?

Created on 21 Jul 2020  路  12Comments  路  Source: aws-amplify/amplify-cli

Which Category is your question related to?
function

Amplify CLI Version
4.24.3

Provide additional details e.g. code snippets

So I've started to use Layers, and I had a few question:

1) I notice the ARN for the layer created via amplify cli does not contain any reference to the env the cli was operating in (dev, prod, etc..). So I guess layers are global and you just use the layer version to connect to it regardless of env name?

2) If this is the case, there appears to be a bug where amplify cli does not actually sync with the available version numbers of a lambda layer. if you add a lambda layer, create a few versions, push, then do amplify function remove and remove the layer. Then create a brand new amplify stack and add a layer with the exact same name as the layer you added and removed before. Amplify CLI will think the latest version of the layer is 1, when it is actually a bigger number since the previous layer and layer versions have not been removed.

P.S. In my case, the original layer was created in a beta version of amplify cli when I was giving feedback to the amplify team. But I don't think that is the cause of this issue.

bug functions lambda-layers pending-release

Most helpful comment

Multi-environment support for Lambda layers has been released in 4.29.0.

This update will only affect newly created Lambda layers.

If you want to migrate a layer:
-create a new layer with amplify add function
-copy the contents of <project-root>/amplify/backend/function/<old-layer-name>/lib/ to <project-root>/amplify/backend/function/<new-layer-name>/lib/
-update all dependent Lambda functions with amplify update function
-remove the old layer amplify remove function
-amplify push

This will only delete the layer from the project bucket because Lambda layer versions created by the CLI have a DeletePolicy set to Retain. To completely remove the old Lambda layer, delete each version from the Lambda console. We will look to improving the layer removal experience in the future.

All 12 comments

In fact even if I delete the layers in aws console, when the layer with the same name is created, the version number does not start at 1. It seems I have to pick a different name for the layer.

Furthermore, it doesn't seem deployments involving lambda layers are atomic. Lambda Layer is created before lambda is updated. But if lambda deployment fails for some reason, a rollback is triggered, but ofcourse lambda layer new version deployed can not be really removed so it's not a clean rollback.

Here's an example error that can cause this situation:

2020-07-22T19:54:45.417Z [INFO]: UPDATE_IN_PROGRESS          LambdaFunction                                                      AWS::Lambda::Function      Wed Jul 22 2020 19:54:42 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_FAILED               LambdaFunction                                                      AWS::Lambda::Function      Wed Jul 22 2020 19:54:42 GMT+0000 (Coordinated Universal Time) Function code combined with layers exceeds the maximum allowed size of 262144000 bytes. The actual size is 334073583 bytes. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: c2f6f8ce-07ab-41c0-af78-5e250db9cf99)
                                 UPDATE_ROLLBACK_IN_PROGRESS amplify-... AWS::CloudFormation::Stack Wed Jul 22 2020 19:54:44 GMT+0000 (Coordinated Universal Time) The following resource(s) failed to update: [LambdaFunction].

So even if we follow ideal happy case, it's very easy for amplify cli to get out of sync with actual versions available in the layer. I don't think I'm able to use layers in production until this issue is resolved.

Also I don't understand why I'm getting above error about my lambda being too large. My lambda layers dist file is 41.4mb and lambda dist file is 956kb. Regardless, it's not worth investigating further. I'm going to go back to my pre-layers code and give layers another go once this issue plus https://github.com/aws-amplify/amplify-cli/issues/4852 is fixed.

Also removing a layers reference from a lambda does not seem to remove the layer parameter in the lambda's cloudformation-template.json. I still have this:

    "functionMyLyrArn": {
      "Type": "String",
      "Default": "functionMyLyrArn"
    }

Hi @hisham - appreciate the feedback and details here. @jhockett is actively looking into getting this resolved.

+1

+1 from me too. Had an issue with my new layer being env-private (dev) and the next env (prod) not seeing any reference to it upon pushing... The CLI never even tried creating a new one.
Resolved this by manually adding the layer function again but I bet I'll have issues with the numbering after some work on Dev

+1

+1

+1

Multi-environment support for Lambda layers has been released in 4.29.0.

This update will only affect newly created Lambda layers.

If you want to migrate a layer:
-create a new layer with amplify add function
-copy the contents of <project-root>/amplify/backend/function/<old-layer-name>/lib/ to <project-root>/amplify/backend/function/<new-layer-name>/lib/
-update all dependent Lambda functions with amplify update function
-remove the old layer amplify remove function
-amplify push

This will only delete the layer from the project bucket because Lambda layer versions created by the CLI have a DeletePolicy set to Retain. To completely remove the old Lambda layer, delete each version from the Lambda console. We will look to improving the layer removal experience in the future.

Was this page helpful?
0 / 5 - 0 ratings