AWS Lambda raises event-source timeout to 90 minutes on managed instances

AWS has raised the maximum execution timeout for Lambda functions on managed instances from 15 minutes to 90 minutes, a sixfold increase that applies to asynchronous invocations and event source mappings. According to a dev.to analysis of the change, which AWS announced on its Compute blog a few days earlier, the update removes one of the longest-standing constraints on serverless workloads.

A limit that stopped keeping up

Lambda launched in 2014 with a five-minute timeout, which AWS extended to 15 minutes in 2018 as event-driven microservices took off. The dev.to write-up traces how the picture changed after that: by 2025 and 2026, workloads had shifted heavily toward data processing, large-scale media transcoding and generative AI reasoning, and the 15-minute ceiling turned into a recurring obstacle.

The workloads that outgrew 15 minutes

The analysis identifies five patterns that regularly pushed past the old limit:

Media processing: speech-to-text transcription and high-definition video transcoding commonly require 20 to 60 minutes of uninterrupted processing.

Financial computation: Monte Carlo risk simulations, portfolio modeling and bond performance calculations that demand large amounts of memory and sustained processing.

ETL and data pipelines: batch jobs that ingest multi-gigabyte files or pull data from slow external partner APIs during peak hours.

AI inference and reasoning: batch evaluations, multi-step LLM reasoning chains and synthetic data generation tasks that fit Lambda's CPU and memory allocations but exceed its clock.

Web data extraction: crawlers that scrape unstructured catalog data from third-party endpoints with limited throughput.

The fine print

The 90-minute timeout is not a universal switch for every Lambda function. It operates under specific architectural constraints:

Only Lambda managed instances (LMI) qualify. Standard on-demand Lambda functions remain limited to 15 minutes.

Invocation type matters. The new window covers asynchronous invocations (InvocationType='Event') and event source mappings, with support for individual execution steps of durable functions.

Synchronous calls stay capped. If a client invokes a function synchronously — via Amazon API Gateway, an application load balancer or direct SDK calls — Lambda strictly enforces the 15-minute maximum even when the function timeout is configured at 5,400 seconds.

The init phase is unchanged. Cold-start container provisioning and runtime initialization remain limited to 15 minutes.

ESM coverage is partial. The 90-minute window applies to Amazon SQS, Amazon Kinesis, Amazon DynamoDB Streams, Amazon MSK and self-managed Apache Kafka, while event source mappings for Amazon MQ and Amazon DocumentDB stay at 15 minutes.

Pricing carries no surcharge, with standard managed-instance compute rates applying. The author nevertheless recommends reviewing costs carefully, noting that the billing model differs from standard Lambda.

How to set it

The timeout is configured through the same mechanisms as before, just with a higher ceiling of 5,400 seconds. In the AWS console, it lives under a function's Configuration tab in General configuration. Via the CLI:

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

For CloudFormation or AWS SAM templates, the Timeout property accepts the new value. The dev.to author reports having verified the change in practice, with a function running for 16 minutes — past the previous hard limit.

Why it matters

The 15-minute cap has shaped serverless architecture for years, forcing teams to split long jobs across orchestrators or move them to containers on Fargate or EC2. A 90-minute window on managed instances lets many media, ETL, simulation and AI batch workloads stay inside Lambda's operational model instead. The exceptions are just as consequential: synchronous paths and several event sources remain capped at 15 minutes, so long-running work has to be routed through asynchronous or event-source triggers deliberately. For anyone building event-driven data or AI pipelines, this is a constraint removal that changes architecture decisions rather than a cosmetic limit bump.