- Newest
- Most votes
- Most comments
To make an HTTP API integration work with stage variables and a lambda function with aliases:
-
Create an HTTP API. (not REST)
-
Create two or more stages in the API. For this example, I'm creating two stages and naming them ‘development’ and ‘production’.
-
In each stage, create a stage variable 'lambda_alias'. In the ‘development’ stage, give the variable the value 'dev' and in ‘production’: 'prod'. Deploy the stages of the API if they are not auto-deployed.
-
In your lambda function, create an alias called 'prod' and have the alias point to the first version of your lambda function. Create a second alias 'dev' and have it point to $LATEST. In this example, the lambda function is named ‘helloworld1’ . This assumes that the lambda function has at least one version and has been deployed one or more times since the version was made. Both version 1 and the latest deployment provide output that are different (so that on you can check that the setup is working properly).
-
Save and copy the ARN of the helloworld1 function.
-
Back in the API console, create a lambda function integration.
-
For the lambda function name, you cannot use the lambda function name from the drop down OR the lambda function ARN that you previously copied. Instead, you must use a gateway ARN with the invocations action. Use the following as a template with your values for region and the previously copied function ARN. Do not make any substitutions for ${stageVariables.lambda_alias}
arn:aws:apigateway:<AWS_REGION>:lambda:path/2015-03-31/functions/<LAMBDA_ARN_YOU_COPIED>:${stageVariables:lambda_alias}/invocations
- Save (Create button) the integration.
A side-note on the “Why?” for the remaining steps. When you create the integration with a lambda function that contains a stage variable, it opens a small security hole. Left unchecked, the integration would run any aliased version of the lambda function. A bad actor could add an alias to the lambda function to accomplish some nefarious purpose. To prevent this bad behavior, AWS security takes a disallow stance on all integrations with a lambda function that use stage variables. The following steps tell AWS which alaised versions of the lambda function to allow.
-
After the save operation is complete, there is an “Invoke Permission” section on the “Integration details for route”. Expand the details for that section.
-
The ‘Example Policy Statement’ must be run for each lambda function alias. Do not run the code example as written: run it once for each of your lambda function aliases that you want API Gateway to have permission to run, substituting the alias value for ${stageVariables.lambda_alias}. Using a configured AWS CLI with a user that has sufficient privileges, run the ‘add-permission’ command for both helloworld1:dev and helloworld1:prod. Double check that you get a response similar to the one shown on the integration details page.
-
Attach the integration to an API route -- I’m using ‘howdy’ as the route.
-
Make a request to the /production/howdy and the ‘prod’ alias of the lambda function will be invoked. A request to the /development/howdy will invoke the ‘dev’ alias of the lambda function.
Releasing new versions of a lambda function will only require you to update which version of the function that prod and dev aliases point to. You do not need to make any additional changes to the API integration.
Relevant content
- asked a year ago
- asked 2 years ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago