A Look into Lambda MicroVMs

tetutetu214 — Sat, 26 Sep 2026 02:26:22 +0000

Originally published on my blog, where the diagrams are interactive.

Introduction

On 2026-06-22, AWS Lambda gained a new unit of execution called MicroVMs (source: AWS What's New, checked 2026-08-24).
The name includes "Lambda", so this post looks into how it differs from the Lambda we have used so far.

In this post, I organize how MicroVMs differ from regular Lambda, containers, and virtual machines.

The technology behind Lambda

What Lambda needed

Lambda is a service that runs code from many unrelated customers packed together on a single physical server. Functions often finish in a few hundred milliseconds, so the execution environment cannot take seconds to start. And because each server is shared with many other customers, those environments must be isolated from each other.

(Source: NSDI '20 paper, checked 2026-08-24)

About MicroVMs

Meeting these requirements calls for a small virtual machine with only the minimum set of features: a MicroVM.

Creating a virtual machine takes two pieces: KVM (Kernel-based Virtual Machine), the virtualization feature (hypervisor) built into the Linux kernel, and a virtual machine monitor (VMM) that drives KVM to assemble the virtual machine. At the time, the standard VMM was QEMU.

However, QEMU is a VMM that builds a virtual machine emulating an entire real PC, so it could not produce the small virtual machines that were needed. AWS therefore built its own VMM, Firecracker, as open source, based on Google's open-source "crosvm". Firecracker creates only small virtual machines, and a virtual machine created by Firecracker is called a MicroVM. Lambda runs customer code inside these Firecracker MicroVMs.

(Source: NSDI '20 paper, checked 2026-08-24)

QEMU vs. Firecracker

Comparing QEMU and Firecracker on three points (how many fit on one host, startup time, and available features) gives the following.

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

Isolation boundaries of virtual machines

Besides virtual machines, containers are another way to isolate execution environments. Containers are light and fast, but everyone on the same server shares the host's single kernel. As a result, a single kernel vulnerability can affect other customers on the same host.

A virtual machine, on the other hand, has its own guest kernel. A MicroVM is also a virtual machine, so the same applies. Even if the kernel has a vulnerability, it does not cross the boundary to other tenants on the same host.

Here I compare where the boundary sits for virtual machines, containers, and MicroVMs.

(Source: Firecracker website and NSDI '20 paper, checked 2026-08-24)

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

Lambda functions vs. MicroVMs

Side-by-side comparison

As described above, Firecracker has long been one of the technologies behind Lambda, and regular Lambda code also runs in a MicroVM for each execution environment.

To see how they differ, I compared Lambda functions and Lambda MicroVMs.

Lambda functions vs. Lambda MicroVMs

Aspect	Lambda functions	Lambda MicroVMs
Execution model	Event-driven handler invocation	Connect to a long-running app through a dedicated HTTPS endpoint
State	Stateless in principle	Memory, disk, and processes kept for the session
Lifecycle	Managed by Lambda	Developer runs run / suspend / resume / terminate
Maximum duration	15 minutes	8 hours (total)
Billing unit	GB-seconds + requests, per millisecond	vCPU-seconds + GB-seconds per second + snapshots + data transfer
OS privileges	Restricted (no pseudo-terminal, pty)	Full OS capabilities

(Source: Lambda MicroVMs developer guide, checked 2026-08-24, as of general availability on 2026-06-22)

What the developer can manage

In addition, here is a diagram comparing which layers the developer can touch (and where AWS takes over) across on-premises, EC2, regular Lambda functions, and MicroVMs.

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

(Source: same as above)

The four operations

With MicroVMs, customers can directly perform four operations (run / suspend / resume / terminate) on a MicroVM, the virtual machine created by Firecracker.

run and terminate are called by the developer's application (backend) that embeds MicroVMs. suspend and resume are performed automatically by Lambda if you pass an idle policy at run time (stop after N seconds without traffic, resume when traffic arrives). They can also be called explicitly through the API (source: Running and using MicroVMs, "Idle policy configuration", checked 2026-09-05).

MicroVM state transitions

This diagram shows how the four operations move a MicroVM between states.

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

The four APIs

Each operation works as follows.
| Operation (CLI name) | Description |
| --- | --- |
| run (run-microvm) | Starts a MicroVM from the image snapshot and assigns a unique ID and a dedicated HTTPS endpoint |
| suspend (suspend-microvm) | Pauses the MicroVM while keeping its memory and disk state. No compute charges while suspended. Also happens automatically when the idle time is exceeded |
| resume (resume-microvm) | Resumes a suspended MicroVM exactly as it was. Automatic resume on incoming traffic can also be configured |
| terminate (terminate-microvm) | Terminates the MicroVM and releases all resources. It cannot be resumed afterwards. Also happens automatically when the maximum duration is exceeded |

(Source: Running and using MicroVMs, checked 2026-09-03)

What makes the four operations possible: snapshots

The foundation of these four operations is the ability to save and restore the entire contents of a MicroVM (memory and disk). When the image is built, the state right after the app starts is saved as a Firecracker snapshot, so run only has to restore it and does not reload dependencies. suspend saves the memory and disk at that moment and stops, and resume restores from there.

There are limits on what can be kept. A single MicroVM can stay in RUNNING and SUSPENDED for at most 8 hours in total. Memory has a baseline of 0.5–8 GB (up to 4x that at peak, with a maximum of 32 GB / 16 vCPU), and disk is up to 32 GB (source: Core concepts, MicroVM images, "MicroVM sizing", Running and using MicroVMs, "Key parameters", checked 2026-09-04).

Hooks

In addition to the four operations, hooks are also provided.

Hooks are not something the customer calls. They let Lambda call the customer's app over HTTP at each of the start, suspend, resume, and terminate points, and at the ready / validate points during the build. If you configure them in your app, you can insert your own processing at those points.

Hook	When it is called	Purpose
`/ready` (build time)	After the app starts	Signal that initialization is done and let the snapshot be taken
`/validate` (build time)	When the MicroVM is launched for validation after the build	Check that the app works correctly after resuming
`/run`	Right after start	Per-tenant initialization, generating unique values
`/suspend`	Right before suspend	Flushing writes, closing connections
`/resume`	Right before resume	Re-establishing connections, refreshing credentials
`/terminate`	Right before terminate	Flushing data, cleanup

(Source: Running and using MicroVMs and MicroVM images, checked 2026-09-03)

Concrete use cases

Listed use cases include development platforms such as browser IDEs and notebooks, data analytics platforms, AI coding agents, security scanners, and CI/CD (source: AWS Compute Blog, checked 2026-09-05).

Here I take the AI coding agent example and follow the whole flow, from the user's request to cleanup.

The flow in an AI coding agent

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

How it differs from other services

Giving each user a dedicated execution environment was, of course, already possible with EC2, containers, and Lambda functions. However, each has its own strengths, so you need to decide which one to use for a given requirement.

Here I prepared a diagram showing which requirements each approach can meet. Switching between approaches shows their strengths and weaknesses.

📊 Interactive diagram: this part has a diagram you can click through. See it on my blog →

Restating those points gives the following.

Option	Isolation	Startup	State retention	Fewer constraints
Virtual machines such as EC2	Strong (hardware virtualization)	Minutes (AMI boot and initialization)	Can keep state	High (choose duration, specs, and OS)
Containers	Shares the host kernel	Seconds	Can keep state	High
Lambda functions	Firecracker (but hidden)	Cold starts	15 minutes, stateless	Low (15 minutes, event-driven)
MicroVMs	Strong (Firecracker exposed)	Restored from a snapshot	Kept for up to 8 hours	Low (8 hours, ARM64, memory limit)

(Source: AWS News Blog, Lambda MicroVMs developer guide, checked 2026-09-05)

Summary

In this post, I looked into how MicroVMs, newly added to AWS Lambda, differ from the Lambda we have used so far.

I think the spread of AI is behind this release.
MicroVMs can be used to build execution environments for code written by AI agents. For that use, the ideal is an environment isolated per user, one that can be paused between turns of the conversation, and one that keeps its previous state and continues when asked to run something. I feel MicroVMs are the best option for that.

The MicroVMs created by Firecracker are a technology that has supported Lambda for a long time. What I personally found most significant is that developers can now handle the Lambda execution environment itself with their own hands through operations such as run and terminate, something that used to be AWS's responsibility.

Rather than a new feature, MicroVMs, newly added to AWS Lambda, felt to me like a redrawing of the line of responsibility between AWS and developers.

DEV Community: tetutetu214

A Look into Lambda MicroVMs

Introduction

The technology behind Lambda

What Lambda needed

About MicroVMs

QEMU vs. Firecracker

Isolation boundaries of virtual machines

Lambda functions vs. MicroVMs

Side-by-side comparison

Lambda functions vs. Lambda MicroVMs

What the developer can manage

The four operations

MicroVM state transitions

The four APIs

What makes the four operations possible: snapshots

Hooks

Concrete use cases

The flow in an AI coding agent

How it differs from other services

Summary