- Newest
- Most votes
- Most comments
There are basically 3 components at play here. The first is the version. You want to create a version of your Lambda function and make sure the version construct in AWS has the specific revision of code you want deployed. You can do this in the Lambda console or with the publish-version CLI command.
Then you create the alias, and make sure the alias itself is pointed to the correct version. You can do this with the console or the create-alias command.
Once you do that, you have to make sure that the integration points to the alias. That should look like <function-name>:alias. You can do this through the API Gateway console or the create-integration CLI command.
This documentation on aliases would be helpful:
https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html
I'd recommend checking over these steps since you are having issues. The answer is likely in one of them.
You can use stage variable for this, there is a tutorial how to do that: https://aws.amazon.com/ru/blogs/compute/using-api-gateway-stage-variables-to-manage-lambda-functions/ (it's at the very end of the page)
I think ApiGateway with Lambda integrations is bugged. I'm running into the exact same problem here. Basically, no matter if I put a version or an alias in the REST lambda integration, the calls always get forwarded to the unaliased Lambda. The CloudWatch logs prove this.
Thanks amoffat, deploying the API did the trick. I also agree that a visual indication of undeployed changes would be a good idea.
Relevant content
- asked a year ago
- asked 4 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
Hi @Ted_Z, I'm having a similar issue here and I can confirm that it appears broken. REST gateway to a Lambda alias always goes directly to the unaliased Lambda.