The 90-Minute Lambda Timeout for Agent Architecture: What It Changes, What It Doesn't

AWS extended the Lambda function timeout from 15 minutes to 90 minutes on Lambda Managed Instances. Most of the writeups will describe this as "long-running Lambda has finally arrived." That framing misses the constraints that actually matter.

The 90-minute timeout only applies to async and event-source-mapping invocations. Synchronous invocations, the kind API Gateway sends when a user hits an endpoint, are still capped at 15 minutes. The init phase is still capped at 15 minutes. And Lambda Managed Instances themselves are a different provisioning model with different pricing than standard Lambda. Understand those three constraints and the change turns into a specific tool for a specific class of agent workload. Miss them and you will ship the wrong thing.

I want to walk through what this changes for the agent architecture patterns I have been writing about, and what it does not.

What actually changed

Before the change: every Lambda invocation, sync or async, capped at 15 minutes.

After the change, three specific loosenings on Lambda Managed Instances:

• Async invocations (SQS-triggered, EventBridge, direct async invoke) can run up to 90 minutes.
• Event source mapping invocations from Kinesis, DynamoDB Streams, and Kafka can run up to 90 minutes.
• Amazon MQ and DocumentDB event source mappings stay at 15 minutes.

Three things that did not change:

• Synchronous invocations are still capped at 15 minutes, regardless of your configured timeout. If API Gateway calls your Lambda synchronously, or if your application does a RequestResponse invoke, 15 minutes is the wall.
• Init phase is still capped at 15 minutes. Loading a 30 GB model into memory at cold start did not just get easier.
• Standard Lambda still has the 15-minute limit. The announcement is scoped to Lambda Managed Instances only. If your functions are on standard Lambda provisioning, nothing changed for you.

That last one matters. Lambda Managed Instances is a newer provisioning model that AWS introduced separately. LMI pricing is closer to EC2, where you pay for provisioned capacity, than to standard Lambda pricing, where you pay per request plus GB-seconds. If you are evaluating this change, you are evaluating LMI as much as the timeout.

What moves from Step Functions to a single Lambda

In an earlier piece on Step Functions versus Lambda for AI orchestration, I argued that past the 15-minute Lambda ceiling, the right answer is orchestration, not function-to-function hopping. That argument was correct for its ceiling. The ceiling moved.

Concretely, these workloads now fit in a single async Lambda where they used to need Step Functions or chained Lambdas coordinated by hand:

Batch inference over a document collection. An agent that reads 40 PDFs from S3, calls Bedrock on each for summarization and entity extraction, and writes results back. That is a 20-40 minute job that used to need one Lambda per document plus a Step Functions Map state to coordinate them. Now: one Lambda triggered by an SQS message, iterating through documents in-process.

Multi-step research agents. An agent that takes a topic, runs 10-15 tool calls (search, retrieve, reason, search again), synthesizes findings, and produces a report. Total time 30-60 minutes for a deep query. Used to need Step Functions with parallel branches and manual state. Now fits in one async Lambda.

Codebase or repository analysis. Clone a repo, walk the file tree, analyze each file with an LLM, aggregate findings. 20-40 minutes for a mid-size repo. Was hard to fit in Lambda at any granularity. Now a single async job.

The pattern to notice: all three are workloads where a client submits a task and expects to check back later. The user is not waiting on a synchronous HTTP response. That is the workload category where 90-minute Lambda earns its keep.

What does not move, and why

Interactive chat with a long-running agent still needs the async pattern.

If a user types "research this topic for 40 minutes and give me a report," you cannot have API Gateway hold the connection while Lambda works. API Gateway caps at 29 seconds. Even if it did not, synchronous Lambda still caps at 15 minutes. The 90-minute change is irrelevant to the sync path.

You still need the same async pattern I described in the Step Functions piece: a sync endpoint accepts the task, drops it on SQS, returns a job ID, and the client polls or gets notified via WebSocket when done. What changed is that the worker on the other end of SQS can now be one Lambda instead of a Step Functions state machine. The orchestration around user interaction is unchanged.

