AWS Lambda MicroVMs Add Stateful Sandboxes For AI-Generated Code
AWS has introduced Lambda MicroVMs for isolated, stateful execution environments, giving developers Firecracker-backed sandboxes for user- or AI-generated code with runtime, region and resource limits.

Lambda Gets A Stateful Sandbox Layer
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.
That distinction matters for enterprise architecture because 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.
Per MicroVM, AWS lists a ceiling of 16 vCPUs, with memory and disk each capped at 32 GB.
The availability list gives developers clear first regions, but it also sets a deployment boundary for global products.
Teams outside those regions will need to decide whether latency, data-location requirements and ARM64 compatibility fit their applications before moving untrusted-code workloads onto the new primitive.
AWS has provided pricing through the Lambda pricing page rather than in the announcement text.
For enterprise teams, the unresolved operating issue is not whether the sandbox exists; it is whether the available regions, ARM64 requirement, 8-hour runtime ceiling and 32 GB memory and disk limits fit the AI coding, analytics or security tools they want to isolate.
















