AWS Lambda Extends Timeout to 90 Minutes on Managed Instances, Unblocking Long-Running Workloads

AWS has announced support for up to a 90-minute (5,400-second) execution timeout for functions executing on AWS Lambda Managed Instances. The 6x duration expansion applies specifically to asynchronous invocations and event source mappings (ESM), while synchronous request-response invocations remain capped at the historical 15-minute ceiling. The feature requires no source code modifications, utilizing existing runtimes, execution roles, and networking topologies while extending the continuous runtime window for batch jobs, AI inference tasks, and durable executions. This update directly addresses one of the most pervasive design constraints in serverless architecture. Workloads involving heavy data transformations, model inference, and video rendering routinely exceed 15 minutes. In the past, hitting this limit forced architects into multi-tier workarounds: slicing tasks across step functions, offloading execution to AWS Batch or ECS tasks, or managing persistent container clusters. By eliminating these architectural splits, development teams can preserve the developer velocity, IAM integration, and automated event triggers of Lambda across an entirely new class of long-running operations. This development reflects a broader cloud industry convergence between Functions-as-a-Service (FaaS) and containerized compute platforms. As cloud providers evolve their compute fabrics—such as Google Cloud Run's extended runtimes and persistent instance modes—the traditional boundaries separating transient serverless functions from persistent background workers are rapidly disappearing. The introduction of longer lifecycles combined with durable function recovery mechanisms illustrates how serverless platforms are evolving from simple request-driven micro-handlers into robust execution engines capable of supporting modern enterprise data workflows and complex agentic AI pipelines. In practice, engineering teams adopting the 90-minute timeout must account for crucial downstream configurations. For SQS event source mappings, visibility timeouts must be adjusted appropriately—AWS recommends setting visibility timeouts to at least six times the function timeout to prevent premature message visibility while long-running batches process. Additionally, streaming sources such as DynamoDB Streams and Kinesis require careful tuning of batching windows and parallelization factors to avoid head-of-line blocking. Teams should audit existing asynchronous Step Functions and Fargate batch jobs to evaluate whether consolidating these pipelines into Lambda Managed Instances can simplify deployment pipelines and reduce ongoing infrastructure overhead.