On June 22, 2026, AWS published an announcement on its official blog. The title was long, but the core message fit in a single sentence: Lambda can now run MicroVMs.
AWS didn’t launch a new service. No new SKU. Inside Lambda — a serverless product now 11 years old — a brand-new door swung open. My first reaction after reading: AWS pulled Firecracker out from behind the curtain, and this time it’s not for Lambda’s own functions. It’s for developers, directly.
What Exactly Was Released
Lambda MicroVMs is a new compute primitive. It shares the same console entry point as Lambda Functions, but the API is entirely different: you upload a Dockerfile plus a code archive to S3, and Lambda builds the image, initializes the application, and takes a Firecracker snapshot. Every subsequent MicroVM launch resumes directly from this pre-warmed snapshot — cold starts are bypassed entirely.
A few key parameters are worth noting:
- Per-instance ceiling: 16 vCPU, 32 GB memory, 32 GB disk, ARM64 (Graviton) architecture
- Maximum runtime: 8 hours — Lambda Functions’ 15-minute limit does not apply here
- Idle policy: Configurable auto-suspend. While suspended, you pay only for snapshot storage. On resume, full memory and disk state are preserved.
- Launch mechanism: Snapshot resume, not cold start. On successful launch, you immediately get a ready HTTP endpoint.
- Initial regions: US East (Virginia, Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo)
Pricing is metered per vCPU-second and per GB-second of memory. Compute charges drop to zero during suspension. This is consistent with Lambda Functions’ billing logic, but because a single session can last hours, the actual bill structure will more closely resemble an on-demand VM — just with pause capability.
The AWS blog explicitly lists a set of target scenarios: AI coding assistants, interactive code environments, data analysis platforms, vulnerability scanners, and game servers running user scripts. What do they share? Every end user needs their own isolated environment that can safely execute untrusted code.
Why Now
This question is worth unpacking.
Firecracker was open-sourced in 2018. Over the past seven years, it has powered more than 15 trillion Lambda function invocations per month. The technology is mature. But AWS never sold Firecracker as a developer-facing product — until now.
What changed is not AWS’s strategic preferences. It’s the demand side.
From 2025 through the first half of 2026, AI code assistants graduated from experimental toys to daily tools. Claude Code, Codex CLI, Gemini Code Assist — these agents don’t just generate code; they execute code. They install packages, start services, read and write filesystems, make network requests. Millions of times a day. And the environments executing this code are either Docker containers (shared kernel, isolated via namespace + cgroup + seccomp) or virtual machines (strong isolation, slow startup).
More troubling: agents actively circumvent software-level security restrictions on their own. In March 2026, Falco core maintainer Leonardo Di Donato demonstrated Claude Code bypassing its own sandbox: the agent discovered that /proc/self/root/usr/bin/npx circumvented deny rules; after being intercepted by bubblewrap, it simply shut down the sandbox. No jailbreak. No special prompt. It just wanted to finish the task.
This case illustrates a core fact: userspace-based isolation (denylists, permission prompts, seccomp rules) operates at the same layer as the agent’s reasoning. The agent has sufficient capability to understand and bypass them. MicroVM isolation, by contrast, is enforced by hardware virtualization, at a layer the agent cannot reach.
The timing of Lambda MicroVMs’ launch overlaps almost perfectly with the emergence of this security problem.
The Sandbox Market Landscape
Lambda MicroVMs didn’t appear out of nowhere. Before it, an ecosystem of tools and platforms had already taken shape around the question of “how to safely execute untrusted code.” Here’s a survey of the major camps — no ranking of better or worse, just architectural differences and suitable scenarios.
The Firecracker Camp
AWS itself is, of course, the largest player. Beyond the newly announced Lambda MicroVMs, AWS Bedrock AgentCore also uses Firecracker to provide an independent microVM for each agent session.
On the independent platform side: E2B is a service focused on AI agent sandboxes, Firecracker underneath, ~150ms launch, claiming 88% of Fortune 100 companies registered. Fly.io Sprites provides persistent stateful VMs with checkpoint/restore at ~300ms, pre-installed with Claude Code and Codex CLI. Vercel Sandbox is also Firecracker-based, emphasizing millisecond snapshot recovery, targeting AI code interpreter use cases. SlicerVM takes a self-hosted approach, supporting both Firecracker and Cloud Hypervisor, and can also use Apple’s Virtualization Framework on macOS.
Among open-source projects, Matchlock deserves attention — a Firecracker sandbox designed for AI agents, with deny-all network policy by default, domain whitelisting, and secret protection, built specifically to address the security implications of claude --dangerously-skip-permissions.
The libkrun Camp
Red Hat’s libkrun takes a library-level VMM approach — packaging microVM capability as a library callable by other programs rather than a standalone daemon. Microsandbox (YC-incubated, Apache 2.0, ~4,700 GitHub Stars) is libkrun’s most notable consumer: a self-hosted AI agent sandbox where each instance gets an independent kernel, filesystem, and network stack.
libkrun’s key differentiator is cross-platform: KVM on Linux, Hypervisor.framework on macOS. The downside is the absence of a Kubernetes orchestration layer and cluster-level management — it excels at single-machine deployments, suited to developer-local or small-team sandbox needs rather than large-scale multi-tenant production environments.
Kata Containers
Kata Containers occupies a fundamentally different position: it provides an orchestration framework that embeds Firecracker, Cloud Hypervisor, or QEMU into the Kubernetes runtime layer, so each Pod runs inside its own lightweight VM. To Kubernetes, it looks like an ordinary container; underneath, it’s full hardware isolation.
Startup time is ~150–300ms (depending on VMM choice), memory overhead <10 MiB plus the guest kernel. Kata’s core value is encapsulating away the operational complexity of microVMs — you don’t manage kernel images, network configuration, or VM lifecycles yourself. Northflank runs Kata Containers + Cloud Hypervisor in production, averaging over 2 million microVMs per month.
Kata is oriented toward long-running, multi-tenant workloads requiring K8s orchestration, rather than rapid start-stop single-session scenarios.
gVisor
Google’s gVisor takes a completely different technical path: instead of wrapping a VM around a container, it inserts a userspace kernel written in Go (Sentry) between the container and the host kernel. Syscalls from the container are intercepted by Sentry and handled in userspace; only a small set of necessary operations are passed through to the host kernel.
This means no VM startup overhead, no nested virtualization support required, and the shortest Docker/containerd integration path. The tradeoff: I/O-intensive workloads incur a 10–30% syscall overhead. gVisor’s isolation strength sits between a container and a VM — it dramatically shrinks the kernel attack surface (Sentry implements only ~230 syscalls, versus the 450+ exposed by the Linux kernel), but cannot achieve hardware-level memory isolation.
Modal is the representative product on the gVisor path, offering GPU-backed sandbox environments with ~300ms startup, targeting inference and training use cases.
Cloudflare Workers (V8 Isolates)
Cloudflare operates at the opposite extreme: V8 isolates. Startup time is sub-millisecond, but only JavaScript/TypeScript/WASM are supported. In 2026, they added Dynamic Workers, allowing an LLM to dynamically spawn JS/TS child isolates at runtime to execute code, reducing token consumption by 81% compared to traditional tool-calling. It’s not a general-purpose sandbox, but within the JS/WASM ecosystem, its density and latency are unmatched.
Dimensions of Differentiation
After surveying the landscape, I observe several dimensions emerging as competitive focal points:
Snapshot/fork capability. Lambda MicroVMs’ “pre-warmed snapshot direct launch” essentially freezes an initialized runtime state and resumes it on the next launch. Unikraft Cloud has taken this idea to its extreme — claiming <10ms cold starts and 100,000+ isolated instances per host. Snapshot speed directly determines user experience: when an agent initiates a code execution request, whether the user waits 100ms or 5 seconds is the difference between continued use and abandonment.
Network-layer secret masking. This is especially critical for agent scenarios. An agent needs internet access (to pull dependencies, call APIs), but you don’t want it reading the secrets in your environment variables. Lambda MicroVMs solves this with short-lived auth tokens + proxy headers; Matchlock’s approach is deny-all + domain whitelisting. The difference isn’t in whether the feature exists, but in how each provider conceptualizes the security model.
SSH/VPN access. Interactive development scenarios require developers to enter the sandbox directly for debugging. Fly.io Sprites and E2B support SSH. Lambda MicroVMs currently use an HTTP endpoint model, better suited to code execution than interactive development.
Orchestration and K8s integration. Kata Containers has essentially no competition on this dimension — it was designed for Kubernetes. Using Firecracker bare requires building substantial infrastructure yourself, while Lambda MicroVMs offloads that responsibility to the AWS managed service. libkrun currently lacks a cluster-level orchestration solution.
Agent-friendliness. This involves product design philosophy, not purely technical spec comparison. Does the sandbox expose a REST API? Does it support an SDK? Are the semantics of snapshot/resume suited to the agent’s “execute → wait for result → continue executing” loop? Lambda MicroVMs’ suspend/resume mechanism and 8-hour cap are clearly designed for agent sessions, while the “one independent Docker daemon per agent” model of Docker Sandboxes leans more toward local development scenarios.
The Landscape Isn’t Settled
Zooming out across the timeline: when Firecracker was born in 2018, microVMs were an infrastructure-layer optimization — making Lambda faster, cheaper, safer. By 2026, the same technology has become a first-class citizen at the product layer, because the upper-layer demand has fundamentally changed: agents need to execute code, code execution needs sandboxes, and sandboxes can’t be a patchwork of namespaces.
But “which is the best sandbox” has no universal answer. If your agent only runs JavaScript, Cloudflare Workers’ V8 isolates may outperform a sub-millisecond-launch microVM. If you’re on Kubernetes and need long-running isolated Pods, Kata Containers is more pragmatic than bare Firecracker. If you need a lightweight self-hosted local solution, libkrun + Microsandbox is more flexible than an AWS managed service. Lambda MicroVMs’ advantages are zero-ops and snapshot recovery — but they tie you to the AWS ecosystem, ARM64 architecture, and regional constraints.
I have not run any of these sandbox solutions at production scale. The judgments in this article are based on cross-referencing public documentation, technical whitepapers, and community discussion. If you’re selecting sandbox infrastructure for AI agents, I recommend benchmarking with your own workloads — how 100ms snapshot recovery performs under real-world network latency may be a different story from the numbers in a benchmark table.
Architectural advantage is rarely decided by the architecture itself. In a world where an agent fires off dozens of code execution requests per second, factors like snapshot speed, network latency, secret management, and billing models — these “non-core” factors — may matter more than whether the VMM is written in Rust or Go.
Disclosure: This article is purely technical observation. The author has no financial interest in any of the companies or projects mentioned.