AWS Lambda Versions and Aliases

AWS Lambda lets you run code without provisioning or managing servers. You are charged based on the time and resources consumed by your code when it runs – there is no charge when your code is not running. All of this makes AWS Lambda very easy to jump straight into your business logic and not worry about the infrastructure setup. But since this is a “server less architecture”, code deployments for your various stages is a bit different than what you are used to. Let’s look at how to manage staging with the help of Lambda Versions and Aliases.

AWS Lambda Versions –

AWS Lambda can store multiple copies of your code with its Versions. Whenever code is updated, you can publish a new version which will hold this latest code. Older version can maintain the previous code you had saved to the Lambda. You can publish versions via AWS console or via AWS command line interface/SDK. With this you can have a code updating script that can push the new code to lambda and publish a new version based on it.

Here is a look at Versions of a sample lambda function.

Now you have multiple versions of your code, all at various stages of your product life but how do they interact with various product stages you have?

AWS Lambda Aliases –

Aliases are pointers which point to lambda functions. Specifically, any version of that function. So, you can have various Aliases such as development, test, UAT and production. These aliases can then point to various lambda versions so you can have development alias pointing to the latest version while test alias points to version 4 and production alias points to a stable version 2. You can create aliases via AWS console or via AWS command line interface/SDK. So now the code updating script can not only update code and publish versions, but also modify aliases to point to a different version if and when necessary.

Here is a look at Aliases of a sample lambda function.

But what about my environment specific configurations you ask?

Environment Variables –

You can define Environment Variables as key-value pairs that are accessible from your function code. These could be environment specific values such as API keys, database table names etc. With the help of these you can put any environment specific details in environment variables and keep your code unchanged as you traverse your product stage cycle.
You can also use AWS Key Management Service to create encryption keys for your environment variables. This could be very useful in storing sensitive information such as third-party API keys. The encrypted environment variables are then decrypted automatically by AWS Lambda when the function is invoked. Along with AWS Role Management you can use this to restrict access to this sensitive information to a select group of users.

Here is a look at encrypted and unencrypted environment variables in a sample lambda function.

All of this sounds great but with so many versions and aliases; how do I invoke my lambda function?
Aliases are treated exactly like they are lambda functions themselves. So, once you set up your aliases for various product stages such as dev/test/prod, you can expose the ARN of alias to the service invoking your lambda function such as API Gateway, iOS/android application using the AWS SDK etc. These services do not need to worry about the lambda versions at all. Production build of your applications will always invoke production alias of your lambda. With version management you decide which code your production alias will run. What this also means is that in case of failure you have the easy option of switching to a previous stable build by simply lowering the version number for you alias.
Hope this little intro to AWS Lambda Versions and Aliases was useful. For any comments/suggestions/questions you can find me at –
EMAIL – vishal.palasgaonkar@talentica.com
Skype – vishal.palasgaonkar_tal