Managing In-Production AWS Lambda Functions With API Gateway

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. With Lambda, you can run code for virtually any type of application or backend service — just set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.

Amazon API Gateway is a fully managed service that allows you to create, publish, maintain, monitor, and secure APIs at any scale. With API Gateway you can create an API that acts as a “front door” for AWS Lambda functions.

Together AWS Lambda and API Gateway are commonly used in N-Tier architecture applications, for example, the front end UI developed in Angular, ReactJS or Vu.js and calls API gateway endpoints which eventually triggers Lambda functions.

The benefits of using N-Tier architecture is that you don’t have to manage any servers or EC2 instances, you can deploy your app on AWS S3 and rest is taking care by AWS API gateway and AWS Lambda as shown in the slide.

Another benefit is to debug or deployment of new features is relatively easier as compared to other architectures.

Problem

The problem or challenge is when working in multiple environments with Lambda functions. Typically, organizations have Development, QA and Production environments. So how would you implement new features or changes to your existing Lambda functions without impacting when one function is currently running in Production or QA?

One solution could be to have different AWS accounts but that also add some administrative overhead.

Solution

To solve the above problem AWS Lambda Versioning and Aliases comes into action. Using versioning in AWS Lambda, you can publish one or more versions of your Lambda function and work with different variations of your function in your development workflow, such as Development, QA or Production.

AWS Lambda also supports creating aliases for each of your Lambda function versions. Conceptually, an AWS Lambda alias is a pointer to a specific Lambda function version.

To learn more about AWS Lambda versioning and aliases, check out the AWS documentation.

In our example, we have a single AWS Lambda function behind AWS API Gateway. The API gateway has 2 different stages deployed named as DEV and PROD. By calling these stages you will see a different Lambda function response from a single Lambda function respectively.

This will allow us to test the API and Lambda function in DEV environment independently of Production API.

We have to do the following:

1. Create Versions and Aliases in AWS Lambda Function
2. Create Dynamic Resources in AWS API Gateway
3. Create Deployment Stages and Variables in AWS API Gateway
4. Test the API

To summarize, when you call the DEV staged API endpoint the function would “Hello from Lambda World” and in case of PROD endpoint the function would return “Hello from Lambda”

The following slide gives an overview of our example:

Versioning and Aliases in AWS Lambda Function

As shown in the slide, we have 2 different versions names 1 and 2respectively of the same lambda function called hello-lambda.

You can create a new version of lambda function by clicking Publish New Version.

Following is the version 1 we will be using for our PROD API

The following is the version 2 we will use for our DEV API:

Similarly, you can create aliases by clicking Aliases. In our case, we have dev and prod aliases defined, which point to version2 and version1 as shown in the slide:

Dynamic Resources in AWS API Gateway

Once we have versions and aliases defined, you can call your Lambda function using the following method:

mylamda-function:my-alias

e.g. hello-lambda:prod or hello-lambda:dev

In order to make it efficient, we need to pass the aliases dynamically so in case of any change our APIs aren’t impacted.

You can do this using Stage Variables in AWS API Gateway, in our case we are passing the alias to Lambda function value by ${stageVariables.env}. On runtime, AWS API gateway would replace the value of the “env” with the value we define.

Note: When defining Stage Variable in the resources you need to add permissions to use stage variables. API gateway would prompt you to run the following command:

You need to run this command on AWS CLI with a proper setup as many times as stages in our case we had to run this twice with dev and prod.

Deployment Stages and Variables in AWS API Gateway

You also need to define multiple stages in AWS API gateway as shown in the slide we have 2 stages defined as dev and prod.

Click on the Stages then click on Stage Variables and enter the name of your variable and value you like to pass on this API endpoint. In our case, we have variable defined env which is we are using in our Lambda Integration point (see the previous paragraph)

Stage Variable for DEV

Stage Variable for PROD

Test the API

Copy the API endpoint from the stages as shown in the slide

Now test the dev stage endpoint in Postman the API would return “Hello from Lambda World”

Now try the prod stage endpoint, you will see the “Hello from Lambda”

Summary

AWS LambdaVersioning and Aliases are powerful features allow us to develop multiple versions of the same function and use for different use cases. AWS API Gateway Stage variables provide us to pass dynamic URLs and resources to avoid duplicates and complexity when developing your APIs.

Hope you find this post useful, please leave a comment for any questions or suggestions.