AWS Lambda now allows functions running on Lambda Managed Instances to run for up to 90 minutes, six times longer than the previous 15-minute limit, further blurring the line between a Lambda invocation and a traditional server. The limit remains unchanged for traditional synchronous requests.
Lambda's timeout increased from 5 minutes at launch in 2014 to 15 minutes in 2018, but that limit led to workarounds for longer-running workloads. Common cases included media processing, financial calculations, data processing and ETL, AI inference, and web scraping or large file transfers, where jobs can exceed 15 minutes of continuous execution.
As AWS points out in the article "Announcing 90-minute function timeout on AWS Lambda Managed Instances," longer-running Lambda functions require extra care with network connections, temporary credentials, and duplicate execution. Developers should ensure connections and credentials remain valid for the full runtime and design operations to safely handle retries and duplicate processing. Durable Functions also require idempotency because failed steps may run again. The team warns about idempotency:
Lambda does not guarantee exactly-once processing. With longer-running functions, the window for retries and duplicate deliveries increases. You can use Powertools for AWS Lambda to implement idempotency in your function code so that operations like payments or database writes produce the same result even if executed more than once.
The 15-minute limit has been a recurring pain point in the AWS community. Yan Cui, serverless expert and AWS Hero, writes:
Part of me is sad that this further blurs the line between "running a server" and a Lambda invocation. But it does make sense, especially for the "Lambda for agentic workflows" use case.
Lambda now offers two main forms: functions for event-driven workloads with a 15-minute timeout, and MicroVMs for user- or AI-generated code that can run for up to 8 hours. Lambda Managed Instances extend this model to steady-state workloads, allowing multiple requests per instance and access to EC2-based pricing and compute options without requiring infrastructure management. Rajesh Pandey, principal engineer at AWS, highlights how the increase can simplify many deployments:
I've lost count of how many times customers have asked when are you guys going to build, "Long-running Lambda functions." Finally, it's here. A lot of the duct tape built around Lambda’s maximum execution duration can now come off.
While the [community reaction has been mostly positive](https://www.reddit.com/r/aws/comments/1wbx6d2/lambda_gets_90_minute_timeout/), some warn that it might encourage fragile and costly patterns. User *Dull_Caterpillar_642* [writes](https://www.reddit.com/r/aws/comments/1wbx6d2/comment/p8uexxc/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button):
If it's taking 90 min, there's a good chance you should be using something like durable functions (...) Unless your code is literally doing meaningful stuff that entire time as opposed to waiting on other stuff, in which case the economics of Lambda may not work out as much in your favor, and something like ECS Tasks or AWS Batch could make more sense.
The increased timeout is not the only recent announcement for Lambda Managed Instances, with the service now also supporting Graviton5-powered EC2 instances.
The extended timeout is supported in all regions where Lambda Managed Instances are available.