A Look into Lambda MicroVMs

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.

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)

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

(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.

(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.

The four APIs

Each operation works as follows.

(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.

(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

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.

Restating those points gives the following.

(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.