Lambda Qualifiers

Lambda Qualifiers

Lambda qualifiers allow you to publish multiple versions of your Lambda function and allow for naming of versions with aliases. A good use for this is to seperate Lambda functions into multiple environments. For example, I would like to have a Dev version of my function running that I can push code to test as I develop, without interrupting any production or testing websites. I would also like to have a QA or Staging environment to send out updates to a QA team, and finally a Prod version, that is hands off production. I can achieve all of this with versions and aliases.

Versioning and $LATEST

By default all Lambda functions have a $LATEST version, which is what version of the code the function will run by default, and if no other versions or aliases are defined. While this an easy way to get started and to run serverless code, reliably running code from $LATEST as your commits grow becomes impossible, and we are unable to achieve the Dev/QA/Prod environments mentioned earlier. So the first thing we do is create a version of our code. Under the Actions button, select Publish new version, give your version a descrption, and click Publish

Now we will have a "locked-in" version of our code, that is published as version 1. Note: Lambda auto increments the version number for us.

Create an Alias

Now that we have version 1 of our code running, we can create an alias that points to this version, so we essentially have a named version. Add an alias by selecting Actions -> Create alias to create a new alias for your function. For this example we will create a Dev alias, that points to our version 1 of the function. We can also give our alias a description. Additionally you can shift traffic between two versions of our function with aliases, but that is not beyond the scope of this article.

Repeating the same process we can create a QA and a Prod alias, each pointing to version 1 of the function.

Deploying a new Version

With all of our aliases in place we can now deploy a new version and set our aliases accordingly and begin to work in the appropriate environment. Initially with our setup all three aliases will be pointing to the same function version. Now a developer wants to make changes to the function. By either uploading new function code, or modifying the code directly in the function dashboard, the developer makes their changes and saves the function. Because they have saved new code to the function, this latest save will be stored in $LATEST. After checking that this code passes our review, we would like to push this out QA. First we deploy a new version, and then we update our alias of QA to point to this new version.

Function Changes

Its worth mentioning here that changes to a functions settings, such as environment variables, memory size, etc. DO NOT reflect on versions. Essentially these changes are only made at the function level with $LATEST. To have these function settings take effect on your version you must deploy a new version of the function.

$LATEST Revisited

At this point you might be wondering why the need for both Dev and $LATEST? In my experience we've used Dev as an integration point with all things AWS as well as other developers code. This Dev alias should be somewhat functional, i.e. no syntax errors, but it doesn't have to be perfect, as we are testing in the cloud. If you do not need an integration point or a way to collaborate with other developers, using $LATEST is perfectly fine to use as a dev environment before pushing to QA.

Conclusion

So to recap at the end of this article we have $LATEST, which is the latest updates from the developer. We also have version 2 of the code, or QA as we've aliased it, and finally version 1 of the code, that our Prod alias points too, untouched during the QA process. We can continue this pattern, rolling out updates to Dev, publishing to QA, and then to Prod, all while keeping our environments isolated in Lambda.

You can use this versioning pattern to manage all aspects of versioning your Lambda code. Some additional features not mentioned in this article include custom logging for versions and A/B deployments. Happy versioning!