Versions and Aliases - Serverless Architectures with AWS Lambda

Versions and Aliases

There are times where you might need to reference or revert your Lambda function back to code that was previously deployed. Lambda lets you version your AWS Lambda functions. Each and every Lambda function has a default version built in: $LATEST. You can address the most recent code that has been uploaded to your Lambda function through the $LATEST version. You can take a snapshot of the code that’s currently referred to by $LATEST and create a numbered version through the PublishVersion API. Also, when updating your function code through the UpdateFunctionCode API, there is an optional Boolean parameter, publish. By setting publish: true in your request, Lambda will create a new Lambda function version, incremented from the last published version.

You can invoke each version of your Lambda function independently, at any time. Each version has its own Amazon Resource Name (ARN), referenced like this:


When calling the Invoke API or creating an event source for your Lambda function, you can also specify a specific version of the Lambda function to be executed. If you don’t provide a version number, or use the ARN that doesn’t contain the version number, $LATEST is invoked by default.

It’s important to know that a Lambda function container is specific to a particular version of your function. So, for example, if there are already several function containers deployed and available in the Lambda runtime environment for version 5 of the function, version 6 of the same function will not be able to execute on top of the existing version 5 containers—a different set of containers will be installed and managed for each function version.

Invoking your Lambda functions by their version numbers can be useful during testing and operational activities. However, we don’t recommend having your Lambda function be triggered by a specific version number for real application traffic. Doing so would require you to update all of the triggers and clients invoking your Lambda function to point at a new function version each time you wanted to update your code. Lambda aliases should be used here, instead. A function alias allows you to invoke and point event sources to a specific Lambda function version.

However, you can update what version that alias refers to at any time. For example, your event sources and clients that are invoking version number 5 through the alias live may cut over to version number 6 of your function as soon as you update the live alias to instead point at version number 6. Each alias can be referred to within the ARN, similar to when referring to a function version number:


An alias is simply a pointer to a specific version number. This means that if you have multiple different aliases pointed to the same Lambda function version at once, requests to each alias are executed on top of the same set of installed function containers. This is important to understand so that you don’t mistakenly point multiple aliases at the same function version number, if requests for each alias are intended to be processed separately.

Here are some example suggestions for Lambda aliases and how you might use them:

  • live/prod/active – This could represent the Lambda function version that your production triggers or that clients are integrating with.

  • blue/green – Enable the blue/green deployment pattern through use of aliases.

  • debug – If you’ve created a testing stack to debug your applications, it can integrate with an alias like this when you need to perform a deeper analysis.

Creating a good, documented strategy for your use of function aliases enables you to have sophisticated serverless deployment and operations practices.