---
title: Lambda Managed Instances now run 90 minutes — stop splitting 20-minute jobs
description: On 9 Sep 2026 AWS raised LMI async and ESM timeout from 15 to 90 minutes (5,400 s). A 90-minute SQS consumer needs at least 9 hours of visibility. Sync and classic on-demand Lambda stay at 15 minutes.
url: https://www.factualminds.com/blog/aws-lambda-managed-instances-90-minute-timeout-2026/
datePublished: 2026-09-10T00:00:00.000Z
dateModified: 2026-09-10T00:00:00.000Z
author: palaniappan-p
category: Serverless & Containers
tags: aws, aws-lambda, lambda-managed-instances, serverless, event-driven, sqs, architecture
---

# Lambda Managed Instances now run 90 minutes — stop splitting 20-minute jobs

> On 9 Sep 2026 AWS raised LMI async and ESM timeout from 15 to 90 minutes (5,400 s). A 90-minute SQS consumer needs at least 9 hours of visibility. Sync and classic on-demand Lambda stay at 15 minutes.

On **9 Sep 2026**, AWS [raised the function timeout on Lambda Managed Instances (LMI)](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/) from **15 minutes to 90 minutes (5,400 seconds)** for **asynchronous** and **event source mapping (ESM)** invocations — a **6×** increase, with **no extra charge** beyond standard LMI pricing.

That is the whole product change. Everything else in this post is about **who should use it** and **who will burn money** by treating 5,400 seconds as the new default.

**What did not change:**

- Classic **on-demand** Lambda is still **15 minutes**.
- **Synchronous** invokes (API Gateway, Function URLs, ALB, SDK `RequestResponse`) are still **15 minutes**, including on LMI.
- **Init** on LMI is still **15 minutes**.
- **Amazon MQ** and **DocumentDB** ESMs are still **15 minutes**.
- A durable **execution** can still run up to **1 year** when invoked asynchronously. Each invocation inside it can now run **90 minutes** continuously on LMI instead of 15.

If your team has been splitting 20-minute ETL steps, chunking transcodes, or bouncing mid-size inference to Fargate **only** because of the 15-minute cliff, LMI async is now a legitimate middle path. If the job needs hours, a GPU, or a process that stays warm, Fargate and Batch are still the right tools.

Artifacts: [timeout vs compute matrix](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/timeout-vs-compute-matrix.md), [set-timeout script](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/set-lmi-async-timeout.sh), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/lambda-lmi-90-minute-timeout.drawio).

> **First-party architecture benchmark (not a cited client)** — We scored **8** workload shapes against the [timeout vs compute matrix](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/timeout-vs-compute-matrix.md). **2** landed on **LMI timeout alone** (idempotent SQS ETL, 20–40 min). **2** landed on **LMI + durable checkpoints** (transcode / reasoning where a restart at minute 35 wastes the run). **1** stayed on **classic Lambda** (sync HTTP). **1** stayed on **Fargate** (MQ consumer — ESM still 15 min). **1** stayed on **durable LMI** for a year-long saga with waits. **1** stayed on **Batch** (GPU encode, hours). The number that matters operationally is not 90 — it is **9 hours** of SQS visibility if you actually set `--timeout 5400`.

## Invocation matrix (read this before you change `--timeout`)

| Invoke path | On-demand Lambda | LMI |
| ----------- | ---------------- | --- |
| Synchronous (API Gateway, Function URL, ALB, `RequestResponse`) | 15 min | **15 min** |
| Asynchronous (EventBridge, S3, SNS, async SDK) | 15 min | **90 min** |
| ESM: SQS, Kinesis, DynamoDB Streams, MSK, self-managed Kafka | 15 min | **90 min** |
| ESM: Amazon MQ, DocumentDB | 15 min | **15 min** |
| Durable function, async execution | 15 min per invoke; execution up to 1 year | **90 min** per invoke; execution up to 1 year |
| Durable function, sync or ESM | 15 min | **90 min** for both invoke and execution |
| Init phase | 15 min | **15 min** |

`GetFunctionConfiguration` reports the **configured** timeout. If you set 5,400 and then hit the function through API Gateway, you still get 15 minutes. Reviews that only read the config value will lie.

![Quiet server hall with a wall clock, used as the reference architecture figure for long-running LMI jobs](../../assets/images/blog/aws-lambda-managed-instances-90-minute-timeout-2026.webp)

_Figure: async and ESM paths on LMI can run 90 minutes; the HTTP path cannot. [Open draw.io](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/lambda-lmi-90-minute-timeout.drawio)_

## When to raise timeout to 5,400 seconds — and when not to

**Raise it** when all of these are true:

