Multiple Environments for AWS Lambda Function with API Gateway
By: Ashish Dhiman
Tags: AWS Lambda, Lambda, AWS, Api Gateway, Python

Lambda function comes pretty handy for small micro-services when you want to go server-less. Creating a Lambda is pretty easy, you just need to package your code, upload the code one AWS, configure the lambda function and you are done. If you want to use the lambda function as a web service, you also need to create an API gateway for your lambda. As long as you don’t need multiple versions of that lambda, life is simple, but that is not always the case. Most of today’s micro-service architectures need multiple environments for the lambda. Using multiple environment for a Lambda Function with API Gateway is not straightforward and will require some work if you doing it for the first time. In this post I’ll try to make it simple for a first time user.

Mainly there are two steps involved :

Configuring multiple alias for Lambda function.

Configuring multiple stages for API Gateway.

Configuring multiple alias for Lambda function

I am taking a very simple example where our lambda function is python 3.7 code. The function when invoked does not take any input parameters and return the name of the environment it is running on.

Our Sample Lambda Function

import json

import os environment_name = os.environ[“ENV”] def lambda_handler(event, context):

# TODO implement

return {

‘statusCode’: 200,

‘body’: json.dumps(‘You have reached the ‘ + environment_name + ‘ environment’)

}

An Alias represents an environment in a Lambda function. You need to create as many aliases as the number of environments you need.

Creating an Alias

Go to Actions tab and click on create alias option. You will see a form like the one shown on the left. Name your function, add the description and for now select version as $LATEST only. I’ll get back to this later. Repeat this step two times and create two aliases DEV and PROD.

Once you have created aliases, you should see two aliases DEV & PROD, both of them pointing to $LATEST version in your Alias tab.

Publish a version of Lambda

You can publish a lambda by clicking on Publish a Version in Actions tab.

Each version of published lambda is a combination of code and configuration. So, in our case code will remain the same for both environments but our configuration will change for two environments. I’ll use the environment variable ENV to differentiate dev and prod environments.

For DEV environment, I’ll set environment variable ENV in the Lambda environment variable tab as Development. Save the lambda and click on Publish a Version tab in Actions tab. All you need to do is add version description. Your version 1 is published now.

Publish a Version Dialog

If you go to the versions tab now, you’ll see two version $LATEST and 1. Now go to the Aliases tab under Version, and change the version from $LATEST to 1.

Once you’ve published a version the configuration will not be editable. If you want to publish another version you can select the $LATEST version, edit code and configuration and publish again. Repeat the same steps for PROD, by editing $LATEST and changing environment variable ENV to Production.

Once you are done, the Alias tab of Lambda should look like the image on the left. You can see that DEV is linked to version 1 and PROD is linked to version 2.

Configuring Multiple Stages for API Gateway

In this step, you can go to the API gateway and create a new API gateway with name like mutli-env-api. Go to Resources tab and create a new GET resource.

In the Integration resource section ( where you have to link to to a Lambda), select Integration type as Lambda, check the Use Lambda Proxy Integration option and enter following value in Lambda Function field: multiEnvLambda:${stageVariables.ALIAS}

Here we are specifying that use the lambda multiEnvLambda should be invoked and ALIAS should be supplied from stage variables.

API Gateway Integration Request Page

Once you’ll confirm, you will see a pop-up shown as below :

Popup for Integration Request page

You can copy the command and execute it using AWS CLI for the account you are using. This command will ensure that you have sufficient policies to access the Lambda Alias. Please make sure to replace the ${stageVariables.ALIAS} with the appropriate values. In our case we’ll need to run this command two times by replacing the this variable value with DEV and then PROD. DEV and PROD here are the names of our aliases.

Now, go to the Actions tab and click on Deploy API option. Create two new deployment stages dev and prod.

Modify each deployment stage by going to Stages option and add a stage variable with name ALIAS and value as DEV or PROD (this should be the exact name of Alias of Lambda to which you want the deployment state to be mapped).

In our case, dev deployment stage should point to DEV Lambda alias and prod deployment stage should forward the request to PROD Alias of our lambda.

How it Works

Everything seems to be ready now. Every Stage of API gateway will generate a unique URL with stage name as one of the path parameter so that you can invoke each stage independently.

When you invoke the dev stage API Gateway with its unique url ( in my case it is https://mgiawrkal9.execute-api.us-east-1.amazonaws.com/dev), the dev stage passes the ALIAS to the Lambda Function name in API Gateway and that Lambda Alias will be invoked.

So, now when I invoke the same lambda function with different urls, it will invoke a particular combination of Code + Configuration for each environment.