# Lambda timeout vs compute path (Sep 2026)

Anchors: [90-minute LMI timeout (9 Sep 2026)](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/), [Lambda Managed Instances](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html), [durable functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html).

Score each candidate workload **0–2** per column (0 = poor fit, 2 = strong fit). Highest column wins; ties favor the option your team already operates.

**Hard rules that override the table:**

- **Synchronous** invokes (API Gateway, Function URLs, ALB, SDK `RequestResponse`) stay at **15 minutes**, even on LMI, even if `--timeout` is 5400.
- **Classic on-demand Lambda** stays at **15 minutes**.
- **Init** on LMI stays at **15 minutes**.
- **Amazon MQ** and **DocumentDB** event source mappings stay at **15 minutes**.
- SQS visibility timeout must be **at least 6×** function timeout. A 90-minute function needs **≥ 9 hours** of visibility.

| Workload shape | Classic Lambda (15 min) | LMI async / ESM (90 min) | Durable LMI (90 min invoke, up to 1 year execution when async) | ECS Fargate task | AWS Batch |
| -------------- | ----------------------- | ------------------------ | -------------------------------------------------------------- | ---------------- | --------- |
| SQS / EventBridge ETL, 20–40 min, cheap to restart | 0 (timeout cliff) | **2** | 1 | 1 | 1 |
| Media transcode or 40-min inference; restart at minute 35 is expensive | 0 | 1 | **2** | **2** | 1 |
| Monte Carlo / portfolio calc, 50 min, CPU-heavy, no GPU | 0 | **2** | 1 | **2** | **2** |
| Bedrock reasoning job, 25 min, async | 0 | **2** | **2** | 1 | 0 |
| Sync HTTP API / webhook | **2** | 0 (sync still 15 min) | 0 | **2** | 0 |
| Amazon MQ or DocumentDB ESM consumer | **2** (still 15 min) | 0 | 0 | **2** | 0 |
| Multi-step saga with long waits (hours–months) | 0 | 0 | **2** (async durable execution) | 0 | 0 |
| GPU encode, custom AMI, or hours-to-days | 0 | 0 | 0 | 1 | **2** |

## Opinionated default (Sep 2026)

1. **Under 15 minutes, event-driven, scale-to-zero matters** → classic on-demand Lambda. Do not move to LMI just to buy timeout headroom you will not use.
2. **15–90 minutes, async or SQS/Kinesis/DynamoDB Streams, job is idempotent** → raise LMI timeout. Checkpointing is optional.
3. **15–90 minutes, restart wastes real money or time** → LMI **plus** durable `step()` checkpoints so a failure at minute 35 resumes instead of replaying from zero.
4. **Hours, GPU, custom AMI, sticky in-memory state, or a persistent process** → Fargate or Batch. Ninety minutes is not unlimited Lambda.
5. **Never set timeout to the platform max “just in case.”** A hung downstream call becomes a 15-minute or 90-minute billing event per concurrent invoke.

## When NOT to pick LMI 90-minute timeout

- The invoke path is **synchronous**.
- The function is **on-demand**, not Managed Instances.
- The event source is **Amazon MQ** or **DocumentDB**.
- You have not raised SQS visibility to **≥ 6×** the new timeout.
- Idle NAT (350 s) or short-lived credentials will drop the connection before the job finishes.
- The job needs **GPU, custom AMIs, or >90 minutes of continuous compute**.