Release Management For AWS Lambda Function With API Gateway
In any predominant software organization, code will normally be deployed in three environments – Development, QA and Production. Problems with such multiple environments arise when we work with Lambda functions, while implementing changes only to a single environment without affecting others.
In order to overcome this problem, we use AWS Lambda Versioning and Aliases. With AWS Lambda Versioning, we can publish more than one version of our Lambda function and deploy these in the above mentioned environments.
We can then create aliases for each of the versions that we create for our lambda function. So, an alias is a reference to a specific Lambda function version.
Consider a single Lambda function behind AWS API Gateway. The API gateway has 3 different stages deployed named as DEV, QA and PROD. By calling these stages we will see a different Lambda function response from a single Lambda function respectively.
We have to perform the following:
- Create Versions and Aliases in Lambda Function
- Create Dynamic Resources in API Gateway
- Create the Authorization in API Gateway for Authorizer Lambda
- Enable the CORS in API Gateway for proxy-lambda
- Create Deployment Stages and Variables in API Gateway
- Test the API
The following diagram gives an overview of our example
Versioning and Aliases in AWS Lambda Function
The versioning and aliases are among the most important features of Lambda function. When we use versioning in AWS Lambda, we can publish one or more versions of our Lambda function. A key point to all of this is that each version of our Lambda function has its own ARN, and most importantly, a published version of our Lambda function is immutable. There is one readily available version of our Lambda function that we can change and it is named Version $LATEST.
We can then create aliases for each of the versions that we create for our Lambda function. An alias is therefore a reference to a specific Lambda function version. Each alias also has a unique ARN. One key difference between aliases and functions is that we can change aliases to point to different versions of our functions.
In the below representation, Fig.1 shows an example of how to use Lambda function versions and aliases. Each alias corresponds to a different environment (Production, UITest and Integration test) that is using a specific version of an AWS Lambda function. Fig.2 is an example which explains how to update Lambda function aliases when moving a new version into Production and a new version for UITest.
- Faster development and easier deployment
- Maintain all stages (DEV, QA and PROD) of code in single lambda function
- Easier operational management
- Reduction in operational costs
- No servers to manage
- Versions are immutable
- Execution duration is long
- Startup latency
Custom authorization and CORS proxy lambda setup in API Gateway
The following diagram gives an overall request and response flow in API Gateway.
AWS API Gateway is a brilliant and fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. We can use it for building serverless applications, integrating with legacy applications and for proxying HTTP requests directly to other AWS services. It also acts as a HTTP front-end.
Custom Lambda authorizer
An API Authorizer is a Lambda function that performs authentication and authorization on requests prior to AWS API Gateway execution. The Lambda either permits or blocks the API requests that contain a particular authorization token by returning an IAM policy. The returning IAM policy is then cached by the API gateway so it can be later reused for up to 1 hour.
- We can have our authentication mechanism the way we want it
- Ultimate control over authentication and authorization
- We can have the UI call the APIs with a standard token (JWT) and the flow for developers remains the same – no extra consideration of AWS SDK
- A lot of effort and thinking is necessary to build authentication
- Chances of missing out on some crucial aspects
CORS Proxy Lambda
Cross-Origin Resource Sharing (CORS) is a security feature provided by the browser which restricts cross-origin HTTP requests that are initiated by running scripts in the browser. To make our REST APIs handle these cross-origin requests, we must enable CORS support.
- Security – Allows restricted domains
- Easy setup as we don’t want to setup any settings in API Gateway
- Everything rests in the code
- Headers, status codes and messages are hidden in the source code
Thus, by using AWSome services of API Gateway and Lambda, we can develop and deploy robust serverless applications and provide security as well as authorization and authentication.
- GitHub URLs for sample code of Authorization and CORS Proxy lambdas code:
- AWS Lambda Function Versioning and Aliases from AWS docs:
Contact for further details
Prabhakar Reddy NAGURU
Sr. Software Engineer – Cloud Application Development