- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Lambda functions, regardless of their VPC setting, are invoked using the Lambda service public API. This means that from the point of view of API Gateway it doesn't matter what the VPC setting is.
You did not mention what the error is, but maybe the function is accessible but it doesn't have proper access to the internet configured. For example: did you assign the function to a private subnet? Do you have a NAT Gateway configured in a public subnet in that VPC? Do you have a routing table with 0.0.0.0/0 pointing to the NAT Gateway in that private subnet?
I had sorted this out some time ago: I accidentally had attached the public subnet directly to the VPC. It should only be accessible through the NAT-Gateway. So yes, it was a subnet misconfiguration.
Right now about half of my calls to the API Gateway are successful. It seems that some condition during the start of the lambda container determines whether it works or times out. If I call the API Gateway in short intervals the result stays the same. If I wait for a longer time, allowing the lambda container to shut down, there is a 50:50 chance that it will work for the next call.
The logs (with API Gateway logging turned on) show no clue of what is going on. Does anyone have an idea about what to look for?
I'm currently getting my head around using API Gateway with lambda in VPC when I came across your comment. I found in the AWS knowledge centre some information on allowing internet access to lambda, and noticed it mentioned "An Amazon VPC-connected Lambda function randomly selects an associated subnet when making requests. All subnets that your function uses should have the same configuration to prevent random errors caused by Lambda using a misconfigured subnet." This sounds like it could have been your issue, and would explain the 50/50 issue (sometimes used one subnet, sometimes the other)
When I call a function in my lambda via API Gateway it simply times out. This is also reflected in the CloudWatch logs: They show a START event followed by an END stating that the task timed out. I created my VPC according to instructions here: https://digitalvarys.com/how-to-assign-a-static-ip-to-the-aws-lambda-function/
Does that show a correct way to do it? And how do I assign a subnet to a lambda?
Ok, now I have it partially working: sometime it works, sometimes it doesn't (times out). How can this be?
I'm currently getting my head around using API Gateway with lambda in VPC when I came across your comment. I found in the AWS knowledge centre some information on allowing internet access to lambda, and noticed it mentioned "An Amazon VPC-connected Lambda function randomly selects an associated subnet when making requests. All subnets that your function uses should have the same configuration to prevent random errors caused by Lambda using a misconfigured subnet." This sounds like it could have been your issue, and would explain the 50/50 issue (sometimes used one subnet, sometimes the other.) Hope this info helps. Link: https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/
Contenuto pertinente
AWS UFFICIALEAggiornata 2 anni fa- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
Agree with Uri, the API, with the proper IAM or Resources permissions will be able to invoke the lambda, no matter which VPC you place it. However, if the lambda is places in a subnet with no proper routing to internet or AWS services (using vpc links) there is no way you can communicate with external dependencies