Lambda Just Stopped Being the 15-Minute Service

Audience: beginner to senior engineers

Twelve years. Same ceiling. Then AWS multiplied it by six.

On 9 Sep 2026, AWS announced that Lambda Managed Instances (LMI) now supports a 90-minute function timeout for asynchronous and event source mapping (ESM) invocations. Jobs that used to force a re-architecture can now run as plain Lambda functions. Here is the full story, from basics to the sharp edges.

1. The basics

A Lambda timeout is how long one invocation may run before AWS stops it. It started at 5 minutes in 2014, rose to 15 in 2018, and stayed there.

Lambda Managed Instances is a capacity mode where Lambda runs on EC2-backed instances. You keep the serverless experience, and you get multiple concurrent requests per instance, specialized compute, and EC2 pricing advantages.

The new rule: on LMI you can set a timeout of up to 5,400 seconds, but only for async and ESM invocations. Same runtime, handler, IAM role and VPC setup. No code changes.

2. Analogy: the food truck vs. the kitchen

Regular Lambda is a food truck that must close its window after 15 minutes. Fine for sandwiches, painful for a slow-roasted brisket. LMI with a 90-minute timeout is the same chef with a bigger oven: same menu and same kitchen rules, but the brisket can finally finish. The customer who orders at the counter (a synchronous call) still gets the 15-minute window.

3. Deep dive

Turning it on is one setting:

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

Or in SAM / CloudFormation: Timeout: 5400. The change applies to later invocations; for ESMs, allow a few minutes to propagate. Pricing: no extra charge, standard LMI pricing applies.

Durable functions: the power combo

The function timeout (--timeout) limits each invocation. The durable execution timeout limits the whole workflow. Async durable executions can now run up to 1 year, with each invocation lasting up to 90 minutes. Checkpoints (step(), wait()) mean a failure at minute 35 resumes from the last checkpoint, not from zero. For synchronous and ESM invocations, both the invocation and the durable execution are capped at 90 minutes.

4. Flow: which timeout do I get?

5. Twelve years of Lambda timeouts

Source: figures from the AWS announcement. MicroVMs for AI-generated code go up to 8 hours, but that is a different, HTTP-driven form factor.

6. Pros and cons (honestly)

👍 Pros

• Long jobs stay on Lambda: no Step Functions or container workaround needed just for duration
• Zero code changes, one config value
• No extra charge for the longer timeout
• Pairs with durable checkpointing for expensive jobs
• Observability (CloudWatch, CloudTrail, X-Ray) works as before

👎 Cons

• Only on Managed Instances, not on-demand mode
• Sync calls still capped at 15 min
• Amazon MQ and DocumentDB ESMs excluded
• Longer runs widen the retry and duplicate window
• Long-lived connections and credentials need care

Use it when work is async or queue-driven, steady-state, and between 15 and 90 minutes. Skip it when a user is waiting on the response, or when a job can be split into small idempotent chunks that already work fine.

7. Edge cases that bite

• SQS visibility timeout. AWS recommends at least 6x the function timeout. At 90 minutes that is 9 hours. Lambda validates this when the ESM is created, but won't stop later queue or function changes from breaking the rule.
• NAT Gateway idle timeout of 350 seconds. A quiet connection can be dropped mid-job. Send keep-alives.
• Credentials and tokens. If they expire before minute 90, refresh them in the background.
• Custom HTTP clients and DNS. The AWS SDK respects DNS TTL; your own client might cache stale records.
• Set it higher, call it synchronously. Lambda silently applies 15 minutes. GetFunctionConfiguration still shows the higher number, so don't trust it alone.
• At-least-once everywhere. Durable steps can re-run if they fail before checkpointing. Use Powertools idempotency, and execution names as keys for durable functions.
• Batch failures. Turn on partial batch failure reporting so one bad record doesn't replay a 90-minute batch.

8. Who benefits

The announcement names workload patterns rather than specific customers, so here is who it targets:

• 🎬 Media teams: speech-to-text and video transcoding
• 💹 Finance: Monte Carlo simulations, bond pricing, portfolio risk
• 🧮 Data engineers: multi-gigabyte ETL and aggregation jobs at peak volume
• 🤖 AI teams: model testing and reasoning-style inference jobs
• 🕸️ Integration teams: crawling slow sources and large vendor file pulls

The community angle: AWS invites feedback on the Lambda Roadmap GitHub page, specifically asking whether people need longer sync timeouts or the on-demand mode. If you do, say so there.

9. How to learn it

10. Key takeaways

• 🚀 90 minutes, 6x more than before, for async and ESM on Lambda Managed Instances.
• 🧩 Config only: --timeout 5400, no code changes, no extra charge.
• 🚧 Not universal: sync stays at 15 min, and on-demand mode and some ESMs are excluded.
• 🛡️ Design for retries: idempotency, keep-alives, refreshed credentials, sane SQS visibility.
• 🔁 For expensive jobs, combine with durable functions so failures resume instead of restart.

Is it "revolutionary"? For long-running batch, media and AI jobs, it removes a real architectural tax. It is a targeted expansion rather than a universal one, and that is exactly why reading the fine print matters.

Based on the AWS Compute Blog announcement, 9 Sep 2026.