Lambda functions are a very useful input for AWS computing services. Since they are essentially only a function in the cloud, tracking different versions and deploying updates is essential to work effectively with them.
$ LATEST Tracks The most recent updates
Whenever you make a change to a Lambda function, the changes are automatically reflected in a version called $ LATEST. It tracks the most recent updates and is the default version of most Lambda functions. Changes to the Lambda edit page, the Cloud9 IDE and the zip download from the CLI update this version.
For this reason, the $ LATEST version should not be used in production, since any update of the function to test new features will affect your production traffic. In addition, there is no easy way to deploy updates over time with CodeDeploy if you are using $ LATEST.
Instead, we recommend that you create new versions for each version, and a “production” alias that points to it. $ LATEST can be used for development, with its own alias also pointing to it.
Add a new version (and transfer traffic to it)
Working with versions is quite simple. Of Lambda management console, select your function and click on the “Version:” drop-down menu. This will allow you to switch between versions and view the versions currently in use.
To publish a new version, you must switch to the $ LATEST version and click on “Publish a new version” in the “Actions” drop-down list.
The new versions are rather designated in an archaic way by an incremented integer, with no way of using the standard format major.minor.patch used for most software versions. If you really need this format, we recommend that you use CodePipeline with SAM deployments and track your Lambda versions on Git.
This new version can be used in other services, such as 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 need to create an alias, which points to a particular version number, and can be set as the endpoint for API Gateway. That way, every time you release a new version, you only need to update the alias to toggle everything.
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 move traffic to a new version. Although you can configure it manually, it is mainly used for CodeDeploy deployments, where new versions of your functions can be deployed gradually, for example, 10% every five minutes or so. This way you can spot errors early and cancel the versions before they affect everyone.
SAM deployments automatically add new versions
Creating versions manually is useful, but if you manage many features, you will likely use SAM deployments instead. Lambda functions deployed using SAM models will automatically add a new version (and update $ LATEST).
Combined with Git for version control and AWS ‘CodePipeline CI / CD service, this makes it easier to manage versions of Lambda functions. Whenever a change is pushed to the publishing branch in your source code control, CodePipeline will fire automatically and update your functions. If you are working with a language that must be compiled (or transpiled in the case of TypeScript), you can also send your function code to CodeBuild to also manage this step.
SAM deployment is an extension of CloudFormation, so any deployment using SAM will create a new CloudFormation stack. Whenever updates are sent, CloudFormation recognizes that this is a stack update, rather than a new stack, and will replace the current feature version with the update.