AWS Lambda MicroVMs Add Stateful Sandboxes For AI-Generated Code

Lambda Gets A Stateful Sandbox Layer

The account comes from an official company announcement by AWS and does not include customer deployments, independent benchmark results or production incident data.

AWS has introduced Lambda MicroVMs, a new serverless compute primitive inside AWS Lambda for applications that need isolated execution environments for code generated by users or AI.

The service is aimed at a gap between virtual machines, containers and functions.

AWS says virtual machines provide strong isolation but can take minutes to start, while containers launch faster but share a kernel and require hardening when untrusted code is involved.

Functions are built for request-response workloads and are not designed for long-running interactive sessions that keep state across user interactions.

Lambda MicroVMs gives each end user or session its own isolated environment.

The environment can launch quickly, retain memory and disk state for the session, and pause at a lower idle cost when the user steps away.

The product is powered by Firecracker, the lightweight virtualization technology AWS says already supports more than 15 trillion monthly Lambda function invocations.

For developers building AI coding assistants, interactive code tools, data analytics platforms, vulnerability scanners or game servers with user scripts, the product reduces the need to operate custom virtualization infrastructure.

The service still leaves application teams responsible for packaging code, setting identity roles and deciding where untrusted code belongs in their workflow.

Firecracker Snapshots Replace Cold Starts

The operating model is image-then-launch.

Developers create a MicroVM Image by providing a Dockerfile and code packaged as a zip artifact in Amazon S3.

Lambda runs the Dockerfile, initializes the application and takes a Firecracker snapshot of the running memory and disk state.

Later environments start from the prepared snapshot rather than a cold boot.

AWS says this is intended to provide near-instant launch and resume for interactive sessions, including sessions large enough to involve multi-gigabyte working environments.

The service also has a distinct API surface from Lambda Functions.

AWS says Lambda Functions remain the right fit for event-driven request-response workloads, while Lambda MicroVMs is for multi-tenant applications that need a dedicated environment for each user or session.

The product does not replace conventional functions.

A company could keep Lambda Functions as an event backbone and use Lambda MicroVMs only for steps that execute untrusted code in isolation.

Lifecycle Controls Define The Cost Boundary

AWS describes lifecycle control as one of the product's main differences.

A running MicroVM can retain memory, disk and active processes during a session.

During idle periods, it can be suspended with memory and disk state preserved, then resumed when traffic arrives.

In the example described by AWS, an idle policy auto-suspended the environment after 15 minutes of inactivity and auto-resumed it on the next incoming request.

AWS also gives each MicroVM a maximum total runtime of 8 hours, with automatic suspension available after a configurable idle window.

Those controls are important for applications where users step away but expect their environment to come back with packages, loaded models and working files still available.

The trade-off is that teams need to design around session length, idle policy, authentication and state recovery rather than treating serverless as only stateless execution.

Regions And Limits Set The Rollout Shape

Lambda MicroVMs is available today in US East in N. Virginia and Ohio, US West in Oregon, Europe in Ireland and Asia Pacific in Tokyo.

The service runs on ARM64 architecture.

AWS lists a ceiling of 16 vCPUs per MicroVM, with memory and disk each capped at 32 GB.

AWS says the service is available first in named regions on ARM64 architecture, while teams outside those regions still need to evaluate latency, data-location requirements and compatibility before moving untrusted-code workloads onto the new primitive.

The public record still lacks customer deployments, independent benchmark results, production incident data or adoption counts for Lambda MicroVMs; the announcement also leaves teams to compare the available regions, ARM64 requirement, 8-hour runtime ceiling and 32 GB memory and disk limits against their own AI coding, analytics or security workloads.