Introduction

AWS Lambda is a powerful serverless compute service that allows developers to run code without provisioning or managing servers. However, as with any complex system, there are nuances in its behavior that can sometimes lead to unexpected results. In this post, we'll explore a specific issue related to Lambda layers, versioning, and aliases, and dive deep into why it occurs and how to address it.

The Problem: Layer Updates Not Reflected in Lambda Functions

Many developers have encountered a perplexing issue: after updating a Lambda layer and deploying it using the AWS Serverless Application Model (SAM) CLI, the changes are not reflected in the Lambda functions that use this layer. This problem is particularly prevalent when working with Lambda functions that use auto-published aliases and provisioned concurrency.

Symptoms

1. A new version of a layer is published and deployed.
2. The Lambda function configuration shows the new layer version.
3. However, the function continues to execute with the old layer code.

Understanding Lambda Configuration vs. Function Code

To grasp why this issue occurs, we need to understand a fundamental distinction in AWS Lambda: the difference between a function's configuration and its code.

Lambda Configuration

• Includes settings like memory allocation, timeout, environment variables, IAM role, VPC settings, and layers.
• Can be updated without necessarily creating a new function version.
• Changes are immediately reflected in the $LATEST version.

Function Code

• The actual code that runs when the Lambda function is invoked.
• Changes to the code typically trigger the creation of a new function version.

Versioning Behavior

• By default, only code changes automatically create new numbered versions.
• Configuration changes update $LATEST but don't automatically create new versions.