AWS Lambda 90 minute timeout: read the conditions first
The AWS Lambda 90 minute timeout applies only to Managed Instances and async or event source mapping invocations. Synchronous calls still stop at 15 minutes.
AWS has raised Lambda's maximum function timeout from 15 minutes to 90. The AWS Lambda 90 minute timeout is real, but it is not a blanket change, and the conditions attached to it are the part most write-ups skip. It applies only to functions running on Lambda Managed Instances, and only to asynchronous invocations and invocations delivered through an event source mapping. If your function is called synchronously, you still get 15 minutes. As of September 2026, that is the whole rule.
That distinction decides whether this changes anything for you, so it is worth getting straight before you start deleting state machines.
What the AWS Lambda 90 minute timeout actually changes
The new ceiling is 5,400 seconds, up from 900. It is a six-fold increase on a limit that has been in place since 2018.
| Invocation type | Maximum timeout | Condition |
|---|---|---|
| Asynchronous (event invokes, S3 notifications, EventBridge) | 90 minutes | Lambda Managed Instances |
| Event source mapping (SQS, Kinesis, DynamoDB Streams, MSK) | 90 minutes | Lambda Managed Instances |
| Synchronous (request/response, Function URLs, HTTP front ends) | 15 minutes | Unchanged |
| Functions not on Managed Instances | 15 minutes | Unchanged |
AWS points at media transcoding, financial calculations, ETL jobs, AI inference and web scraping as the work this is aimed at — jobs with a long single stage rather than many short ones. For work that needs to run longer than 90 minutes, AWS directs you to durable functions, which can run for up to a year.
Why the 15 minute limit shaped so much architecture
Lambda started at a five-minute ceiling in 2014 and moved to 15 minutes in 2018. Everything that did not fit got decomposed, and a lot of that decomposition was never an architectural preference. It was arithmetic.
You can usually tell which is which by looking at a state machine and asking what each state is for. If a step exists because it owns a distinct failure mode — it retries differently, it alerts a different team, it can be resumed independently — the decomposition is doing real work. If the step exists only to hand a file to the next step before the clock runs out, it is a workaround with a CloudWatch bill. We have inherited plenty of the second kind, and they are the ones this change frees.
Which jobs can now collapse into one function
The candidates are jobs that are long because the work is long, not because the work is complicated:
- Single-pass file processing. Transcode a video, parse a large export, resize a batch of assets. One input, one output, no branch.
- Overnight ETL stages that read from a queue, transform, and write once. These are the clearest win, because an event source mapping invocation is exactly the path that got the new limit.
- Model inference over a batch where the batch is defined up front and there is nothing useful to do between items.
- Scheduled reconciliation that walks a data set and emits a report.
If you have been paying for a Fargate task purely to escape the 15-minute ceiling on work like this, the arithmetic is worth redoing. A long serverless architecture job that runs a few times a day is often cheaper on Lambda than a container that has to be scheduled, warmed and drained.
Which jobs should still not move
Four cases where the old decomposition is still the right answer:
- Anything a user is waiting on. Synchronous invocations are unchanged. This limit does not reach them.
- Anything where per-stage retry is cheaper than whole-job retry. A 90-minute job that fails at minute 85 and retries has cost you 175 minutes of compute to produce one result. Five 18-minute stages with checkpoints cost you 18.
- Anything with a wait in it — human approval, a third party's callback, a deliberate backoff. Burning Lambda duration to wait is the most expensive way to do nothing. Orchestration tools exist for exactly this shape.
- Anything with fan-out at different concurrency per stage. One function means one concurrency setting.
What a 90 minute execution changes in your code
A function that runs for an hour and a half is a different animal from one that runs for eight minutes, and three things break quietly.
Duplicate execution stops being cheap
Asynchronous invocations retry on failure, and event source mappings redeliver. That was always true, but at 90 minutes a duplicate is no longer a rounding error in your bill or your data. Make the work idempotent, checkpoint progress somewhere durable so a retry can resume rather than restart, and set the retry attempts and maximum event age deliberately instead of leaving the defaults in place.
Credentials can expire mid-run
The execution role credentials placed in the function environment are temporary. Code that reads them once at start-up and caches them for the life of the process is fine at eight minutes and can fail at eighty. Use the SDK's default credential provider so it refreshes, rather than pinning the environment variables into your own client at module load.
Connections go stale
A database connection opened at minute zero and used again at minute seventy has been idle long enough for the other end, or something in between, to have dropped it. Either pool through a proxy or make reconnection part of the job rather than an exception you discover in production.
Memory is the fourth thing worth watching. A long job that accumulates results in a list will find the ceiling eventually, and the fix is the same as it always was: stream through the data instead of collecting it.
Does the 90 minute timeout apply to API Gateway?
No. Anything behind an HTTP front end is a synchronous invocation, so the 15-minute ceiling stands. In practice an HTTP front end will cut the request off long before that anyway. If a request triggers long work, the answer has not changed: accept the request, return an identifier immediately, run the job asynchronously, and let the client poll or receive a webhook.
What to do this week
- List every function with a timeout at or near 900 seconds. That list is short and it is where the whole decision lives.
- For each one, check how it is invoked. Synchronous means nothing changes.
- For the async and event source mapping ones, check whether moving to Managed Instances is something you want for other reasons too, not just this ceiling.
- Before collapsing any state machine, confirm the job is idempotent and can resume from a checkpoint. If it cannot, that is the work — not the timeout setting.
The honest summary is that this removes a constraint that forced bad decompositions, and it does not remove the reasons for good ones. Treat it as permission to delete the state machines you built to beat a clock, and as no reason at all to touch the ones you built to handle failure. If you are not sure which is which, the failure modes that catch teams out on serverless platforms are a reasonable place to start reading.
Sources: the AWS Compute Blog announcement and InfoQ's write-up.
Frequently asked questions
Lambda now supports a maximum function timeout of 90 minutes, or 5,400 seconds, up from 15 minutes. The higher ceiling applies only to functions on Lambda Managed Instances, and only to asynchronous invocations and invocations delivered by an event source mapping. Synchronous invocations remain capped at 15 minutes.
No. Requests arriving through API Gateway are synchronous invocations, and synchronous invocations still cap at 15 minutes. In practice an HTTP front end will cut the request off well before that. For long work behind an HTTP endpoint, return a job identifier immediately and run the work asynchronously.
Not as a single function execution. AWS points to durable functions for work that needs longer, which can run for up to a year. For most batch work the better pattern is still to checkpoint progress and split the job so that a failure costs you one stage rather than the whole run.
Yes, for anything with branching, waits, human approval or stages that need different retry behaviour and concurrency. What you no longer need is a state machine built purely to chop a single long job into 15-minute pieces. If each state exists only to pass a file along, that decomposition was a workaround.
Three things commonly break: cached temporary credentials expire mid-run, idle database connections are dropped, and retries of a failed long job become expensive rather than trivial. Make the work idempotent, checkpoint progress durably, refresh credentials through the SDK provider chain, and expect to reconnect.
