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.
Top comments (0)