Field report · · AgentConn Team
AWS Lambda MicroVMs: Sandbox Agent Code Without the Infra
AWS Lambda MicroVMs give agents VM-level isolation with zero infra. How they compare to E2B, gVisor, and DIY Firecracker.
Every team that lets an agent execute generated code hits the same wall: isolation. The agent needs to run untrusted code — install packages, write files, hit APIs — and you need a guarantee that a bad completion cannot escape its sandbox, read another tenant’s data, or compromise the host. Until last week, solving this meant either stitching together your own Firecracker stack or paying a startup for sandbox-as-a-service.
On June 22, AWS launched Lambda MicroVMs — a managed compute primitive that gives each agent session its own dedicated Firecracker virtual machine, with no shared kernel and no shared resources between users. No infrastructure to manage. No warm pool to babysit. The same isolation technology that powers over 15 trillion monthly Lambda invocations, now exposed as a first-class product for running untrusted code.
The Hacker News thread hit 366 points and 199 comments. The signal is clear: agent sandboxing just graduated from DIY project to managed cloud primitive.
Why Containers Are Not Enough
Standard Docker containers share the host kernel. Every container on a node uses the same Linux kernel for syscalls, separated only by namespaces and cgroups. A kernel vulnerability in one container can compromise all others on the same host.
For internal code this is an acceptable tradeoff — you wrote it, you trust it. For LLM-generated code, it is not. An agent that can write arbitrary Python and shell commands is, by definition, running untrusted code. A prompt injection that escapes the agent’s instructions can attempt privilege escalation, data exfiltration, or lateral movement through the shared kernel.
This is not theoretical. The agent supply chain attack surface has expanded dramatically in 2026. Every autonomous code-execution loop is an attack vector. The sandbox is the last line of defense.
As one comprehensive analysis put it: “Every hyperscaler reached for their strongest isolation primitive and pointed it at AI. None of them reached for containers.”
The Isolation Spectrum
Not all sandboxes are created equal. The field has converged on four tiers:
Tier 1 — Containers (Docker, runc): Fast startup, weak isolation. Shared kernel. Sufficient for trusted internal code, insufficient for agent-generated code.
Tier 2 — User-space kernels (gVisor): Intercepts syscalls in user space without touching the real kernel. Stronger than containers with less overhead than a full VM. Used by Google Cloud’s Agent Sandbox and Modal. Tradeoff: not all syscalls are perfectly emulated, which can cause compatibility issues.
Tier 3 — MicroVMs (Firecracker, Kata Containers): Each workload gets its own kernel via hardware virtualization. Firecracker achieves roughly 125ms boot time with approximately 5MB memory overhead. Compromising the sandbox requires exploiting the hypervisor, not a syscall implementation. This is the tier AWS Lambda MicroVMs operates at.
Tier 4 — Confidential compute (AMD SEV-SNP, Intel TDX): Hardware-encrypted memory isolation. Emerging but not yet practical for agent workloads.
For multi-tenant workloads where tenants cannot trust each other — which describes every agent code-execution service — Firecracker provides the strongest practical isolation.
What Lambda MicroVMs Actually Offer
Lambda MicroVMs are not a rebranding of Lambda Functions. They are a distinct compute primitive designed for stateful, long-running, isolated sessions.
Lambda MicroVM specs: Up to 16 vCPUs, 32 GB memory, 32 GB disk per MicroVM. Maximum 8 hours total runtime (vs. 15 minutes for Lambda Functions). ARM64 architecture (Graviton). Dedicated HTTPS URL per MicroVM with HTTP/2, gRPC, and WebSocket support. Auto-suspend on idle with state preservation, auto-resume on next request.
The lifecycle: You create a MicroVM Image by supplying a Dockerfile and a code artifact in S3. Lambda runs the Dockerfile, initializes your application, and takes a Firecracker snapshot. Every subsequent MicroVM launched from that image resumes from the pre-initialized snapshot rather than booting cold. This is how “near-instant launch and resume” works — it is snapshot restoration, not container startup.
The pricing: Consumption-based — per-second billing for vCPU, memory, snapshot storage, and data transfer. Suspended MicroVMs incur reduced costs while preserving state. This is the key economic difference from running your own Firecracker fleet: you do not pay for idle warm pools.
Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo). ARM64 only at launch.
The Agent Sandbox Pattern
The canonical pattern for agent code execution on Lambda MicroVMs:
- Control plane (your orchestrator — ECS, Step Functions, or a simple API) receives a code-execution request from the agent
- Launch or resume a MicroVM from a pre-built image containing the agent’s runtime (Python, Node, etc.) plus any base dependencies
- Execute the agent’s generated code inside the MicroVM via the dedicated HTTPS endpoint
- Capture results — stdout, stderr, return values, file artifacts
- Suspend the MicroVM if the agent session continues, or terminate if done
AWS has published integration guidance for Anthropic Claude-managed agents specifically — one MicroVM per Claude session, launched from a control plane in your AWS account. The pattern generalizes to any agent framework.
The critical property: each agent session is hardware-isolated. A compromised session cannot read memory, access files, or observe network traffic from any other session. This is not namespace isolation — it is separate virtual machines on separate kernels.
Lambda MicroVMs vs. the Alternatives
The agent sandbox market has four distinct layers. Lambda MicroVMs sit at a new intersection: managed-platform convenience with primitive-level isolation.
vs. DIY Firecracker
Running Firecracker yourself gives maximum control — custom kernels, custom networking, custom snapshot strategies. But the operational overhead is real: TAP interface management, CNI plugin overhead, warm pool economics, image distribution. As one HN commenter noted: “Networking kills microVM projects. Quietly.”
Lambda MicroVMs eliminate all of this. The tradeoff: you are locked to ARM64, limited to 8 hours, and bound to AWS’s networking model. If you need custom kernels or x86, DIY Firecracker is still the path.
vs. E2B
E2B is the sandbox-as-a-service specialist — Firecracker MicroVMs with SDKs that make code execution a three-line operation. E2B is cloud-agnostic, supports x86, and has the simplest developer experience in the category. If your team does not run on AWS, E2B is the strongest option. If you do run on AWS and want everything in your VPC, Lambda MicroVMs keep your data inside your account boundary.
vs. gVisor / Modal
Modal uses gVisor for isolation — syscall interception without full VMs. Modal is the only platform where a sandbox can hold a GPU. If your agent needs to run inference or fine-tune inside the sandbox, Modal is currently the only serious option. For CPU-only code execution, Lambda MicroVMs provide stronger isolation (hardware virtualization vs. syscall interception) at a comparable price point.
vs. Daytona
Daytona pivoted to AI code execution in 2026 with roughly 90ms cold starts — the fastest in third-party benchmarks. Daytona uses gVisor, which provides strong isolation but blocks GPU passthrough. If per-call latency is your primary constraint and you do not need hardware-level isolation, Daytona is competitive. If isolation strictness matters more than cold-start speed, Lambda MicroVMs win.
Decision Matrix
| Need | Best Option |
|---|---|
| Strongest isolation, AWS-native | Lambda MicroVMs |
| Cloud-agnostic, simple SDK | E2B |
| GPU inside sandbox | Modal |
| Lowest cold start | Daytona |
| Maximum control, custom kernels | DIY Firecracker |
| Existing Kubernetes cluster | gVisor on GKE |
What This Means for Agent Operators
If you are building or running agents that execute generated code, Lambda MicroVMs change the build-vs-buy math.
If you are on AWS already: Lambda MicroVMs are the default answer. Same account, same VPC, same billing, VM-level isolation, no infrastructure to manage. The existing DIY sandbox patterns (Tailscale + LangSmith + manual Firecracker) were always a means to an end — Lambda MicroVMs are that end as a managed service.
If you run multi-agent orchestration: Each agent in the queue gets its own MicroVM. Cross-agent contamination is architecturally impossible — no shared kernel, no shared filesystem, no shared network namespace.
If you run ambient agents: The suspend/resume capability is designed for exactly this pattern. An ambient agent that listens for events, executes code when triggered, and suspends between events. 8-hour runtime covers most business-day agent sessions. Suspended MicroVMs cost less than idle compute.
If you are evaluating agent security: The isolation question just got easier to answer. “Where does the agent’s code run?” → “In a dedicated Firecracker MicroVM with no shared kernel.” That is an auditable, defensible answer for compliance reviews.
The Bigger Picture
The sandbox layer is the fastest-growing segment of the agent infrastructure stack. In the last 90 days: E2B raised $33M, Daytona pivoted entirely to AI code execution, Modal shipped gVisor-based agent sandboxes, Google Cloud launched Agent Sandbox on GKE, and now AWS has shipped Lambda MicroVMs.
The pattern is unmistakable. Every hyperscaler and every well-funded startup in the agent tooling space has converged on the same thesis: agents that execute code need hardware-level isolation, not container boundaries. The question is no longer whether to sandbox agent code — it is which managed primitive to pick.
Lambda MicroVMs will not be the last entrant. But they represent the clearest signal yet that agent sandboxing is a first-class cloud product, not a DIY project. If you have been putting off the isolation question because “containers are probably fine,” this is the week to stop.