- 最新
- 最多得票
- 最多評論
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.
相關內容
- 已提問 1 年前
- AWS 官方已更新 2 年前
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.