Multi-approval workflows still belong in Step Functions.

If your agent workflow includes a human approval gate mid-flight, the answer is not "one 90-minute Lambda that sleeps waiting for approval." That is an anti-pattern for cost and reliability. Step Functions with a wait-for-callback pattern is still the right shape. Duration and orchestration are two different problems and this change only solves one of them.

Anything requiring persistent connections to external services still belongs in Fargate or ECS.

Lambda is not the right runtime for a long-lived WebSocket client, a database replication worker, or an agent that maintains a persistent session with an external LLM provider. Those still belong on ECS or Fargate. The 90-minute ceiling does not change that answer.

The pricing gotcha nobody will talk about

Lambda Managed Instances bills differently from standard Lambda. Standard Lambda is pay-per-request plus GB-seconds of execution time. Simple, predictable, scales to zero.

LMI is closer to EC2. You provision capacity, you pay for that capacity, and you can run multiple concurrent invocations per instance. The tradeoff: better throughput per dollar for steady workloads, worse for bursty workloads that could otherwise scale to zero.

If your 90-minute async agent runs three times a day, the LMI capacity is idle for 22 hours. You are paying for that idle time. Standard Lambda, when it worked for your workload, would not have charged you for it.

The math to run before adopting: what is your invocation frequency, average duration, and concurrency requirement?

• Workload that used to fit in 15 minutes and runs 100 times a day: standard Lambda is almost certainly cheaper.
• Workload that used to require Step Functions plus 8 chained Lambdas: LMI might be cheaper and simpler.
• Workload that runs 3 times a day for 60 minutes each: you might be better off in Fargate Spot.

This is the cost containment guardrail in a new form. The old failure mode was runaway agent loops. The new failure mode is provisioned capacity you are not using.

Three patterns worth using

If you are evaluating 90-minute Lambda for your agent workloads, three specific patterns are worth adopting.

Pattern 1: Split sync-thin, async-fat. Your synchronous endpoint, the user-facing API, stays a thin acceptor. It validates the request, drops it on SQS, and returns a job ID. The async worker, the 90-minute Lambda on LMI, does the actual work. This was already the right pattern for anything longer than a few seconds. The 90-minute ceiling makes the async side able to do more work without further orchestration.

Pattern 2: Reach for Step Functions when the workflow needs coordination, not when it needs duration. The old rule "past 15 minutes, use Step Functions" was really a proxy for "you need Step Functions." Now those are two separate decisions. Duration goes to Lambda when possible. Step Functions is reserved for workflows that genuinely need orchestration: human approval gates, parallel branches with rejoin, complex retry policies, or multi-step state that has to survive worker restarts.

Pattern 3: Set a hard concurrency ceiling on your LMI instances. Because LMI supports concurrent invocations per instance and steady provisioning, the failure mode "our agent spawned 500 concurrent long-running jobs and blew the budget" is real. Set a maximum concurrency at the LMI configuration level. Set an SQS queue depth alarm. Do not trust the agent's design to bound itself. That is the pattern from the agent-readiness piece applied to this specific new runtime.

The bottom line

The 90-minute timeout is a real capability change, but a scoped one. Async batch inference, multi-step research agents, and repository-scale analysis workloads that used to require Step Functions plus multiple chained Lambdas can now be single Lambdas. That is genuinely simpler and often cheaper if the workload runs frequently enough to keep LMI capacity utilized.

The change does not help interactive chat with long-running agents. It does not help cold-start-heavy workloads that load large models. It does not help workloads that were fine at 15 minutes and are now going to pay for LMI capacity they do not need.

The architectural work is the same as it has always been: match the runtime to the workload's shape, not to the runtime's ceiling. AWS raising the ceiling is useful. Deciding which workloads earn a seat on the new runtime is still on you.

---

Written by Ramesh Nori. If this was useful or you have feedback, reach me at cloudbuckle@gmail.com.