AWS Lambda Can Now Run for 90 Minutes — Here’s the Catch
AWS Lambda Managed Instances can now run asynchronous and event-driven workloads for up to 90 minutes. Here is what actually changed, where it helps, and the limits developers should know before using it.
Dev Ops
One of Lambda's most famous limits just changed
If you have worked with AWS Lambda before, you probably know one number: 15 minutes.
For years, that has been the maximum execution time of a Lambda function. If a workload needed 20, 30, or 60 minutes of continuous processing, you usually had to split the work or move it somewhere else.
AWS has now changed that for Lambda Managed Instances.
Asynchronous invocations and supported event source mappings can now run for up to:
90 minutes (5,400 seconds).
That is a 6x increase over the previous limit.
But this does not mean every Lambda function can suddenly run for 90 minutes.
What actually changed?
Lambda Managed Instances use fully managed EC2 capacity inside your VPC while keeping the Lambda programming model. AWS still manages provisioning, patching, scaling, and instance lifecycle, but you can select EC2 instance families and run multiple concurrent Lambda requests on that capacity.
The new 90-minute timeout applies mainly to long-running background and event-driven workloads.
Scenario | Maximum timeout |
|---|---|
Managed Instances + asynchronous invocation | 90 minutes |
Supported event source mappings | 90 minutes |
Synchronous Lambda invocation | 15 minutes |
Function initialization | 15 minutes |
Amazon MQ / DocumentDB event mappings | 15 minutes |
That distinction matters.
This feature is not intended for an API request that keeps a user waiting for an hour. It is much more interesting for workloads such as data processing, media processing, long-running calculations, AI inference, and queue-driven background jobs.
If the function already uses Managed Instances, the timeout can be configured with the AWS CLI:
aws lambda update-function-configuration --function-name my-function --timeout 5400 It can also be configured through the AWS Console, CloudFormation, SAM, and supported AWS developer tooling.
Longer functions create new architecture questions
A 90-minute timeout removes one limitation, but it also makes good architecture more important.
For example, imagine a Lambda function processing messages from Amazon SQS.
AWS recommends setting the SQS visibility timeout to at least six times the Lambda function timeout. A Lambda configured for 90 minutes could therefore require a visibility timeout of roughly 9 hours.
Otherwise, a message could become visible again while the original invocation is still processing it.
Long-running workloads also make idempotency more important. Lambda does not guarantee exactly-once processing, so operations such as database updates, payments, file creation, or external API calls should be safe to retry.
There is also a bigger cost to failure.
If a job fails after 50 minutes, restarting everything from zero may be expensive. For workflows that need checkpoints, waits, and recovery across multiple stages, Lambda durable functions may still be a better pattern.
Networking deserves attention too. A function that runs for an hour gives database connections, external APIs, credentials, DNS records, and network sessions much more time to expire or change.
In other words:
a workload that works for five minutes is not automatically safe to run for ninety.
Does this replace ECS or AWS Batch?
No.
The new timeout makes Lambda an option for more workloads, but it does not remove the tradeoffs between serverless functions, containers, and batch computing.
ECS or AWS Batch can still make more sense when you need specialized containers, complex scheduling, large compute fleets, several hours of runtime, or greater control over the execution environment.
Pricing matters as well.
Lambda Managed Instances use managed EC2 capacity, so their pricing model differs from normal Lambda. Costs include the underlying EC2 capacity, Lambda requests, and the Managed Instances management charge.
The right question is therefore not:
"Can Lambda run this now?"
It is:
"Does the Lambda programming model make sense for this workload?"
A useful experiment for students
If you are learning AWS architecture, try designing the same long-running background task three ways:
Lambda default compute → Lambda Managed Instances → ECS or AWS Batch
Compare runtime limits, scaling, cost, retry behavior, observability, failure recovery, and operational responsibility.
That comparison teaches much more than simply memorizing that Lambda can now run for 90 minutes.
My takeaway
The interesting part of this announcement is not only that Lambda can run longer.
It is that one of the easiest AWS rules to remember:
"More than 15 minutes? Lambda is not an option."
is no longer always true.
The decision now depends on invocation type, compute mode, cost, retries, networking, idempotency, and workload characteristics.
AWS removed a technical limit.
Developers still have to decide whether using that extra runtime is actually the right architecture.
If you are already using Lambda Managed Instances, what kind of workload would you consider moving to the new 90-minute timeout?
Happy building!
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article