AWS Lambda Expands Managed Instance Timeouts to 90 Minutes, Reshaping Serverless Batch Pipelines

AWS has expanded the maximum function execution timeout on AWS Lambda Managed Instances (LMI) from 15 minutes to 90 minutes (5,400 seconds) for asynchronous invocations and Event Source Mappings (ESM). The 6x increase applies directly to event sources such as Amazon SQS, Amazon Kinesis, and Amazon DynamoDB Streams, as well as async invocations paired with Lambda durable functions. Synchronous invocations continue to respect the traditional 15-minute ceiling, and the configuration is deployable across standard Infrastructure-as-Code tooling like CloudFormation and AWS SAM without requiring code changes. This update significantly alters architectural calculations for engineers handling compute-heavy, continuous processing. Workloads like video transcoding, extract-transform-load (ETL) data transformations, Monte Carlo financial simulations, and local model inference previously hit the 15-minute wall, compelling developers to orchestrate Step Functions state machines or migrate directly to Amazon ECS and AWS Batch. Extending the runtime window to an hour and a half allows developers to keep existing function logic intact while processing larger contiguous batches on dedicated, multi-concurrent EC2-backed capacity. Contextually, this shift reflects the ongoing convergence between traditional serverless execution models and elastic container infrastructure. As AI workflows and data-intensive pipelines demand longer execution loops without sacrificing automated scaling, cloud providers are dismantling historical serverless constraints. By combining extended timeouts with Managed Instances and durable function checkpointing, AWS is repositioning Lambda from a purely short-lived, ephemeral compute engine to a robust compute substrate capable of hosting sustained enterprise processing pipelines. In practice, adopting 90-minute executions requires careful operational tuning. Platform teams must adjust downstream queue configurations, such as ensuring SQS visibility timeouts are configured to at least six times the function timeout to prevent premature message reprocessing during throttles. Long-running functions also elevate the necessity of strict idempotency, credential refresh lifecycles, and resilient network connection retries to withstand transient downstream failures over extended runtimes. Teams should evaluate LMI instance sizing and concurrency models to balance pricing advantages against long-running execution costs.