The new limit applies only to certain Lambda Managed Instances invocations. A longer timeout does not automatically make Lambda the right home for every batch job.
A larger timeout can hide a larger architecture decision
AWS Lambda built its reputation on short, event-driven work. A file arrives, a message enters a queue, an API request calls a function, and the function finishes quickly.
In September 2026, AWS increased the maximum timeout to 90 minutes for certain workloads running on Lambda Managed Instances. That sounds like a simple expansion: jobs that previously exceeded Lambda’s 15-minute limit can now stay in Lambda.
But this is not a universal change to ordinary Lambda. It applies to asynchronous and event-source-mapping invocations on Lambda Managed Instances. Synchronous calls remain limited to 15 minutes. Amazon MQ and Amazon DocumentDB event-source mappings also retain the 15-minute limit.
More importantly, Lambda Managed Instances change the compute, concurrency, scaling and pricing model. The decision is not simply whether a function needs another 75 minutes. It is whether the workload fits this different form of Lambda.
What changed—and what did not
| Invocation or compute mode | Maximum continuous invocation |
|---|---|
| Standard Lambda synchronous invocation | 15 minutes |
| Standard Lambda asynchronous invocation | 15 minutes |
| Lambda Managed Instances synchronous invocation | 15 minutes |
| Lambda Managed Instances asynchronous invocation | 90 minutes |
| Most event-source mappings on Managed Instances | 90 minutes |
| Amazon MQ or DocumentDB event-source mapping | 15 minutes |
AWS describes use cases such as media processing, AI inference, scientific work, financial calculations, slow file transfers and large data-processing jobs. These are technically possible candidates. Technical eligibility is only the first filter.
Managed Instances are not ordinary Lambda with a bigger clock
Standard Lambda runs execution environments on AWS-managed, multi-tenant infrastructure and charges primarily by requests and execution duration. It scales to zero when idle.
Lambda Managed Instances run functions on EC2 capacity in your account while AWS manages instance lifecycle, runtime patching, routing and scaling. They use instance-based pricing, including a management fee, and maintain configured minimum capacity rather than behaving like scale-to-zero standard Lambda.
They also support multiple concurrent invocations inside one execution environment. That can improve utilization for I/O-heavy workloads, but it changes assumptions about shared memory, global variables, thread safety and context isolation. A function written for the single-concurrency behaviour of ordinary Lambda may need engineering work before it is safe on Managed Instances.
This makes the 90-minute limit part of a broader decision:
- Do you have steady enough demand to justify instance capacity?
- Can the code safely handle concurrent invocations in one environment?
- Is CPU-based asynchronous scaling appropriate for the workload?
- Can the job recover after failing at minute 89?
- Does Lambda still offer an advantage over a container or batch service?
Long-running does not mean durable
A timeout tells you how long code may continue running. It does not guarantee that the work will complete.
Instances fail. Dependencies time out. Deployments replace environments. A message may be delivered again. If a 70-minute job restarts from the beginning after failure, the larger timeout has extended the amount of work that can be lost.
Long jobs therefore need:
- idempotent processing so a retry does not duplicate business effects;
- checkpoints or partitions so recovery does not restart everything;
- a clear retry and dead-letter policy;
- progress and failure telemetry;
- bounded input size and execution time;
- safe cancellation and cleanup.
AWS durable functions can preserve application state across steps and resume from checkpoints. Step Functions can coordinate several tasks, waits and branches. AWS Batch and ECS can run containerized compute with different resource and job-control models. A 90-minute invocation does not replace those capabilities.
Where 90-minute Lambda can fit
Lambda Managed Instances may be a good choice when the workload:
- is triggered asynchronously or by a supported event source;
- normally completes well inside 90 minutes;
- has predictable or sustained demand that can use provisioned instance capacity;
- benefits from EC2 instance choices but does not justify managing a container platform;
- can tolerate the Managed Instances concurrency model;
- is idempotent and can checkpoint or divide work safely;
- already fits Lambda’s event, deployment and observability model.
A team processing a steady stream of large documents from SQS, for example, may value Lambda integration while using Managed Instances for longer processing and specialized compute.
Where another service is probably better
| Workload characteristic | Better starting point | Why |
|---|---|---|
| Short, bursty event processing | Standard Lambda | Scale to zero and simple per-invocation economics |
| Multi-step process with waits or approvals | Step Functions or durable functions | Explicit state, checkpoints and recovery |
| Large container image or custom operating environment | ECS/Fargate | Greater control over runtime and task lifecycle |
| Queued compute with varied CPU/GPU requirements | AWS Batch | Job queues, scheduling and compute environments |
| Work routinely approaches 90 minutes | ECS or Batch | More headroom and clearer job controls |
| Continuous service or long-lived worker | ECS/EKS/EC2 | It is not naturally an invocation |
These are starting points, not universal rules. Data movement, team skills, regional availability, compliance, startup latency and cost can change the answer.
The cost question is different too
It is tempting to compare the price of a 60-minute standard-style invocation with a container task. That is incomplete because Managed Instances use EC2-based capacity rather than standard Lambda’s scale-to-zero duration model.
Model the complete operating pattern:
- Minimum instances that remain available.
- Average and peak utilization.
- Concurrency achieved per execution environment.
- Instance, storage, data-transfer and management charges.
- Cost of retries and repeated work.
- Operational effort avoided compared with containers.
A cheaper compute minute can still produce a more expensive system if capacity sits idle or long retries repeat large jobs.
What should architects do next?
Do not migrate a Step Functions, ECS or Batch workload merely to remove a service from the diagram.
Choose one candidate job and measure:
- real duration distribution, not only the average;
- CPU, memory, storage and network use;
- arrival pattern and achievable concurrency;
- failure frequency and restart cost;
- recovery point after interruption;
- current total cost, including orchestration and operations.
Then compare a small Managed Instances trial with the current architecture. If the new design is simpler, recoverable and economically sound, the longer timeout is useful. If the only argument is “it now fits under 90 minutes,” the architecture review is not finished.
Know, use or master?
Know: Cloud practitioners should understand that the 90-minute limit is not available to every Lambda function and that Managed Instances use a different capacity model.
Use: Developers and DevOps engineers should be able to design idempotency, checkpointing, concurrency safety, retries and telemetry for long jobs.
Master: Cloud architects should compare Managed Instances, durable functions, Step Functions, ECS and Batch using workload behaviour, recovery requirements and total cost.
The useful question is not, “Can Lambda run this for 90 minutes?” It is, “What happens when this 90-minute job is slow, duplicated, interrupted or idle?” That answer should choose the architecture.
References and further reading
- Announcing 90-minute function timeout on AWS Lambda Managed Instances — AWS, 9 September 2026. Defines eligible invocation types and intended use cases. Reviewed September 2026.
- Configure Lambda function timeout — AWS Lambda documentation. Confirms timeout limits and exclusions. Reviewed September 2026.
- Lambda Managed Instances — AWS Lambda documentation. Explains compute, concurrency, scaling, isolation and pricing differences. Reviewed September 2026.
- Best practices for Lambda Managed Instances — AWS Lambda documentation. Covers availability, concurrency and long-invocation considerations. Reviewed September 2026.