Lamba version not created despite using PublishLambdaVersion

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

OS:
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)
AWS region: eu-west-1

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?

@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?

@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?

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}'

Wondering if this was ever proven to be an issue or not?

We've just seen something similar today, updating a parameter passed to a AWS::Serverless::Application resource, resulted in the nested stack being updated and all resource, including the $Latest version of the lambda, being updated correctly BUT a lambda version was not created (and as a result the associated alias was not updated).

The AutoPublishAlias and AutoPublishAliasAllProperties are both correctly set, so slightly confused.

@chrisclayson

Wondering if this was ever proven to be an issue or not?

We've just seen something similar today, updating a parameter passed to a AWS::Serverless::Application resource, resulted in the nested stack being updated and all resource, including the $Latest version of the lambda, being updated correctly BUT a lambda version was not created (and as a result the associated alias was not updated).

The AutoPublishAlias and AutoPublishAliasAllProperties are both correctly set, so slightly confused.

@chrisclayson - it sounds like your case is a bit different. My issue was related to layers stored in the root stack. I worked around that issue by moving and duplicating the layers in each nested stack.

Navigation Menu

Repository navigation

Lamba version not created despite using PublishLambdaVersion #3802

Description

Steps to reproduce

Observed result

Expected result

Additional environment details

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Lamba version not created despite using PublishLambdaVersion #3802

Description

Description

Steps to reproduce

Observed result

Expected result

Additional environment details

Activity

TobiasRDahl commented on Aug 16, 2025

vicheey commented on Sep 13, 2025

TobiasRDahl commented on Sep 15, 2025

chrisclayson commented on Jul 13, 2026

TobiasRDahl commented on Jul 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions