Using AWS API Gateway Stage Variables as Environment variables

Image for post
Image for post

While building enterprise applications, the parameters such as Db name, file server name etc. are often required to be different for each environment. For example, you would want to point your dev environment to the dev version of the database. When the application gets promoted to test environment, it should point to the test version of the database.

In the AWS’ Serverless Backend world, we would want to have a separate version of Lambda function to be pointing to each environment, so that we do not accidentally point the prod environment to our dev version.

But how do you set up your application such that this happens seamlessly without needing any hard coding in a config file or having the put these in environment variables?

Here are some steps you can take to make this happen…

  1. You can define stage variables for each stage in the API Gateway. Define a stage variable named “alias”.
Image for post
Image for post

2. When setting up the integration request for the API, you will need to pass the stage variable as an alias as follows.

Image for post
Image for post

3. Lambda functions must have an alias for each environment such as Dev, test and prod.

4. Here comes the best part. How do we figure out in which environment we are running the lambda function?

Well, when a specific alias of the lambda function is being used, the alias’ name can be derived from the context. So, in your event handler, you can access the context, get the invoked function’s ARN. The ARN’s last node contains the alias. You can get that using the code as follows –

def lambda_handler(event, context):

arn = context.invoked_function_arn

lastIndex = arn.rindex(‘:’) + 1

runEnvironment = arn[lastIndex:]

Now, you are all set to use runEnvironment to derive the path to all your parameters in the Parameter Store as follows –

db_url = ssm.get_parameter(Name=’/pathnode1/’ + runEnvironment + ‘/pathnode2’, WithDecryption=True)[‘Parameter’][‘Value’]

The approach makes it easy to identify which parameter to use (and hence which components to use) based on the environment (stage).

While following this approach, you will need to ensure two things –

· Provide appropriate permission to your API Gateway to call the lambda function’s alias

· Define your parameters so that they have the value of the stage variable as a part of its path. /webabb/{stagevariable-value}/param-name

· Ensure that the lambda function’s alias is pointing to the appropriate version

The benefits of this approach are –

1. Simulate multiple environments in a single AWS account.

2. There is a clear distinction between various components being used by your environments.

3. In the Terraform script, you can define a single variable for API Gateway Stage, Stage Variables, Lambda Alias, Parameter Store

Architecting with AWS

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store