AWS Lambda adds MicroVMs: Firecracker-isolated, stateful sandboxes for untrusted code

AWS has launched Lambda MicroVMs, a new serverless primitive aimed at applications that must run code they didn’t write — AI coding assistants, interactive notebooks, data analytics tools, vulnerability scanners, and game servers executing user scripts. Each session gets its own dedicated environment built on Firecracker, the same micro-virtualization layer behind Lambda’s existing functions, giving VM-grade isolation with no shared kernel between tenants. The pitch is that it closes a long-standing gap: full VMs isolate well but boot in minutes, containers start fast but need heavy hardening to contain hostile code, and conventional functions aren’t built to hold state across a long interactive session.

The model is image-then-launch. You package a Dockerfile and code as a zip in S3, and Lambda builds the app and captures a Firecracker snapshot of the running memory and disk state. Every subsequent launch resumes from that pre-initialized snapshot rather than cold-booting, so even multi-gigabyte sessions come back online quickly. A running MicroVM keeps memory, disk, and live processes for the duration of a session — up to eight hours total — and can auto-suspend after a configurable idle window, snapshotting its state and resuming transparently on the next request. Networking is handled for you: each instance gets a unique endpoint and is reached over HTTPS using a short-lived auth token.

The trade-off worth flagging is the snapshot mechanic itself. Because every instance resumes from the same pre-baked image, apps that generate unique content, open network connections, or load ephemeral data at startup may need AWS-provided hooks to behave correctly. AWS positions MicroVMs as complementary to regular Lambda functions rather than a replacement — functions stay the right tool for event-driven request/response work, while MicroVMs handle the isolated, stateful execution of untrusted or AI-generated code.