AWS just shifted the serverless contract: Lambda Managed Instances (LMI) now permit 90-minute timeouts for asynchronous and event-source-mapping (ESM) invocations. That’s a six-fold increase over the old 15-minute asynchronous ceiling — and it changes what “serverless” can reasonably own.
This extension applies to asynchronous invocations and ESM consumers on managed Lambda instances, and to long-running steps when Lambdas are used inside orchestrated workflows (for example, with AWS Step Functions). Synchronous invocations remain limited to 15 minutes. Practically, that means you can run long-running jobs — batch transforms, media processing stages, long polling adapters — without ripping them out of Lambda and into ECS or EKS. But it also hands platform teams a new bill shock vector and an operational surface for retries, visibility, and lifecycle management.
Two related Lambda changes matter here. SnapStart support has been expanded beyond a single managed runtime to help reduce cold starts for heavier functions, including many packaged as container images (check AWS docs for current limits and exact platform support). SnapStart works by snapshotting the initialized execution environment so cold-start penalties are significantly reduced for supported runtimes and packaging formats. If you haven’t, skim the recent explainer on SnapStart for containers; this will accelerate adoption of container packaging in latency-sensitive serverless workloads. The net effect: container images + SnapStart + extended async timeboxes lets teams build long-lived, low-latency serverless components you used to reserve for fleets.
Opinion: this is the right call. AWS is reclaiming the “serverless for more” territory by giving teams primitives instead of gatekeeping. The platform now assumes responsibility for lifecycle, retries, and observability at longer durations — which is where it should be. The catch is teams that treat Lambda like a cheap VM: long-running functions mean large, accumulating billed durations and more complicated error semantics. Use this to consolidate legitimate long async tasks, not to run background daemons that belong in compute instances.
On the AI and model-serving front, Bedrock and related services added model catalog updates and new operational tooling for agents and knowledge integrations. Rather than naming specific vendor model versions, the important change is that AWS has pushed more agent-facing features: session binding and consent flows for agent interactions and document-level ACL controls for managed knowledge stores. Those additions are correlated: agents are getting more agentic and interactive, and AWS is adding identity and document-level access controls to avoid the classic “agent gets access to everything” problem. Good — but agent sessions plus session binding create another authentication surface you’ll need to audit and instrument.
Meanwhile, on the Kubernetes side, EKS Auto Mode announced changes to how storage attribute mutation is handled: teams should migrate away from brittle, annotation-based mutators and adopt the upstream, stable API primitives the platform recommends for declarative volume attribute changes. Annotation-based hacks break admission ordering, are hard to test, and lock teams into custom controllers; move your automation to the supported API before the announced deprecation takes effect.
Practical implications, fast:
- Long-running async Lambdas: consider LMI for ETL stages or long polling, but add cost guards, idempotency, and observability around duration and retries. Don’t move cron jobs wholesale; pick workloads with natural async semantics.
- SnapStart + containers: expect more teams to ship heavy bootstrapping in container images. That reduces the need for trickery like prewarm pools and custom init-sidecars. If you rely on init-time state, review SnapStart snapshot semantics.
- Bedrock agent identity and ACL APIs: integrate consent flows and session binding into your audit trail now; these are going to be compliance hooks for deployments that interact with PII or regulated data.
- EKS storage tooling: replace annotation-based mutators with the upstream volume-attribute APIs and test admission flows against your Auto Mode policies before the deprecation deadline.
Final thought: AWS is expanding the operational envelope of managed services rather than nudging teams toward more infrastructure. That’s powerful and correct — but it raises a simple rule of platform hygiene: when the platform gives you more time or capability, you must also harden lifecycle, cost, and security guardrails. If you don’t, these features will surface as incidents, not innovations.
Relevant reading: see the SnapStart container explainer (AWS Lambda SnapStart supports container-image functions) and our piece on platform attack surfaces for AWS model context servers (AWS MCP servers for Lambda, EKS, ECS, and Finch).
Sources
- AWS Compute Blog – AWS Lambda now supports a 90-minute function timeout for asynchronous and ESM invocations on Lambda Managed Instances
- AWS News Blog – Weekly Roundup: Claude Fable 5.1 on AWS, Amazon Linux 2027 preview, and Lambda SnapStart for container image functions
- AWS Lambda – AWS Compute Blog category
- Amazon Bedrock – AWS Machine Learning Announcements
- Amazon Bedrock | Artificial Intelligence – AWS Machine Learning Blog
- Amazon Elastic Kubernetes Service – EKS Auto Mode release notes
- EKS Distro – Official EKS-D distribution site and version matrix
- Daily AWS – 2026-09-09 headlines (Lambda 90-minute timeout, Graviton5 on Lambda Managed Instances, Bedrock Managed Knowledge Base APIs)