Versioning and aliases

In the real world, we often have different environments to work out of, for example development, QA, staging, pre-production, production, and so on. Having to manage a single Lambda function across all these environments can be a real pain, and also tricky especially, when each of your environments provide different configuration options, such as different connection strings for databases hosted for development and production, different roles and resource settings.

Lambda thus provides few add-on services that help you better categorize, and manage functions in the form of versions and aliases.

Versioning is a simple way to create one or more versions of your working Lambda code. Each version that you create is basically a snapshot of your origin function. Versions are also immutable which means, that each version you create from the origin or [$LATEST] branch cannot be edited or its configuration parameters change as well. Lambda assigns simple incremental version numbers (1, 2, 3, ..., n) to your versions each time they are created.

Following is a simple example depicting a function and its associated versions. Note however, that the version numbers are never reused, even if your function gets deleted or re-created:

You can create and assign your function's versions using both, the AWS Management Console as well as the CLI.

In the following scenario, I'll be reusing the calculator.js code that we published and executed from our earlier steps however feel free to try these steps on any function of your own as well.

Let us look at the AWS Management Console first:

  1. From the Lambda dashboard, select your function for which you wish to create the version.
  2. Next, from the Actions tab, select the Publish new version option.
  3. At this point, you will be publishing a new version of the code from the $LATEST version. Provide a suitable description for your new version in the Version description field and click Publish when done.
  4. Note that the function is an exact copy of our $LATEST code with the same configurations as well, however we are not able to edit this code. To go back to the $LATEST version, simply select the Version: 1 drop-down list and pick the $LATEST version as shown as follows:

You can similarly create versions using the CLI as well. With the CLI, you get two options: The first is to create the version when you first create the function itself. This can be done by using either the create-function or the update-function-code command and pass the parameter --publish along with it as shown in the following snippet:

# aws lambda create-function  
--function-name myNewFunction  
--zip-file fileb://myNewFunction.zip  
--role arn:aws:iam::001234567890:role/basic-lambda-role  
--handler index.myHandler  
--runtime nodejs4.3  
--memory-size 128  
--publish  

Alternatively, you can also publish a function's version explicitly using the publish-version command. But first, let us list out the current versions associated with our function using the list-versions-by-function command as shown:

# aws lambda list-versions-by-function  
--function-name myCalculatorFunction 

The preceding command's output can be seen in the following screenshot:

From the output, we can see that our calculator example has two versions associated with it. Each version also has its own unique ARN that you can use to invoke that particular function.

Now to publish a new version, we first need to make some change in our [$LATEST] version as Lambda will not create a newer version of your function unless, there is actually some change in it. So go ahead and either tweak some resource parameter or change some text around in your code; you can use the AWS Management Console to do the same. Make sure to save the changes performed in the [$LATEST] version and once done, type in the following command as shown:

# aws lambda publish-version  
--function-name myCalculatorFunction  
--description "A second version created by CLI" 

Once executed successfully, you should now see a new version (in this case: 2) of your code along with a new ARN of the following format:

arn:aws:lambda:[REGION]:[ACCOUNT_ID]:function:[FUNCTION_NAME]:[VERSION_NUMBER]   

However as time goes by, you would end up with a lot of different versions of a particular function. This can be problematic, especially if you are working with environments like development or production where you need to frequently change a function's versions to match the environment. That's where aliases help out. Aliases are nothing but simple pointers that point to a particular Lambda function at a given point in time. They are basically simple name-like values that get invoked by a caller and thus abstract the version value that the alias was pointing to.

For example, consider a scenario where a developer pushes some function code from the base [$LATEST] version to a new version 1. Let us assign this version 1 an alias called as DEV. When invoked, the alias DEV that points to version 1 gets invoked by the caller:

Now, the developer makes some modifications to the code from the base version again and pushes out a new version 2. Rather than updating the invoker each time a new version is created, all the developer has to do now is, remap the alias DEV from version 1 to version 2. In this way, the developer can map and unmap the alias to any current function version without changing the invoker.

Each alias that you create gets its own individual ARN as well.

Aliases can also help in simplifying event source mappings where instead of using your Lambda function's ARN, you substitute it with an alias ARN. This makes it easier for developers to work with event source mappings as now, they don't have to worry about changing the function's ARN each time they update to a newer version.

Here is an example format of an alias's ARN:

arn:aws:lambda:[REGION]:[ACCOUNT_ID]:function:[FUNCTION_NAME]:[ALIAS]   

You can create, associate, and disassociate an alias with a version anytime you want. This makes them mutable unlike versions which cannot be changed once created. Let us look at a few essential examples of working with aliases using both the AWS Management Console, as well as the AWS CLI with a simple example:

  1. First up, from the Lambda dashboard, select a particular function for which you wish to create the alias. In my case, I'll be using the same calculator code example that we used to create the two versions. From the Actions tab, select the Create alias option.
  2. In the Create a new alias dialog box, provide a suitable Name, Description, and finally, select the Version for which you wish to associate the alias. In this case, I've associated it with the $LATEST version as shown in the following screenshot:
  1. Click on Create to complete the process.

With this completed, your [$LATEST] version is now associated with the DEV alias. Let us quickly look at few commands from the CLI as well that can help us in creating and managing aliases.

First up, let us associate the version 1 of our calculator function with the alias PROD. To do so, we use the create-alias command as shown:

# aws lambda create-alias  
--function-name myCalculatorFunction  
--name PROD  
--function-version 1  
--description "PROD alias for my function" 

With your new alias created, you can list out all associated aliases to your function using the list-aliases command as shown:

# aws lambda list-aliases  
--function-name myCalculatorFunction 

You should get a similar output as shown in the following screenshot. Note the individual alias ARNs, and the function versions to which they are mapped to:

You can now substitute these ARNs for your event source mappings and go ahead with creating newer function versions as well. Let's assume you publish a new version of your code (in this case, version 2) and this new version has to be published to the PROD environment. All you need to do is update the alias PROD, and point it to the new version 2 using the update-alias command as shown:

# aws lambda update-alias  
--function-name myCalculatorFunction  
> --name PROD  
> --function-version 2 

Run the list-aliases command once again and verify the changes. Remember, all this time we have not touched the event source mapping for this function. We have only used aliases to point the new version of the function to the environment abstracting out. Simple isn't it!

With versioning and aliases done, let us quickly learn about environment variables and how you can use them with your Lambda functions.