Lamba version not created despite using PublishLambdaVersion

[TobiasRDahl]

Description

I am trying to implement SnapStart on two of my lambdas. It works well, until we deployed with only changes in the layers - then a new lambda version was not created.
I came across the possibility to set PublishLambdaVersion = true on the AWS::Serverless::LayerVersion resource.
The bug is that a new lambda version is not created, despite the layer version being bumped up.

In our rootstack we have two layers defined which are used by several nested stacks.
It is only 2 out of many lambdas in which we want to use SnapStart and thereby have the need for new lambda versions being created when a layer is updated.

Steps to reproduce

Rootstack:

  CommonLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: CommonLayer
      Description: Common layer
      ContentUri: ../lambdas/layers/common
      RetentionPolicy: Delete
      PublishLambdaVersion: True

  RdsSchemaLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: RdsSchemaLayer
      Description: RDS SQLAlchemy layer with defined schemas
      ContentUri: ../lambdas/layers/rds_schema
      RetentionPolicy: Delete
      PublishLambdaVersion: True

We then have several nested stacks defined in the rootstack, fx:

  ExampleApi:
    Type: AWS::Serverless::Application
    Properties:
      Location: './example_api.yaml'
      Parameters:
        EnvPipeline: !Ref EnvPipeline
        CommonLayer: !Ref CommonLayer
        RdsSchemaLayer: !Ref RdsSchemaLayer

Inside example_api.yaml, we have the lambda defined:

  ExampleApiLambda:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      FunctionName: ExampleApiLambdaFastApi
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: SnapStart
      AutoPublishAliasAllProperties: true
      Handler: lambda_entry_point.handler
      CodeUri: ../lambdas/example_api/
      Description: "Example API lambda that runs FastAPI app"
      MemorySize: 1024
      Timeout: 29
      Role: !Ref ExampleApiLambdaRole
      Events:
        ExampleApiEvent:
          Type: Api
          Properties:
            RestApiId: !Ref ExamplePlatformApiV1
            Path: /v1/example/example
            Method: POST
        ...
      Layers:
        - !Ref CommonLayer
        - !Ref RdsSchemaLayer
      Environment:
        Variables:
          ....
      VpcConfig:
        SecurityGroupIds:
          - !Ref RdsLambdaSecurityGroup
        SubnetIds:
          - !Ref subnet1Id
          - !Ref subnet2Id
          - !Ref subnet3Id

I first deployed the stack with the above configuration.
I then made a simple change in the RdsSchemaLayer and deployed again.

Observed result

I observe that the RdsSchemaLayer has version 624

On the lambda, no new version is created:

Version 37 (latest lambda version) is still pointing at RdsSchemaLayer version 623:

Expected result

I expect that a new lambda version is created using RdsSchemaLayer version 624.

Additional environment details

1. OS:
2. If using the SAM CLI, sam --version: AWS SAM CLI 1.142.1 (deploying with Github runner https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md)
3. AWS region: eu-west-1

[TobiasRDahl]

I just tried moving the layers to example_api.yaml, and then it works as expected.
Is it still expected behavior that it does not work when defining the layers in the root stack?

[vicheey]

Hi @TobiasRDahl,

It sounds like the deployment of the root stack that contains your updated layers does not trigger new deployment of the nested stacks (contains Lambda functions). The next deployment of your nested stack of should trigger a function version to be published, during which the new function versions should refer the newer version of the layer.

Do you mind confirming that this is actually the case?
How do you build and deploy these stacks?

[TobiasRDahl]

Hi @TobiasRDahl,

It sounds like the deployment of the root stack that contains your updated layers does not trigger new deployment of the nested stacks (contains Lambda functions). The next deployment of your nested stack of should trigger a function version to be published, during which the new function versions should refer the newer version of the layer.

Do you mind confirming that this is actually the case? How do you build and deploy these stacks?

Hi @vicheey

Yes, that seems indeed to be the case.

We build and deploy from a Github Actions workflow:

    - name: Deploy
      run: |
        echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin
        cd iac/
        make deploy

Makefile:

SHELL := /bin/bash
.PHONY: diff_cdf_template deploy deploy_serverless_dependencies

init:
	@if [[ -z "${TEMPLATE_FILE}" || -z "${STACK_NAME}" || -z "${REGION}" || -z "${ENV}" ]]; then \
		echo 'One or more variables are undefined!' ; \
		exit 1; \
    fi

diff_cdf_template: init
	sam deploy \
		--no-execute-changeset \
		--no-fail-on-empty-changeset \
		--stack-name ${STACK_NAME} \
		--region ${REGION} \
		--resolve-s3 \
		--resolve-image-repos \
		--capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \
		--parameter-overrides 'EnvPipeline=${ENV} \
	                          AmmaBackendApiId=${AMMA_BACKEND_API_ID} \
	                          AmmaFrontendApiId=${AMMA_FRONTEND_API_ID} \
							  AuroraMasterSecretArn=${RDS_MASTER_SECRET_ARN}'

deploy: init
	sam build \
		--debug \
		--parallel \
		--template-file ${TEMPLATE_FILE} && \
	sam deploy \
		--no-fail-on-empty-changeset \
		--stack-name ${STACK_NAME} \
		--region ${REGION} \
		--resolve-s3 \
		--resolve-image-repos \
		--capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \
		--parameter-overrides 'EnvPipeline=${ENV} \
	                          AmmaBackendApiId=${AMMA_BACKEND_API_ID} \
	                          AmmaFrontendApiId=${AMMA_FRONTEND_API_ID} \
							  AuroraMasterSecretArn=${RDS_MASTER_SECRET_ARN}'