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

On 9 Sep 2026, AWS raised the function timeout on Lambda Managed Instances (LMI) 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, set-timeout script, architecture diagram (draw.io).

First-party architecture benchmark (not a cited client) — We scored 8 workload shapes against the timeout vs compute matrix. 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)

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.

Figure: async and ESM paths on LMI can run 90 minutes; the HTTP path cannot. Open draw.io

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.

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. 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.

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 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 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.
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.
• 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 · Lambda vs ECS Fargate · EC2 vs Lambda · Which AWS compute