Introducing Lambda MicroVMs - Isolated, Stateful Sandboxes for Running Untrusted Code on AWS

👋 Hey there, Tech Enthusiasts!

I'm Sarvar, a Cloud Architect who loves turning complex tech problems into simple solutions. I've worked with AWS, Azure, DevOps, Data, Analytics, Generative-AI and Agentic-AI building real systems for real companies. In this article series, I'll share what I've learned in a way that's easy to follow, whether you're experienced or just getting started.

Let's get into it! 🚀

On June 22, 2026, AWS launched Lambda MicroVMs. It is a new compute primitive inside Lambda that gives you a dedicated Firecracker virtual machine per user or session. It is not an update to Lambda functions. It is a different thing with a different model, different pricing, and different use cases.

If you are building anything where users or AI agents execute arbitrary code and you need strong isolation, fast startup, and persistent state this is what you reach for now.

What Existed Before and Why It Was Not Enough

Before this launch, if you needed to sandbox untrusted code on AWS, you had three options. Each one forced a compromise.

EC2 instances give you full VM isolation and persistent state. But they are not fast enough for interactive use. Between AMI boot, instance initialization, and user data scripts, you are looking at 30 seconds to several minutes before a user can do anything. That kills the experience for coding assistants or on-demand sandboxes.

Containers (ECS/Fargate) start faster and keep state while running. But containers share a kernel with the host. That shared kernel is a security boundary you cannot fully trust when running code from strangers on the internet. You can layer security on top, but the fundamental model is weaker.

Lambda functions give you real VM-level isolation (they already run on Firecracker) and start in milliseconds. But they die after 15 minutes. They are stateless between invocations. They follow a request/response model. You cannot give a user a persistent environment where they write code, run it, see the output, install a package, and run again all within the same session.

Teams building coding assistants, AI agent sandboxes, or multi-tenant notebook platforms had to stitch together custom solutions. EC2 with a lifecycle manager. ECS with heavy security configuration. Running Firecracker directly on bare metal. All of it was operational overhead solving a problem that should have had a managed answer.

What Lambda MicroVMs Actually Is

Lambda MicroVMs is that managed answer.

You package your application code and a Dockerfile into a zip archive, upload it to S3, and call the Lambda API to create a MicroVM image. Lambda executes your Dockerfile, starts your application, and captures a snapshot of the fully initialized environment.

When you need a sandbox for a user, you call run-microvm. Lambda launches a MicroVM from that snapshot with rapid startup.

Each MicroVM gets:

• Its own dedicated HTTPS endpoint (no load balancers or ingress infrastructure needed)


• Full VM-level isolation (separate kernel, no shared resources with other tenants)


• Persistent state for up to 8 hours (memory and disk survive suspend/resume)


• Automatic suspend when idle (you stop paying for compute)


• Automatic or programmatic resume when traffic arrives (picks up where it left off)


• Vertical scaling up to 4x the configured baseline CPU and memory (e.g., 2 GB / 1 vCPU baseline scales to 8 GB / 4 vCPU)

Users connect over HTTP/2, gRPC, or WebSockets. Authentication is handled through bearer tokens you generate via the CreateMicrovmAuthToken API.

The Mental Model Shift

This is important: Lambda MicroVMs is not request/response.

With Lambda functions, a request comes in, your code runs, it returns a response, the invocation ends. Scaling is automatic. You think in terms of individual invocations.

With Lambda MicroVMs, you spin up a persistent VM for a user or session. It stays alive. It has a dedicated URL. Multiple requests hit the same VM. State accumulates. The user installs a package, it is still there on the next request.

You manage the fleet yourself. You decide when to create a MicroVM, which user it belongs to, and when to tear it down. There is no automatic horizontal scaling. Your application owns that logic.

This is closer to managing a pool of servers than it is to writing Lambda functions. The difference is you do not manage the infrastructure underneath no AMIs, no instance types, no patching, no capacity planning for the host.

What It Looks Like in Practice

Here is the basic workflow using the AWS CLI. Command names below follow the API naming convention. Check the .