Strategies to Manage AWS Lambda Versions

Read more below.

Strategies to Manage AWS Lambda Versions

4 min read · Ryan Jones

When it comes to creating AWS Lambda functions there is a concept called, versioning. What versioning does is allow you to have a single lambda function with different code in each version. Every version can be invoked the same way your normal AWS Lambda function can be invoked, except you add the version number to the end. The most up to date version can also be referred to as $LATEST. However, adding $LATEST is not required to invoke the latest version of your Lambda function.

$Latest (Current, most up to date):

arn:aws:lambda:us-west-2:123456789012:function:my-awesome-function
arn:aws:lambda:us-west-2:123456789012:function:my-awesome-function:$LATEST

Version 1:

arn:aws:lambda:us-west-2:123456789012:function:my-awesome-function:1

Versions can grow out of control quickly if you’re not paying attention. Frameworks such as the Serverless Framework version each function when you deploy by default. The Serverless Framework makes it easy to deploy new code easily, but also allows you to wrack up numerous redundant versions easily as well.

The Serverless Framework pushed for a new feature to be introduced a while ago which would allow you to turn off the versioning for your deployments. This solved the problem of having 50+ versions of the same Lambda function. However, only for future deployments. Existing versions will still exist.

# serverless.yml
service: myService
provider:
  name: aws
  ...
  versionFunctions: false # optional, default is true

As you can see the option versionFunctions defaults to true. By adding this line to each of your projects you can turn off versioning completely. However, having multiple versions of your Lambda is not always a bad thing. It’s actually a great feature if you keep the number of versions under control.

Serverless Plugin Canary Deployments:

By having multiple versions of your Lambda functions you can do canary deploys and easily rollback to previous versions. However, if you don’t have a custom solution already built there is a Serverless Framework plugin called, Serverless Plugin Canary Deployments. This plugin allows you to automatically handle shifting live traffic between new versions of your code gradually. You can even limit the stage where you want this to take place (e.g. only prod).

Serverless Prune Plugin:

For proactively managing Lambda versions and maintaining only a certain number of versions which you can specify. There is a Serverless Framework plugin called, Serverless Prune Plugin. This plugin enables you to be proactive about versions, but not remove the ability to version all together. Below, is a description of the plugin from the creators/contributors.

“Following deployment, the Serverless Framework does not purge previous versions of functions from AWS, so the number of deployed versions can grow out of hand rather quickly. This plugin allows pruning of all but the most recent version(s) of managed functions from AWS.”

Here is a snippet from the Serverless Prune Plugin documentation for handling automatic pruning of old versions. This will keep the last 3 versions and prune everything else.

custom:
  prune:
    automatic: true
    number: 3
The plugin also allows you to manually prune old versions for a single lambda function by running the following command.
sls prune -n <number of version to keep> -f helloWorld

Or you can prune versions from a specific region/stage. By running the following command.

sls prune -n <number of version to keep> --stage production --region eu-central-1

Janitor Lamba:

Let’s assume that you’re not using the Serverless Framework, but still need to prune old versions. Yan Cui, faced this issue at his company, Yubl.

“At Yubl, me and a small team of 6 server engineers managed to rack up nearly 20GB of deployment packages in 3 months.”

After, realizing this. Yan Cui, developed a solution to purge old versions of your lambda versions across your entire account called, Janitor Lambda. The entire thing can be summed up as, a “cron job + Lambda function to clean up old, unreferenced versions of Lambda functions from your AWS environment.”

Yan Cui, described the result of running Janitor Lambda in his article, here. “After we employed this Janitor Lambda function, our total deployment package went from 20GB to ~1GB (we had a lot of functions…).”

Awesome! There is a bunch of different strategies to help you be proactive when it comes to managing versions. Let’s review each ones use case, below.

Use Cases:

Serverless versionFunctions - Turn off all function versioning for Lambda deployments for workloads managed by the Serverless Framework.

Janitor Lambda - Bulk version removal across ALL Lambda functions in your account. Great for handling workloads not using the Serverless Framework.

Serverless Prune Plugin - Proactive version control and version removal for workloads managed by the Serverless Framework.

Serverless Canary Deployment Plugin - Traffic shifting, canary releases, and CICD for serverless workloads managed by the Serverless Framework.

Thanks for reading! @github/mode2cloud

About Mode2

Mode2 LLC (www.mode2.com) is a digital transformation services partner, helping companies address the challenges of seeking a competitive advantage, embracing disruptive technologies and managing organization change. Mode2 has a team of experts who create new leab cloud-native solutions without compromising security. Mode2 is headquartered in Los Angeles CA, with locations in San Francisco & Bay Area, Portland OR and New York City, is a specialist cloud partner offering services across the United States.