1. The function already runs on **Managed Instances**.
2. The invoke path is **async or a supported ESM**.
3. The job is a **single continuous unit of work** that routinely exceeds 15 minutes (peak ETL, transcode, Monte Carlo, longer inference).
4. You have set SQS visibility to **≥ 6×** the new timeout, or you are not on SQS.

**Leave it** (or set it to measured p99 + buffer) when:

- The path is a **sync API**.
- The function is **on-demand**.
- You have not proven the job needs more than 15 minutes on production-like payloads.
- A hang would now bill for **90 minutes × concurrency**.

There is no additional charge for the longer cap. You still pay LMI compute for every second the function actually runs — including the seconds it sits on a dead NAT connection.

## The 6× SQS rule is the real footgun

AWS documents that SQS visibility timeout must be **at least six times** the function timeout so Lambda can retry a throttled batch. At 15 minutes that was **90 minutes** of invisibility. At 90 minutes it is **9 hours**.

Lambda checks this when you **create** the event source mapping. It does **not** stop you from later dropping queue visibility or raising function timeout out of band. That mismatch is how you get two consumers on one message.

For Kinesis and DynamoDB Streams, retune the **batching window** and **parallelization factor**. A 90-minute batch holds the iterator that long. Enable **partial batch failure** (SQS, Kinesis, DynamoDB Streams, MSK, self-managed Kafka) so one bad record does not replay the whole batch.

## Networking and credentials at 90 minutes

A 15-minute function could ignore idle timeouts. A 90-minute function cannot.

- **NAT Gateway** idle timeout is **350 seconds**. If the function holds a connection through NAT and goes quiet, the connection dies. Send keep-alives, or keep the work chatty.
- **RDS / ElastiCache / vendor API** idle timeouts must cover the full run, or you refresh the client in-loop.
- **Temporary credentials** (STS, vendor tokens) must last the run or be refreshed in the background.
- Respect **DNS TTL**. AWS SDK clients do; a custom HTTP pool that caches forever will pin a stale IP for the whole 90 minutes.

Idempotency matters more, not less. Lambda is still **at-least-once**. A longer run widens the retry window. Powertools idempotency keys, or durable execution names as keys, belong in the handler before you raise timeout.

## Durable functions and the 90-minute invoke

Timeout (`--timeout`) is **one invocation**. Durable `ExecutionTimeout` is **start to finish**, including waits.

- Idempotent SQS job: **timeout alone**. If the host dies, the message returns to the queue and a fresh invoke starts.
- Expensive mid-job work: **timeout + `step()` checkpoints**. A failure at minute 35 resumes from the last checkpoint instead of minute zero.
- Async durable execution can still span **up to a year**; each LMI invoke inside it can now do **90 minutes** of continuous compute.

Do not use a 90-minute invoke as a substitute for `wait()`. Waiting should checkpoint and suspend, not burn LMI capacity.

_Context: AWS CLI v2, function already on a Managed Instances capacity provider, region `us-east-1`. Sync invokes remain capped at 900 seconds._

```bash
aws lambda update-function-configuration \
  --function-name my-data-processor \
  --timeout 5400 \
  --region us-east-1
```

SAM / CloudFormation uses `Timeout: 5400` on `AWS::Serverless::Function`. The change applies to **subsequent** invokes. ESM mappings can take a few minutes to pick it up.

> **Reproduce this** — Clone [`examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/set-lmi-async-timeout.sh`](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/set-lmi-async-timeout.sh). `bash set-lmi-async-timeout.sh my-data-processor us-east-1 https://sqs.us-east-1.amazonaws.com/ACCOUNT/queue` updates timeout to 5400 and **fails** if SQS visibility is below 32,400 seconds (9 hours). Score the workload first with [`timeout-vs-compute-matrix.md`](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/timeout-vs-compute-matrix.md).

> **What broke** — Modeled counter-case, not a production incident. Team sets `Timeout: 5400` on an LMI function fronted by API Gateway, reads 5400 from `GetFunctionConfiguration`, and ships. The first 22-minute report export still dies at **15 minutes** because the invoke is synchronous. Second failure mode: same 5400 on an SQS mapping while visibility stays at **300 s**. A second consumer starts at minute 5 while the first is still writing. Detection: duplicate primary keys plus `ApproximateReceiveCount` > 1 on in-flight messages. Fix: move the export to EventBridge async (or SQS), set visibility to **32,400 s**, and set timeout to measured p99 + buffer — not the platform max.

## Opinionated recommendation

**Use LMI 90-minute timeout** for async or SQS/Kinesis/DynamoDB Streams jobs that already belong on Managed Instances and that routinely miss 15 minutes — ETL, transcode, CPU-bound calc, longer inference — **after** you fix visibility, NAT keep-alives, and idempotency.

