AWS Lambda Expands Execution Timeout to 90 Minutes for Managed Instances

AWS has updated AWS Lambda to support function execution timeouts of up to 90 minutes for asynchronous and Event Source Mapping (ESM) workloads running on Lambda Managed Instances, multiplying the long-standing 15-minute threshold by six. Synchronous request-response invocations remain capped at 15 minutes. For platform engineers and backend architects, this capability directly targets common pain points in long-running batch computing. Previously, data processing, extensive file transformations, and multi-step AI reasoning loops that exceeded a quarter of an hour required partitioning logic across multiple chained invocations, managing state in external datastores, or migrating workloads entirely to AWS Batch or ECS. By removing this boundary on managed instances, teams can streamline backend architectures and retire bespoke execution workarounds. This shift reflects a wider evolution across cloud ecosystems where the distinction between event-driven serverless functions and persistent managed containers continues to dissolve. As modern workloads increasingly encompass agentic AI tasks and heavier data ingestion steps, hyperscalers are extending serverless abstractions to accommodate long-running, steady-state computation alongside pure micro-billing. Lambda's expansion follows recent platform enhancements such as isolated microVM runtimes and container image support, signaling that serverless infrastructure is adapting to match complex execution profiles rather than forcing workloads to fit rigid constraints. In practice, engineering teams must recognize that extended execution windows heighten operational risks around failure recovery and credential longevity. Because Lambda does not guarantee exactly-once processing, a 90-minute run substantially widens the vulnerability window for duplicate invocations or transient network interruptions. Practitioners should implement strict idempotency mechanisms—such as leveraging Powertools for AWS Lambda—and verify that temporary IAM session tokens and upstream database connections remain valid throughout the complete duration. Additionally, if workloads spend significant time idle waiting on I/O rather than computing actively, alternative patterns like Durable Functions or Step Functions remain critical to prevent unnecessary compute spend.