AWS's serverless compute jumps from a 15 minute cap to an 8 hour ceiling, recasting a fence that used to push long running and AI agent workloads onto its own higher priced container services.
AWS just turned a 15-minute product limit into an 8-hour one, and the size of that jump matters more than the announcement suggests. Lambda, the serverless computing service that has defined "function-as-a-service" since 2014, can now run a single invocation for up to 8 hours, according to AWS's own what's-new page. The previous ceiling was 15 minutes. That is a 32x change to a limit that has shaped how teams architect on AWS for a decade.
The new execution environment is called Lambda MicroVMs, and The Register's coverage of the launch frames it for untrusted code, AI agents, and any long-running task. MicroVMs are lightweight, sandboxed virtual machines in the Firecracker lineage: a stripped-down hypervisor AWS built specifically to spin up isolated compute quickly. Calling them "serverless" still works, but only because AWS is keeping that word. The runtime characteristics now sit on top of a different piece of real estate.
For most of Lambda's life, the 15-minute cap was a quiet but decisive architectural boundary. Anything that needed to run longer (a batch job, a data pipeline stage, a long polling loop, an AI agent that could plausibly wait minutes for a model to finish) was forced to graduate to a different AWS product. ECS and Fargate, AWS's container and managed container services, became the default. Those services have always been priced differently from Lambda, with billing tied to the lifetime of a container rather than the millisecond ticks of a serverless function. The cap was not, primarily, a technical limit. It was a fence.
The 8-hour jump removes that fence for almost every realistic long-running workload. AI agents that need to keep a session alive, sandboxed execution of user-submitted or model-generated code, batch transforms, scheduled jobs that cross the 15-minute mark: all of these now fit comfortably inside a single Lambda invocation. The 32x change is large enough that "serverless" and "container" stop being useful as competing categories for this class of work. They are now adjacent slots on the same menu.
This reads like a product launch, but it is a pricing-tier policy. AWS is publicly dismantling the boundary that pushed long-running workloads to its own higher-margin container services, and it is doing so in a window where the loudest demand is for "AI agent" infrastructure. The framing is generous. The effect is recapture.
That does not mean the launch is cynical. The technical lift to push Lambda to 8 hours on Firecracker-style microvirtualization is real. Cold-start behavior, memory pricing, and concurrency ceilings all change when a function can run for a workday. The honest read is that the technical capability and the policy move arrived in the same release because both were overdue, and the AI-agent narrative gave AWS a clean reason to ship the change without openly admitting that a decade of internal pricing arbitrage was the constraint.
What builders actually gain is agency. An AI team can now host a model-driven workflow that takes minutes to think, then minutes more to execute, in a single Lambda invocation with no container, cluster, or scheduler to provision. A security team can run untrusted user-submitted code inside a Lambda MicroVM, getting isolation closer to a separate virtual machine than to a shared serverless function, without standing up a Fargate service. A data team can run a job that takes a few hours, billed per millisecond, instead of committing to a container that is paid for by the second. None of those teams have to negotiate with ECS or Fargate to get there.
The trade-offs are also real, and worth naming. Lambda is still billed per request duration, and at sustained 8-hour loads the math does not always beat EC2 (raw virtual machines) or Fargate, especially for work that is continuously busy rather than bursty. Cold starts still apply, and the memory and ephemeral storage ceilings are tighter than what a container gives you. Eight hours is a ceiling, not a guarantee of always-on behavior, so an actual long-running service still wants a container, a VM, or a managed runtime. Lambda MicroVMs improve isolation compared with the shared-function model, but they are not a substitute for hardware-level isolation in high-assurance contexts. And like everything in this corner of the AWS catalog, the deeper the use of Lambda's quirks, the harder it is to leave.
The next move to watch is whether Azure Functions and Google Cloud Run follow with a comparable duration jump. If they do, the FaaS-versus-container boundary is genuinely dissolving across the industry, and the "serverless" label will mostly be a billing model rather than a runtime category. If they do not, AWS has bought itself a two-year window in which long-running AI agent workloads are cheapest and simplest on Lambda, and the rest of the field is reacting. Either way, the cap that used to define Lambda is gone, and the architecture on top of AWS will not be the same.