The 15-Minute Wall Just Got Six Times Taller

For years, every serverless developer lived under the same quiet tyranny. Your Lambda function had 15 minutes to finish its work, and not a second more. Hit that limit and your function was killed mid-task, sometimes leaving behind half-processed data and a cleanup headache. That single number shaped how we designed entire systems. We chopped big jobs into smaller ones, wired up Step Functions to orchestrate the pieces, or gave up on Lambda entirely and moved to containers we never really wanted to manage.

That wall just came down.

AWS Lambda now supports a 90-minute function timeout for asynchronous and event source mapping (ESM) invocations running on Lambda Managed Instances. That is a 6x jump from the old 15-minute ceiling, and it changes what the word "serverless" can honestly cover.

Why this matters more than the headline suggests

Numbers like "6x" are easy to skim past, so let me make it concrete. Picture the workloads that never fit inside 15 minutes.

A video platform transcoding a two-hour recording into multiple resolutions. A finance team running Monte Carlo simulations across thousands of scenarios. An ML pipeline running inference on a large batch of images. A nightly ETL job that pulls, cleans, and reshapes gigabytes of records before loading them into a warehouse. Every one of these used to blow straight past the timeout.

So teams reached for workarounds. They split the job into 14-minute slices and glued them back together with queues and state machines. They spun up Fargate tasks or EC2 instances just for the heavy lifting. They built retry logic to handle functions that died partway through. Each of these choices worked, but each one added moving parts. More code to maintain, more infrastructure to reason about, and more places for a 2 a.m. page to originate.

The 90-minute window makes a lot of that plumbing simply disappear. You run the job. It finishes. You move on with your day.

The catch you need to understand first

Here is where people are going to trip up, so let me be direct. This is not a blanket upgrade to every Lambda function in your account. The 90 minutes applies only to functions running on Lambda Managed Instances (LMI), which AWS introduced in late 2025.

LMI is worth understanding on its own. Instead of the classic Lambda model where each invocation gets its own isolated micro-environment, LMI runs your functions on managed EC2 capacity providers, including Graviton4 and compute-optimized instances. You still get the scale-to-zero simplicity that makes serverless pleasant, but you also get EC2 style pricing advantages and the ability to handle multiple concurrent requests per instance. Think of it as the bridge between lightweight functions and full container orchestration. The 90-minute timeout is the natural next step on that bridge.

If your function is running on classic Lambda, the 15-minute limit still applies. The long timeout is an LMI feature, full stop.

More gotchas worth knowing before you flip the switch

There are three things I would flag before you go bump every timeout to the maximum.

First, synchronous invocations still cap at 15 minutes. The 90-minute limit is for asynchronous and ESM invocations only. This makes sense when you think about it. Nobody wants an API call sitting open for an hour and a half waiting for a response. So this feature is aimed squarely at background and event-driven work, not request-response traffic. There are also a couple of specific exclusions on the ESM side, namely Amazon MQ and Amazon DocumentDB, so check those if they are part of your setup.

Second, longer runtimes widen the door for duplicates. When a function can run for 90 minutes, the window for retries and duplicate deliveries grows with it. If your function writes to a database, charges a card, or sends an email, running it twice by accident is a real risk. This is where idempotency stops being a nice-to-have and becomes a requirement. Powertools for AWS Lambda gives you tools to handle this, so an operation produces the same result even if it fires more than once. Build that in from the start rather than bolting it on after your first double-charge incident.

Third, do not set your timeout too close to your average duration. AWS calls this out specifically. If a function usually takes 80 minutes and you set the timeout to 85, a slightly slower run because of extra data or a laggy downstream service will get killed unexpectedly. Give yourself real headroom.

Turning it on is almost anticlimactic

After all that, the actual activation is refreshingly boring. No code rewrites. No runtime upgrades. You change a single configuration value.

In the CLI it looks like this:

aws lambda update-function-configuration \
  --function-name your-function \
  --timeout 5400

That 5400 is just 90 minutes expressed in seconds, since Lambda measures timeout in seconds. The same change works through the Console, the Lambda APIs, your IaC tooling, or the Agent Toolkit for AWS. If you use SAM, it is a one-line property:

Timeout: 5400

That is genuinely the whole story for enabling it.

The part that quietly unlocks the most

Here is a detail that deserves more attention than it usually gets. The increased timeout also applies to invocations inside Lambda durable functions. These use checkpoints to track progress and automatically recover from failures by replaying, skipping the work that already completed.

When invoked asynchronously, a multi-step durable execution can run for up to a full year. Read that again. A single logical workflow, spanning wait states and long-running steps, can live for 365 days. Each active step gets up to 90 minutes, while the overall execution lifecycle stretches far beyond that. Just remember that steps have at-least-once semantics, so one that fails before checkpointing may re-execute. Using execution names as idempotency keys is a clean way to guard against that.

The bigger picture

Lambda's timeout has climbed steadily since launch. Five minutes in 2014, 15 minutes in 2018, and now 90 minutes on LMI in 2026. Each jump pulls serverless deeper into territory that used to belong exclusively to containers and long-lived servers.

The line between "lightweight function" and "real compute" keeps getting blurrier, and that is a genuinely good thing for the rest of us. Less glue code. Fewer workarounds. More time actually building.

The 15-minute wall defined a generation of serverless design. It is strange, and a little freeing, to watch it fall.