Skip to content

Jesses Software Engineering Blog

Jul 11

Jesse

AWS Lambda Versions and Aliases

Lambda is a great tool for micro service architectures. They are easy to configure, scale well, and have a pay for what you use model. As the services scale out it becomes important to establish development workflows that provide easy deployments and roll backs for production code. AWS Lambda versions and aliases provide configurations for managing deployment pipelines.

The workflow is to add explicit new versions for Lambda after each new deployment, and use aliases as pointers to the different versions. This will allow us to point different resources, in this case API Gateway stages, to different versions of Lambdas. This will allow for dev, prod stages to point to different Lambda versions via aliases, and deployments can be quickly rolled back by repointing the alias.

Creating Versions and Aliases

CLI reference

Run a Lambda deployment:

aws lambda update-function-code --function-name <FUNCTION-NAME> --zip-file  fileb://artifact.zip --region us-east-1

Explicitly create a new version:

aws lambda publish-version --function-name <FUNCTION-NAME> --description <DESCRIPTION> --region us-east-1 --output=text --query 'Version'

An alias must be created prior to being used, and pointed at an existing Lambda version:

aws lambda create-alias --function-name <FUNCTION-NAME> --name <ALIAS> --region us-east-1 --function-version \$LATEST

And point an alias to that version, where VERSION is the response from the above command:

aws lambda update-alias --function-name <FUNCTION-NAME> --name <ALIAS> --function-version <VERSION> --region us-east-1

A complete example:

aws lambda update-function-code --function-name lambda-function-name --zip-file fileb://artifact.zip --region us-east-1

version=$(aws lambda publish-version --function-name lambda-function-name --description $(date +%Y-%m-%d-%H-%M) --region us-east-1 --output=text --query 'Version') && aws lambda update-alias --function-name lambda-function-name --name PROD --function-version $version --region us-east-1

Aliases can be repointed to different versions for rollbacks:

aws lambda update-alias --function-name lambda-function-name --name PROD --function-version 2 --region us-east-1

NOTE: You cannot name the versions, so having descriptions are useful i.e. using a timestamp or commit message. Also versions will only update if the code has changed, so calling publish-version multiple times on the same code will not result in a version update.

API Gateway Configuration

API Gateway stages can be used so that API changes, routes, mappings, etc, can be launched into different versions (/v1, /v2, etc.). Each stage has the ability to add stage specific env vars which are passed through to API routes via HTTP headers. Using the stage environment variables we can map the API Gateway stages to the Lambda aliases.

To configure the routes to use the environment vars, configure the Integration Request -> Lambda Function (where ENV is the variable name):

<lambda-function-name>:${stageVariables.ENV}

Note that when using wildcard or variable Lambda aliases, permissions will need to be manually added to the Lambda so that the routes can access the aliases (run for each possible alias).

aws lambda add-permission --function-name arn:aws:lambda:us-east-1:2987525232423:function:lambda-function-name:PROD --source-arn 'arn:aws:execute-api:us-east-1:2987525232423:6uzlev733d/*/GET/route' --principal apigateway.amazonaws.com --statement-id fd997104-9ac1-49fd-afdb-519a26a0c084 --action lambda:InvokeFunction

Last step is to configure the API Gateway stage with the correct environment var for that stage. For example, the /v1 var may be, ENV = PROD.

Blog Powered By Wordpress