For eight years, every AWS Lambda function lived under the same ceiling: 15 minutes, no exceptions. On September 9, 2026, AWS quietly broke that rule. Functions running on Lambda Managed Instances can now execute for up to 90 minutes when triggered asynchronously or through an event source mapping, a six-fold jump that AWS detailed in a Compute Blog post and a matching What’s New announcement.
The change sounds like a footnote. It isn’t. Lambda’s 15-minute cap has shaped how an entire generation of engineers architects data pipelines, batch jobs, and now AI inference workloads. Raising it to 90 minutes, even under narrow conditions, tells you something about where AWS thinks serverless computing needs to go next: toward longer, heavier, less bursty work, the kind that used to force teams onto ECS, Fargate, or a plain EC2 box the moment a job ran past a quarter hour.
What AWS Changed on September 9
The mechanics are specific. AWS increased the maximum timeout from 900 seconds to 5,400 seconds, a 6x jump, but only for functions running on Lambda Managed Instances (LMI) that are invoked asynchronously or through an event source mapping (ESM). Synchronous invocations, the kind that power an API Gateway request or a direct SDK call expecting an immediate response, stay capped at 15 minutes. AWS documentation states plainly that “for functions using AWS Lambda Managed Instances, asynchronous invocations and event source mapping invocations (except Amazon MQ and Amazon DocumentDB) support a maximum allowed value of 5,400 seconds (90 minutes),” a limit you can confirm in the Lambda timeout configuration docs.
Two event source mappings are excluded outright: Amazon MQ and Amazon DocumentDB. Functions wired to either of those still top out at 15 minutes, even on Managed Instances. AWS hasn’t published a technical reason for the carve-out, though the pattern lines up with how those two services handle connection pooling and polling behavior differently from Kinesis, DynamoDB Streams, or SQS.
The new limit is live across the Lambda console, the AWS CLI, the Lambda API, infrastructure-as-code tools like CloudFormation and Terraform, and the AWS Agent Toolkit. No opt-in program, no waitlist. If a function already runs on Managed Instances and fires asynchronously, the longer runway is available today.
Lambda Managed Instances, Explained
To understand why this matters, you need to understand what Lambda Managed Instances actually is, because it’s a meaningfully different product from the Lambda most developers know. AWS launched LMI on November 30, 2025, several weeks after re:Invent, though available announcements don’t confirm it debuted in a specific keynote session. LMI keeps Lambda’s programming model, its event triggers, and its per-invocation billing logic, but swaps the underlying execution environment. Instead of AWS silently managing ephemeral microVMs behind the scenes, customers select and provision the EC2 capacity that backs their functions.
That’s a structural shift. Traditional Lambda is famous for abstracting away servers entirely, you hand AWS a zip file or container image and never think about instance types. Managed Instances asks you to pick EC2 capacity, in exchange for control over performance characteristics, steadier concurrency at scale, and now, a much longer execution window. AWS still handles patching, scaling within your chosen capacity, and operational overhead, but the “serverless” abstraction gets a little less absolute.
It’s worth being precise about scope here: this timeout increase doesn’t touch standard, on-demand Lambda at all. If your functions run the conventional way, nothing changes. The 90-minute window is exclusive to teams who’ve already opted into the Managed Instances execution model, which today is a smaller slice of the Lambda customer base than classic pay-per-invocation Lambda.
Why the 15-Minute Wall Existed Since 2018
Lambda launched at re:Invent in November 2014 with a 1-minute execution ceiling, tight enough that it mostly suited quick event handlers and glue code. AWS stretched that to 5 minutes not long after, and then, on October 10, 2018, tripled it again to 15 minutes, a change covered at the time by DevClass as a response to demand for bigger data transformation jobs, bulk batch processing, and heavier statistical workloads.
That 15-minute number held for nearly eight years. It became a design constraint baked into how teams build on AWS: split long jobs into chunks, checkpoint progress in DynamoDB or S3, chain functions through Step Functions, or give up on Lambda and move the workload to Batch, ECS, or Fargate. An entire cottage industry of workaround patterns exists purely to route around the 900-second wall, including long threads on AWS re:Post cataloguing chunking strategies, step function orchestration, and queue-based retries.
Ninety minutes on Managed Instances doesn’t erase that constraint for everyone, since standard Lambda keeps the old ceiling. But for the subset of workloads already running on LMI, it removes a whole layer of engineering effort that existed only to dodge a timer.
The Fine Print: Async and Event Source Mapping Only
The restriction to asynchronous and ESM invocations isn’t an arbitrary AWS quirk, it reflects how these invocation types actually work under the hood. A synchronous call keeps a client connection open and waiting for a response, which is a poor fit for anything running past a few minutes regardless of platform. Asynchronous invocations and event source mappings, by contrast, queue work and process it independently of any waiting caller, which is exactly the pattern that benefits from a longer runway: a Kinesis stream backlog, an SQS queue full of transcoding jobs, a DynamoDB Streams trigger processing a batch of writes.
That means the 90-minute limit shows up in the AWS docs as a conditional, not a flat replacement. The Lambda quotas page now reads that code “can run for up to 15 minutes in a single invocation (up to 90 minutes for Lambda Managed Instances functions invoked asynchronously or through any event source mapping except Amazon MQ and Amazon DocumentDB).” Engineers reading the docs for the first time should expect to check both the execution model (standard vs. Managed Instances) and the invocation type before assuming they have the longer window.
What It Costs to Run Longer
Pricing is where Managed Instances diverges most sharply from the Lambda model most teams budget around. Standard Lambda charges per request plus GB-seconds of compute duration, a pure consumption model. LMI adds two more line items. AWS still charges the same Lambda request fee, $0.20 per million invocations, but on top of that customers pay standard EC2 charges for whatever capacity they provision, plus a compute-management fee AWS sets at 15% of the applicable EC2 On-Demand price for those instances.
That 15% surcharge is the trade-off for AWS handling patching, scaling, and the operational grind of managing EC2 fleets on your behalf, while still letting you apply Compute Savings Plans or Reserved Instance discounts to the underlying EC2 spend. For predictable, high-concurrency workloads, that combination can beat paying per-GB-second on standard Lambda at scale. For spiky, unpredictable traffic, provisioned capacity sitting idle between invocations can just as easily cost more than pure pay-per-use Lambda ever would.
| Attribute | Standard Lambda | Lambda Managed Instances |
|---|---|---|
| Max timeout (sync) | 15 minutes | 15 minutes |
| Max timeout (async / ESM) | 15 minutes | 90 minutes |
| Request charge | $0.20 per million | $0.20 per million |
| Compute billing | GB-seconds, per invocation | Standard EC2 instance pricing |
| Management fee | None | 15% of EC2 On-Demand price |
| Capacity control | Fully abstracted by AWS | Customer selects EC2 instance type |
| Savings Plans eligible | No | Yes, on EC2 portion |
| Launched | 2014 (GA) | November 30, 2025 |
Who AWS Is Targeting: AI Inference, Batch, and Finance
AWS names four workload categories explicitly in its announcement: data processing, media transcoding, financial calculations such as Monte Carlo simulations, and AI inference, alongside general batch jobs. That list reads like a checklist of workloads that regularly blew past 15 minutes and forced teams either to chunk their code awkwardly or abandon Lambda for a heavier compute service.
AI inference deserves particular attention given where cloud spending has drifted in 2026. Running a mid-size model over a long document, batch-scoring a large dataset, or chaining multiple inference calls inside an agent workflow can easily run past 15 minutes, especially without dedicated GPU acceleration. A 90-minute window gives teams room to run heavier inference jobs on Lambda’s event-driven model instead of standing up a persistent GPU-backed service for workloads that don’t run continuously.
Media transcoding and financial simulation share a similar profile: bursty, computationally heavy, and naturally triggered by an event (a file upload, a scheduled batch run) rather than needing an instant synchronous response. AWS’s own framing avoids naming AI inference as the single driver, listing it alongside the other three categories, which suggests this is a broad infrastructure move rather than a feature built to chase one trend.
How Lambda’s New Ceiling Compares to Azure and Google Cloud
Serverless compute limits are notoriously hard to compare cleanly because every provider structures execution, scaling, and billing differently. Still, the shape of the competitive landscape is clear enough to sketch out.
Google Cloud Run caps HTTP request timeouts at 60 minutes, configurable up to that ceiling, according to Google’s own documentation. Cloud Run Jobs, a separate product built specifically for batch-style execution rather than request-response traffic, supports much longer-running tasks and isn’t bound by the same request-timeout logic at all. Azure Functions is the most fragmented of the three: Consumption plans carry short, tightly bounded execution windows, while Premium and Dedicated (App Service) hosting plans support long-running or effectively unbounded execution, subject to configuration, per Microsoft’s hosting plan documentation.
Set against that backdrop, Lambda’s new 90-minute window on Managed Instances clears Cloud Run’s 60-minute request ceiling outright, while still falling short of what a purpose-built batch platform like Cloud Run Jobs or Azure’s Dedicated plans can do. The nuance that matters: LMI isn’t trying to become a container service. It keeps Lambda’s event integrations, its invocation model, and its developer experience, while borrowing just enough from provisioned infrastructure to stretch the runway. That’s a narrower, more surgical move than launching a new compute product from scratch.
| Platform | Max duration (request-driven) | Batch-oriented option |
|---|---|---|
| AWS Lambda (standard) | 15 minutes | Step Functions, AWS Batch |
| AWS Lambda Managed Instances | 90 minutes (async/ESM only) | N/A within Lambda |
| Google Cloud Run (services) | 60 minutes (configurable) | Cloud Run Jobs |
| Azure Functions (Consumption) | Short, plan-dependent | Premium / Dedicated plans |
| Azure Functions (Premium/Dedicated) | Long-running, configuration-dependent | Durable Functions |
Durable Functions Push the Runway to a Year
The 90-minute change also extends to steps inside Lambda durable functions, a checkpoint-and-replay pattern for long-running, multi-step workflows. According to AWS’s Managed Instances best-practices documentation, a multi-step durable execution invoked asynchronously can run for up to one year in total, though any individual step or invocation within that execution still obeys the per-invocation timeout, now 90 minutes on Managed Instances rather than 15.
That distinction matters for architects evaluating whether to migrate an existing Step Functions workflow onto durable functions with Managed Instances. The year-long ceiling applies to the overall execution, stitched together from many shorter steps, not to a single unbroken block of compute. Even so, fewer, longer steps mean less orchestration overhead and fewer checkpoints to manage compared with chaining together dozens of 15-minute invocations the old way.
Industry Reaction: Serverless Edges Toward Traditional Servers
Independent commentary on the change has been relatively sparse in the three weeks since the announcement, but InfoQ’s coverage captured the strategic read most clearly, framing the update as pushing serverless computing toward long-running workloads and blurring the boundary between a Lambda invocation and a conventional server, a characterization laid out in InfoQ’s analysis of the launch.
That framing lines up with what Managed Instances already represents before you even factor in the longer timeout. Customers provision EC2 capacity, pay EC2 rates, and cover a 15% management fee, none of which resembles the original, purely ephemeral, pay-per-millisecond Lambda pitch from 2014. Stack a 90-minute window on top and the product looks less like classic function-as-a-service and more like a managed, event-triggered compute layer sitting on customer-selected servers. AWS hasn’t published a named analyst assessment from a firm like Gartner or Forrester on the change, so the InfoQ framing remains the most substantive independent read available so far.
Market Impact and the FinOps Angle
Serverless computing is not a niche line item anymore. Market research estimates put the global serverless computing market at roughly $27.5 billion to $32 billion in 2026, according to figures compiled by Precedence Research, with multiple analyst firms projecting continued double-digit annual growth into the next decade as AI workloads and cloud-native adoption push more computing onto event-driven platforms. AWS, as the category’s originator and still its largest single vendor, has an obvious incentive to keep Lambda competitive as workloads get heavier and longer-running, rather than cede that traffic to container platforms or dedicated batch services.
The FinOps implications cut both ways. On one hand, removing the 15-minute wall for eligible workloads means fewer teams need to run parallel infrastructure (a Fargate cluster here, a Batch queue there) purely to handle jobs that occasionally exceed Lambda’s old ceiling, which can consolidate spend and simplify cost tracking. On the other, LMI’s EC2-plus-15%-fee pricing model requires far more careful capacity planning than pure consumption billing. A team that provisions Managed Instances capacity for a workload that turns out to be spikier than expected could end up paying for idle EC2 time it never needed to buy under standard Lambda’s per-invocation model. Cost teams evaluating the migration should model both scenarios before committing.
Competitive Comparison: Managed Instances vs. ECS, Fargate, and Batch
The most direct way to judge this change is against the AWS services teams already use to route around Lambda’s old ceiling. ECS and Fargate offer effectively unbounded execution time since they run containers rather than short-lived function invocations, but they come with more operational surface: task definitions, service configuration, and, for ECS on EC2, cluster management. AWS Batch is purpose-built for exactly the kind of long computational jobs AWS now name-checks for LMI, financial simulations, data processing, with mature queueing and job-dependency features Lambda doesn’t attempt to replicate.
What Managed Instances offers that none of those alternatives do is Lambda’s event integration surface without rewriting the trigger logic. A team with dozens of Lambda functions wired to SQS queues, DynamoDB Streams, and Kinesis shards doesn’t have to re-architect anything to get a longer runway, it opts into Managed Instances and gains 90 minutes for eligible invocations. That’s a meaningfully lower migration cost than porting the same workload to ECS task definitions or Batch job queues, even if the raw execution ceiling is still shorter than what those services allow.
Historical Context: From One Minute to 90 in 12 Years
Lambda’s timeout history reads like a slow, deliberate ratchet. One minute at launch in November 2014. Five minutes not long after, as adoption grew past simple event handlers. Fifteen minutes on October 10, 2018, a tripling that held firm for nearly eight years and became the defining architectural constraint of the serverless era. Now, 90 minutes, but only for a specific execution model and invocation type introduced less than a year ago.
Each jump tracked the same underlying pressure: customers pushing heavier, longer workloads onto a platform originally designed for quick, stateless event handlers. The difference this time is that AWS didn’t just raise the number for everyone, it built a new execution tier (Managed Instances) and attached the longer timeout there specifically, keeping standard Lambda’s economics and its 15-minute ceiling untouched. That’s a more conservative move than a blanket increase would have been, and it signals AWS still sees value in keeping classic Lambda’s purely ephemeral, consumption-priced model intact for the workloads that actually fit it.
Predictions: Where Serverless Timeouts Go From Here
- Standard Lambda’s 15-minute cap likely stays put through 2027. AWS has kept classic Lambda’s ceiling unchanged since 2018 and shows no sign of touching it again now that Managed Instances exists as the outlet for longer jobs.
- Expect Azure and Google to respond with their own long-duration serverless tiers. Cloud Run Jobs and Azure’s Premium plans already cover part of this gap, but a head-to-head answer to Managed Instances, with equivalent event-trigger integration, would close the remaining difference.
- AI inference will be the workload that pushes adoption of Managed Instances fastest. As agentic and multi-step inference chains get longer and more common through 2027, the 90-minute window gives Lambda a credible seat at a table it would otherwise lose to dedicated inference platforms.
- More AWS services will pick up a “Managed” tier that trades pure abstraction for longer limits and EC2-based pricing. LMI’s structure, a familiar programming model plus customer-controlled capacity, is a pattern AWS could extend to other serverless products facing similar duration ceilings.
- FinOps tooling built specifically for LMI’s hybrid pricing will emerge over the next year. The mix of per-request charges, EC2 rates, and a 15% management fee doesn’t fit cleanly into existing Lambda cost dashboards, creating an opening third-party cost tools are likely to fill.
Configuring the Longer Timeout
For teams already running functions on Lambda Managed Instances, extending the timeout is a configuration change, not a redeploy. Via the AWS CLI, it looks like this for an asynchronously invoked function:
aws lambda update-function-configuration \
--function-name my-managed-instances-function \
--timeout 5400The value is expressed in seconds, so 5,400 corresponds to the full 90-minute ceiling. AWS will reject the update if the function isn’t running on Managed Instances or if it’s configured for synchronous invocation only, in both cases the timeout still tops out at 900 seconds.
What This Doesn’t Change
It’s worth restating what stays exactly the same, because the scope of this update is easy to overstate. Standard, on-demand Lambda functions, the vast majority of functions running in production today, keep their 15-minute ceiling regardless of invocation type. Synchronous invocations on Managed Instances also stay capped at 15 minutes, so API Gateway-fronted functions expecting a direct response see no change at all. And Amazon MQ and DocumentDB event source mappings are excluded from the longer window even when everything else about the function qualifies. Teams should audit their invocation patterns carefully before assuming a blanket 90-minute runway applies.
Frequently Asked Questions
What is the new AWS Lambda timeout limit?
AWS Lambda functions running on Lambda Managed Instances can now run for up to 90 minutes (5,400 seconds) when invoked asynchronously or through most event source mappings, up from the previous 15-minute (900-second) limit, effective September 9, 2026.
Does the 90-minute timeout apply to all Lambda functions?
No. It only applies to functions running on Lambda Managed Instances that are invoked asynchronously or through an event source mapping (excluding Amazon MQ and Amazon DocumentDB). Standard Lambda functions and all synchronous invocations remain capped at 15 minutes.
What is AWS Lambda Managed Instances?
Lambda Managed Instances (LMI) is an execution model AWS launched on November 30, 2025, that keeps Lambda’s programming and invocation model but runs functions on EC2 capacity that customers select and provision, rather than on fully abstracted, AWS-managed microVMs.
How much does Lambda Managed Instances cost compared to standard Lambda?
Both charge $0.20 per million requests. Managed Instances adds standard EC2 instance pricing for the provisioned capacity plus a compute-management fee equal to 15% of the applicable EC2 On-Demand price. Standard Lambda instead bills purely by GB-seconds of execution with no separate instance or management charge.
How does Lambda’s 90-minute timeout compare to Google Cloud Run and Azure Functions?
Google Cloud Run request timeouts max out at 60 minutes, so Lambda’s 90-minute window on Managed Instances now exceeds it. Azure Functions varies by hosting plan: Consumption plans have short, tightly bounded windows, while Premium and Dedicated (App Service) plans support much longer or effectively unbounded execution depending on configuration.
Can Lambda durable functions run longer than 90 minutes?
Yes, at the workflow level. A multi-step durable function invoked asynchronously can run for up to one year in total, though each individual step or invocation within that execution is still bound by the per-invocation timeout, now 90 minutes on Managed Instances.
Why did AWS cap the old Lambda timeout at 15 minutes in the first place?
AWS raised Lambda’s execution limit from 5 minutes to 15 minutes on October 10, 2018, to support bigger batch processing, bulk data transformation, and statistical computation jobs. That 15-minute ceiling then held for almost eight years until the September 2026 Managed Instances change.
Should I migrate my workloads to Lambda Managed Instances for the longer timeout?
It depends on your traffic pattern. Predictable, high-concurrency workloads that regularly exceed 15 minutes are good candidates, since provisioned EC2 capacity plus Savings Plans discounts can be cost-effective at scale. Spiky, unpredictable, or low-volume workloads may still be cheaper on standard, pay-per-invocation Lambda, since Managed Instances can incur cost for idle provisioned capacity.
