How to fix AWS Lambda + API Gateway integration timeout after 30 seconds (Python code)

3 min readJul 18, 2023

In this article I will talk about how you can fix your AWS Lambda integration with API Gateway failure after 30 seconds (timeout).

Assumptions

We are going to assume the following:

code is written in Python
we have at least one AWS lambda function
we have at least one API Gateway instance
the two above are connected via an integration
you have basic knowledge about AWS API Gateway, AWS Lambda

Prerequisites

One initial lambda function

This lambda function simply waits for 31 seconds (more than the 29 seconds threshold) and then sends a response back.

import time

def handler(event, context):
    time.sleep(31)
    return {"hello": "world"}

An integration with API Gateway

For this particular article the integration code is not relevant and it would be a lot to take into, since you need to create your API Gateway instance, add it to a stack and connect the lambda function to that API Gateway instance.

If needed, I will create a separate article to showcase how you can do an integration between an AWS Lambda function and API Gateway.

The problem

There are cases where your lambda might take more than 30 seconds to respond to the HTTP call and you will get an error saying that your request failed due to a timeout.

Usually this happens because of a combination of the following: your lambda took longer to start (unused lambdas have a cold start by default) and the actual running of the code inside a lambda took longer than 29 seconds to finish and give API Gateway a response back.

If API Gateway does not get a response back after 29s after it has sent the request, then it times out and sends a default response to the calling entity.

Distinction

We need to establish that AWS Lambda timeout and API Gateway timeout are two different things.

For a lambda you can set up a timeout of maximum 900 seconds (15 minutes) while for API Gateway you are stuck with a maximum of 29 seconds.

The solution

Lambda posting a message into an SQS queue and having a trigger

A possible solution is to have the first lambda post a message in an SQS queue, and then having a trigger inside that SQS queue that will start a second lambda once the message lands in the queue.

As an addition to this, we can have a DLQ (dead letter queue) which stores any failed runs of the second lambda for you to be able to re-try the message after fixing the bugs. The idea is that you will know when one run failed and have ways to revert specific actions that you do not want.

Here’s a simple diagram of the flow for this particular solution.