**Add durable checkpoints** when restarting from zero is the expensive part.

**Stay on classic Lambda** for spiky, sub-15-minute, scale-to-zero handlers. The [LMI ops playbook](/blog/aws-lambda-managed-instances-2026-operations-guide/) is still the scaling guide; this post does not replace it.

**Prefer Fargate or Batch** for hours-to-days, GPU, custom AMIs, sticky in-memory state, or a process that must stay up. Ninety minutes is not "unlimited Lambda." Walk [which compute](/decide/which-aws-compute/) if the duration question is still open.

**Do not** raise timeout to 5,400 seconds on a sync API, an MQ/DocumentDB mapping, or as a global default.

## What to Do This Week

1. Inventory functions that currently **chunk at 14 minutes** or that already time out. Tag invoke type: sync / async / ESM.
2. Drop anything **sync**, **on-demand**, **MQ**, or **DocumentDB** from the 90-minute list.
3. Score the rest on the [timeout vs compute matrix](https://www.factualminds.com/examples/architecture-blog-2026/lambda-lmi-90-minute-timeout/timeout-vs-compute-matrix.md).
4. For SQS consumers, set visibility to **≥ 6×** timeout **before** you raise `--timeout`.
5. Set timeout to **p99 + buffer**, not 5400, unless you have measured a job that needs the ceiling.
6. If a restart at minute 35 would hurt, add durable `step()` around the expensive units.
7. Alarm on duration p99 and on SQS `ApproximateAgeOfOldestMessage` — a 9-hour visibility window hides stuck messages unless you watch age.

## What This Post Doesn't Cover

- **LMI capacity-provider sizing, scheduled scaling, 32 GB / 16 vCPU, file descriptors** — see the [LMI operations guide](/blog/aws-lambda-managed-instances-2026-operations-guide/).
- **Region availability** of 90-minute timeout on LMI — confirm in the account before you design around it.
- **A first-party duration benchmark** of a 90-minute job. This post shipped the day after the announcement; the matrix is an architecture score, not a stopwatch run in our lab.
- **On-demand 90-minute timeout** or **sync 90-minute timeout** — AWS asked for roadmap feedback; they are not here.
- **Cost model vs Fargate** at 60–90 minutes of continuous vCPU. Price both before you move a fleet.

**Related:** [AWS serverless services](/services/aws-serverless/) · [Lambda vs ECS Fargate](/compare/aws-lambda-vs-ecs-fargate/) · [EC2 vs Lambda](/compare/aws-ec2-vs-lambda/) · [Which AWS compute](/decide/which-aws-compute/)

## FAQ

### When should we NOT raise a Lambda timeout to 90 minutes?
Do not set 5,400 seconds on a synchronous API, on classic on-demand Lambda, on Amazon MQ or DocumentDB event source mappings, or as a default "just in case." Sync and on-demand stay at 15 minutes. A hung downstream call with a 90-minute timeout becomes a 90-minute billing event per concurrent invoke. Keep timeout close to the real p99 duration plus a small buffer.

### Does the 90-minute timeout apply to ordinary Lambda functions?
No. The 90-minute cap is for functions running on Lambda Managed Instances, and only for asynchronous invokes and supported event source mappings. Classic on-demand Lambda remains 15 minutes. The Init phase on LMI is still 15 minutes.

### What happens if I set timeout to 5400 seconds and invoke the function synchronously?
Lambda still applies the 15-minute synchronous cap. GetFunctionConfiguration reports 5400, which is easy to misread in a review. API Gateway, Function URLs, ALB, and SDK RequestResponse invokes do not get 90 minutes.

### What goes wrong if SQS visibility stays at five minutes after raising timeout?
AWS requires SQS visibility timeout to be at least six times the function timeout. A 90-minute function needs at least 9 hours of visibility. If visibility is shorter than runtime, a second consumer can start while the first is still working — duplicate side effects, lock fights, and poisoned batches. Lambda validates this at mapping create time, not after you change the queue later.

### Do Amazon MQ and DocumentDB event source mappings get 90 minutes?
No. Those mappings remain limited to 15 minutes. Use SQS, Kinesis, DynamoDB Streams, Amazon MSK, or self-managed Kafka for the longer window, or move MQ/DocumentDB consumers to Fargate.

### Should we use durable functions instead of a longer timeout?
Use the 90-minute timeout alone when the job is idempotent and cheap to restart (SQS ETL is the usual case). Combine it with durable step() checkpoints when a failure at minute 35 would throw away expensive work. Durable execution can still run up to one year when invoked asynchronously; each invocation on LMI is now 90 minutes, not 15.

---

*Source: https://www.factualminds.com/blog/aws-lambda-managed-instances-90-minute-timeout-2026/*