AWS Lambda Gets 90-Minute Timeouts and Graviton5 on Managed Instances

September 9, 2026. AWS hit two of Lambda’s oldest constraints in one day: the function timeout jumps from 15 to 90 minutes on Lambda Managed Instances (LMI), and the service gains Graviton5 instances (C9g, C9gd, M9g, M9gd) billed at up to 25% better compute than Graviton4. Why it matters: the architectural detour that thousands of teams built to dodge the 15-minute cap is now obsolete, and the line between serverless and EC2 just got thinner.

A quick recap: what Lambda Managed Instances are

Lambda Managed Instances, launched at re:Invent 2025, let you run Lambda functions on EC2 compute while keeping the serverless experience: AWS handles instance lifecycle, OS and runtime patching, routing, load balancing, and auto-scaling. The developer writes code; the infrastructure stays abstract.

The economic model is explicit. An LMI costs the on-demand EC2 price plus a 15% management fee and $0.20 per million requests — the duration charges native to Lambda are gone. Savings Plans and Reserved Instances apply, which do not exist on classic Lambda. In short, AWS has finally put a number on what “not managing servers” costs: 15% on top of EC2.

The positioning is clean: predictable or steady-state workloads that want serverless simplicity without paying Lambda’s per-millisecond premium move to LMI. Spiky, latency-sensitive workloads stay on classic Lambda.

The timeout goes from 15 to 90 minutes

The 15-minute limit was Lambda’s Achilles’ heel. Any job that outlasted it — video transcoding, Monte Carlo simulations, AI inference, financial calculations — forced teams to slice work into chunks, chain invocations, or abandon serverless for ECS, Batch, or a VM.

AWS now lifts the cap, but surgically. The 90-minute timeout — six times the old limit — applies only to asynchronous invocations and event source mappings (ESM), on LMI. Synchronous invocations keep their 15-minute ceiling. The distinction matters: a synchronous call is blocked on an HTTP response, while an asynchronous call can wait in a queue. It is exactly the right split.

The change also extends to Lambda durable functions, which can checkpoint and replay steps: a multi-step durable execution invoked asynchronously can now run for up to 1 year. That is the end of the hand-rolled state machine for long-running workflows.

Graviton5: the Arm cost argument

The second September 9 announcement plugs LMI into Graviton5. The C9g, C9gd, M9g, and M9gd types become selectable, with a claimed up to 25% compute improvement over Graviton4. You configure it at the capacity provider level: pin an instance type, or let Lambda pick automatically from its list based on the function’s architecture, memory, and memory-to-vCPU ratio.

The real stake is not raw speed but cost per unit of compute. Graviton has historically been AWS’s cost-reduction lever on EC2; bringing it to LMI means offering Arm pricing without leaving the serverless comfort zone. For a long, predictable workload — an overnight transcoding pipeline, a simulation batch — the combination of 90 minutes + Graviton5 + Savings Plans mechanically lowers the bill versus a classic 15-minute-capped Lambda or hand-managed EC2.

What this changes for teams

The architecture decision gets simpler in practice. A long asynchronous workload no longer needs re-architecting: it fits in one function. A low-latency synchronous workload stays on classic Lambda. A stable, predictable workload moves to LMI to capture EC2 pricing and Graviton5 compute.

The trade-off is a more complex mental model. AWS now stacks several execution planes — classic Lambda, Lambda on LMI async, LMI with a capacity provider — and the right pick depends on synchronous versus asynchronous, duration, predictability, and CPU architecture. It is no longer “serverless or not”; it is a four-dimensional menu. The learning curve is real, but it replaces workarounds that were far more expensive. The practical upshot is that fewer workloads need to leave the Lambda family at all.

How to configure it

The switch is deliberately simple, and that is the point. The timeout is set like any Lambda function, in seconds — 5,400 for 90 minutes:

aws lambda update-function-configuration \
  --function-name long-transcode-job \
  --timeout 5400

The catch is that this ceiling only applies when the function runs on Lambda Managed Instances and is invoked asynchronously or through an event source mapping. A synchronous invocation of the same function falls back to the classic 15 minutes. In other words, AWS did not relax Lambda as a whole; it created a second execution plane — longer and cheaper — alongside the first.

On the Graviton5 side, the choice happens at the capacity provider level: pin a C9g or M9g type, or let Lambda pick automatically from its list based on the function’s architecture (arm64), memory, and memory-to-vCPU ratio. The move from x86 to Arm is not always transparent: if a function ships native dependencies, you must provide an arm64 image or layer. That is the one real point of friction, and it deserves a test phase before you flip a production pipeline.

The durable functions note also deserves attention. Because a multi-step durable execution can now checkpoint and replay for up to a year when invoked asynchronously, the “long-running workflow as a single Lambda” pattern stops being a hack and becomes a supported primitive. Teams that built their own Step Functions orchestration or a bespoke state machine around the 15-minute ceiling can delete that layer outright — the orchestration code, the fan-out plumbing, and the retry logic all collapse into one durable function.

The net result is a finer trade-off than before. Classic Lambda taxes duration by the millisecond; LMI bills the instance. ECS forces you to run the cluster; LMI keeps the serverless abstraction. Every team can now pick its point on a cost/simplicity curve that did not exist a year ago — and that choice, more than the timeout number itself, is the real September 9 news. And keep the 15% management fee in view: that is the price of the abstraction. For a genuinely stable and predictable workload, hand-managed EC2 will always undercut it; LMI buys operational simplicity, not the lowest possible rate. The decision is therefore not binary but a gradient — the two September 9 announcements simply moved the break-even point further toward “serverless is fine here too.” That is a modest shift on any single workload, but multiplied across a fleet of long-running jobs, it compounds.

Verdict

If you run long asynchronous workloads — transcoding, simulations, batch inference — that you were slicing into 15-minute pieces, move them to LMI with the new timeout: you delete an entire class of orchestration code. If you have a stable, predictable workload you were reluctant to pull out of Lambda on cost grounds, try LMI with Graviton5 and a Savings Plan: that is where the bill drops most. If your traffic is spiky and latency-sensitive, stay on classic Lambda — the synchronous 15 minutes and scale-to-zero still make sense there.

References

• AWS — “AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances” (September 9, 2026)
• AWS — “AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances” (September 9, 2026)
• AWS — “Introducing AWS Lambda Managed Instances” (official blog)
• AWS — “Announcing AWS Lambda Managed Instances” (re:Invent 2025)