AWS Lambda Extends Function Timeout to 90 Minutes on Managed Instances

AWS announced a significant enhancement to AWS Lambda Managed Instances (LMI), increasing the maximum execution timeout to 90 minutes (5,400 seconds) for asynchronous invocations and event source mappings (ESM). This represents a sixfold increase over the longstanding 15-minute execution limit. The extended timeout applies across all AWS regions where Lambda Managed Instances are deployed, while synchronous invocations remain bounded by the standard 15-minute limit. For practitioners, the 15-minute barrier has historically been the primary inflection point forcing teams away from serverless architectures. Tasks exceeding 15 minutes—such as large-scale extract-transform-load (ETL) data pipelines, distributed machine learning inference batches, video transcoding, and Monte Carlo financial simulations—previously demanded complex workarounds. Engineering teams had to either maintain bespoke task-splitting logic orchestrated by AWS Step Functions or stand up dedicated container infrastructure on Amazon ECS, EKS, or AWS Batch. With a 90-minute ceiling, developers can execute extended computational jobs natively in Lambda with zero code rewrites, preserving existing runtime configurations, IAM execution roles, and VPC attachments. This release represents a continued convergence between serverless paradigms and heavy-duty compute elasticity. Cloud providers have steadily dismantled the traditional boundaries of Function-as-a-Service (FaaS). By layering this extended runtime onto Lambda Managed Instances—which support request concurrency per node and leverage EC2 pricing advantages—AWS is positioning serverless not merely as an event-routing glue layer, but as a viable computational substrate for resource-intensive data processing and generative AI workflows. It effectively bridges the operational divide between lightweight functions and long-running batch containers. In practice, leveraging the 90-minute timeout requires careful tuning of downstream messaging systems and architectural dependencies. When configuring event source mappings with Amazon SQS, teams must adjust queue visibility timeouts to at least six times the function execution timeout to prevent duplicate inflight message deliveries during extended processing cycles. Furthermore, while function handler execution can now span an hour and a half, the runtime initialization (Init) phase remains capped at 15 minutes. Teams operating mission-critical workloads should also integrate extended execution windows with checkpointing mechanisms and durable workflows to protect against compute interruptions, ensuring tasks can recover state without restarting from scratch.