Lambda functions are a very useful entry to AWS’s compute services. Since they’re basically just a function in the cloud, tracking different versions and rolling out updates is crucial to working with them effectively.
$LATEST Tracks The Most Recent Updates
Anytime you make a change to a Lambda function, changes are automatically reflected in a version called $LATEST. This tracks the most recent updates, and is the default version for most Lambda functions. Changes from the Lambda edit page, Cloud9 IDE, and zip uploading from the CLI all update this version.
Because of this, the $LATEST version should not be used in production, as any updates to the function to test new features will affect your production traffic. Plus, there’s no easy way to roll out updates over time with CodeDeploy if you use $LATEST.
Instead, we recommend creating new versions for each release, and a “production” alias that points to it. $LATEST can be used for development, with its own alias pointing to it as well.
Adding a New Version (And Shifting Traffic To It)
Working with versions is pretty easy. From the Lambda Management Console, select your function, and click on the “Version:” dropdown. This will allow you to switch between versions, and view the versions currently in use.
To publish a new version, you’ll need to switch to the $LATEST version, and click “Publish new version” from the “Actions” dropdown.
New versions are rather archaically denoted by an incrementing integer, with no way to use the standard major.minor.patch format used for most software releases. If you really need this format, we recommend you use CodePipeline with SAM deployments, and track your Lambda versions on Git.
This new version can be used in other services, like API Gateway. However, you don’t want to have to update every service that uses your Lambda function every time the function itself is updated. Instead, you should create an Alias, which points to a particular version number, and can be set as the endpoint for API Gateway. This way, whenever you publish a new version, you’ll simply need to update the alias to switch everything over.
You can create aliases from the same “Actions” menu. Give it a name, such as “Production,” and select a version to point to.
Aliases can also gradually shift traffic over to a new version. While you can manually set this up, it’s mostly used for CodeDeploy deployments, where new versions of your functions can be deployed gradually, e.g., 10% every five minutes or so. This way, you can catch errors early and rollback releases before they affect everybody.
SAM Deployments Automatically Add New Versions
Creating versions manually is useful, but if you’re managing a lot of functions, you’ll probably be using SAM deployments instead. Lambda functions deployed using SAM templates will automatically add a new version (and update $LATEST).
Combined with Git for version control, and AWS’s CodePipeline CI/CD service, this makes version management for Lambda functions much easier. Whenever a change is pushed to the release branch in your source control, CodePipeline will trigger automatically and update your functions. If you’re working with a language that needs compiling (or transpiling in the case of TypeScript), you can also send your function code to CodeBuild to handle that stage as well.
SAM deployment is an extension of CloudFormation, so any deployments made using SAM will create a new CloudFormation stack. Whenever updates are pushed, CloudFormation recognizes that it’s a stack update, rather than a new stack, and will replace the current function version with the updated one.
