Intermittent Internal Server Error - StatusCode 500 on API Gateway calling Lambda

Viewed 2103

I have a REST API in AWS API Gateway that invokes a Python Lambda function and returns some result. Most of the times this workflow works fine, meaning that the Lambda function is executed and passes the result back to the API, which in turn returns a 200 OK response.

However, there are few times in which I get a 500 error code from the API and the Lambda seems not to be even executed. The response.reason says: "Internal Server Error" and no additional information is given.

There is no difference between the failing requests and the successful ones to the API in terms of the method or parameters format.

One more comment is that the API has the cache setting enabled. I've seen similar posts and some of the answers mention the format of the JSON object returned by the Lambda function, others point to IAM permissions issues, but none of those seem to be the cause here. In fact, as this post's title says this is an intermittent behavior: most of the times it works fine, but occasionally I get this error.

Any hint would be highly appreciated.

3 Answers

I have the same problem and in my case I had to enable Log full requests/responses data together with INFO logs on the API Gateway stage to see the following logs:

(xxx) Endpoint response body before transformations: 
{
    "Type": "Service",
    "message": "INFO: Lambda is initializing your function. It will be ready to invoke shortly."
}

In my case the issue was related to the fact that the lambda was in Inactive state, which happens If a function remains idle for several weeks.

I have the same problem and I suspect a timeout maybe due to lambda reaching its memory limit.

I have set the memory limit to the next notch (128 -> 512) and augmented the timeout to 10s (default is 3), and now I'm able to see the timeout in action. I still have the problem for the moment but now I'll be able to investigate.

I hope that this helps you.

I see this with a HTTP API integration. It's intermittent, and it appears to improve when adding provisioned concurrency to the Lambda. For example, on a Lambda that has between 4 and 10 concurrent instances, but usually hovers in the 4 to 8 range, purchasing between 5 and 6 provisioned concurrent instances helped reduce, possibly eliminate, these 500 errors.

I am still monitoring to see whether they are gone for good. The frequency of these errors has gone down drastically with the provisioned instances.

Related