Give a function enough time, with a limit — Lambda and Timeouts

Your goal

Set a useful time budget for a function that calls a slow service.

Why this matters

A function works with small files but struggles with larger ones. You will measure realistic work, choose a time budget, and make retries safe if time runs out.

Words you will use

A timeout stops a run after its time limit. A retry is another attempt. A time budget divides the available time between calls and cleanup.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Measure realistic inputs

Your test file takes one second, but real files vary greatly. A timeout chosen from the smallest example may stop valid work. Choose what to measure.

Which test is most useful?

Typical and large supported inputs, including slow dependencies.

Measure the range of inputs the app promises to support. Include network waits and slower responses. A timeout needs room for normal variation while still limiting a stuck or unexpectedly slow run.

You have evidence for the function’s time budget.

Representative load tests → duration range

2. Leave room to finish

The function has a total time limit, but its network client can wait nearly that entire time on one call. Choose a safer arrangement.

How should call limits relate to the total?

Keep them shorter and leave time for cleanup and error handling.

A bounded network wait leaves time to record useful failure information or return a response. Set the total within the limits of the Lambda execution option you use, then test the whole path.

The function can handle a slow call before its own time runs out.

Call deadline < total budget; leave cleanup time

3. Avoid doing paid work twice

A request times out after a payment service accepts it. The next attempt cannot safely assume nothing happened. Choose a recovery approach.

What should another attempt check?

A stable request ID and the previous operation’s result.

A timeout does not prove that every downstream action was undone. Use a stable operation ID and check existing results so a retry can recover without charging or creating work twice.

A retry can find the original result safely.

Request ID → check prior result → continue or reuse result

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.