AWS Lambda provides a platform to run your code in the cloud. By letting a user deploy versions, it provides excellent audit trail for changes to Lambda code. Aliases of Lambda functions help manage environments, such as development and production, effortlessly. For more information about AWS Lambda, it’s versions and aliases, refer to this post.
SAM templates are generally used to deploy Lambda functions on AWS straight from the source code repository. However, developers often manage the versions and aliases manually using AWS CLI. However, as we shall see in this post, with slight modification, the same SAM template can be used to effectively manage your versions and aliases as well.
Traditional methods for managing versions and aliases for AWS Lambda
A typical first deployment of AWS Lambda function using SAM will deploy your code inside an AWS Lambda function, without creating any version or alias. If you login to AWS console, and navigate to your deployed function, you can see your code there (unless it is too complex to display). Your code has been deployed to $LATEST version. If you now wish to create versions or aliases, you can do so via the console, or using AWS CLI commands:
aws lambda publish-version
aws lambda publish-alias
Management of versions and aliases becomes more problematic as you further develop your code and want to redeploy it. At times, you may want to deploy and test your changes to the $LATEST version without creating a new version. In other instances, you may want to publish a new version with your changes and you may want to point your alias to the newly deployed version. Automatic management of aliases, so they automatically point to the correct version is essential for maintaining a robust CI/CD pipeline for AWS Lambda deployments.
The next section proposes one way in which you can manage versions and aliases by making slight changes to your existing SAM templates.
Why use SAM templates?
Managing your AWS Lambda versions and aliases can be automated to an extent using SAM, something that perhaps you already use for Lambda deployments. The process is semi-automated, rather than fully automated, because you still execute your SAM commands, but you won’t have to executed further commands to manage versions and aliases.
The specific advantage of using SAM lies with the ability to create a logic so that an alias can point to a specific version dynamically. E.g. you can have a ‘prod’ alias point to the latest published version, whereas an alias ‘dev’ could point to $LATEST version. Achieving this using a traditional approach will require an additional step to find out the last published numbered version and then manually adjusting the alias.
Sample SAM template for managing versions and aliases
Here’s a simplified YAML-based SAM template illustrating how to manage AWS Lambda versions and aliases. You can also down this template from our GitHub repoository here.
This code deploys a Lambda version, and creates two aliases, ‘dev’ and ‘prod”. The ‘dev’ alias points to $LATEST always, but ‘prod’ alias points to the latest numbered version. Additionally, you can control whether to publish a new numbered version, or just to change the code currently held in $LATEST using the parameter ‘CreateNewVersion’. If this is set to ‘true’ a new version is created and ‘prod’ alias is automatically set to point to this new version.
Code sample (YAML)
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Parameters:
FunctionName:
Type: String
Default: MyLambdaFunction
CreateNewVersion:
Type: String
Default: 'true'
AllowedValues:
- 'true'
- 'false'
ProdAliasVersion:
Type: String
Default: '$LATEST'
Conditions:
ShouldCreateNewVersion: !Equals
- !Ref CreateNewVersion
- 'true'
Resources:
MyLambdaFunction:
Type: 'AWS::Serverless::Function'
Properties:
FunctionName: !Ref FunctionName
Handler: index.handler
Runtime: nodejs14.x
CodeUri: src/
MemorySize: 128
Timeout: 10
Policies:
- AWSLambdaBasicExecutionRole
LambdaVersion:
Type: AWS::Lambda::Version
Condition: ShouldCreateNewVersion
Properties:
FunctionName: !Ref MyLambdaFunction
ProdAlias:
Type: AWS::Lambda::Alias
DependsOn: LambdaVersion
Properties:
FunctionName: !Ref MyLambdaFunction
FunctionVersion: !If
- ShouldCreateNewVersion
- !GetAtt LambdaVersion.Version
- !Ref ProdAliasVersion
Name: prod
DevAlias:
Type: AWS::Lambda::Alias
Properties:
FunctionName: !Ref MyLambdaFunction
FunctionVersion: '$LATEST'
Name: dev
Explanation
Parameters:
- FunctionName: The name of the Lambda function.
- CreateNewVersion: A flag to determine if a new version should be created.
- ProdAliasVersion: Specifies the version for the production alias.
Conditions:
- ShouldCreateNewVersion: Checks if a new version should be created.
Resources:
- MyLambdaFunction: Defines the Lambda function.
- LambdaVersion: Creates a new Lambda version if the ShouldCreateNewVersion condition is true.
- ProdAlias: Points to the newly created version or a specified version for production.
- DevAlias: Points to the latest version ($LATEST) for development.
Other possible AWS Lambda environment configurations
The sample code above provides a simplified example where there are just two environments – dev and prod, each represented by an alias pointing to a specific version. But you might also have a staging environment, and you might want another ‘stage’ alias to point to the latest published version, and ‘prod’ to point to the second most recent numbered version. Unfortunately, standard YAML-based SAM templates are limited in how much logic you can implement within the code. For building in more advanced logic, you need to use Cloud Development Kit (or CDK). CDK is used to deploy infrastructure in the same way as standard SAM templates, but with the coding capabilities of a programming language.
