Set realistic function timeouts

AWS Lambda functions run code for a set amount of time before timing out. The timeout configuration is the maximum amount of time, up to fifteen (15) minutes, that an invocation of your Lambda function can run. The default timeout is three (3) seconds, but you can adjust the timeout in one second intervals.

Setting an appropriate timeout can be beneficial in containing costs of your Lambda-based application. This is particularly true in the unhappy path, when errors, blocking actions (for example, opening a network connection), or slow dependencies lead to your function running longer than desired or is necessary. When your function reaches its configured timeout, execution of the function will end.

AWS Lambda is billed per millisecond of execution time. Setting realistic timeouts for functions prevents paying for execution that is not of value.

Consider a synchronous workload that includes Amazon API Gateway and a Lambda function:

API Gateway has a maximum integration timeout of thirty (30) seconds. API Gateway returns an integration error if the Lambda function does not return within thirty seconds. Milliseconds of execution beyond 30 seconds is execution time paid for, but not utilized by the system.

When setting function timeouts, consider:

• Downstream latency of dependencies when your function calls another service. Include network latency, particularly if the dependency is called over the internet.
• Potential retries in case of errors. For example, the AWS SDK will automatically retry failed actions by default. This is effective, particularly in case of temporary failures or throttles, but leads to a longer function execution.
• Potential for unhandled or unexpected errors in the system that may lead to uncaught exceptions.

The Amazon Builders Library article on timeouts, retries, and backoff reviews considerations for handling failures at Amazon.

Realistic timeouts protect against function execution in the error (or "unhappy") path primarily.

Our recommendation is to set a timeout of less than 29-seconds for all synchronous invocations, or those in which the caller is waiting for a response. Example event sources include API Gateway, AWS AppSync, and Amazon Alexa Skills.

Longer timeouts are appropriate for asynchronous invocations, but consider timeouts longer than 1-minute to be an exception that requires review and testing. While these may be appropriate, consider AWS Step Function or other integration services if substantial time is spent waiting for dependencies.

Setting realistic timeouts are an important protection against incurring cost for unnecessary execution time.