AWS Lambda MicroVMs are a new serverless compute primitive that gives you virtual-machine-level isolation, near-instant launch from a snapshot, and stateful execution you can suspend and resume. It runs on Firecracker, the same lightweight virtualization that already backs more than 15 trillion Lambda invocations a month. The short version: Lambda just grew the ability to hand each session its own dedicated, isolated, long-lived sandbox, and to do it without you managing any virtualization yourself.

If you have ever tried to safely run code your own application did not write, multi-tenant code execution, interactive notebooks, vulnerability scanners, you already know why this matters. The honest answer until now was "spin up containers or VMs and build the orchestration, isolation, and lifecycle plumbing yourself." MicroVMs collapse that into an API call.

What is actually new

Regular Lambda functions are stateless, short-lived, and event-driven. They are superb for that. They are also the wrong tool when you need a session that lives for minutes or hours, keeps state in memory, and isolates untrusted code at the kernel level. MicroVMs are a different primitive inside the same service, aimed squarely at that gap. AWS frames it as three capabilities that no single AWS compute service offered together before today.

1. VM-level isolation

Each session runs in its own dedicated MicroVM with no shared kernel and no shared resources between users. That is the Firecracker guarantee: untrusted code from one tenant is contained to its own environment, with no path to other environments or the host. Containers share a kernel; a MicroVM does not. For running code you did not write, that boundary is the entire point.

2. Snapshot-fast launch and resume

The model is image-then-launch. You build a MicroVM Image from a Dockerfile plus a code artifact in Amazon S3. Lambda runs the Dockerfile, initializes your application, and takes a Firecracker snapshot of the running memory and disk state. Every MicroVM launched from that image resumes from the pre-initialized snapshot instead of cold-booting. Even a multi-gigabyte interactive session comes back fast enough to feel live. This is the SnapStart idea taken to its logical end: you are not starting a process, you are restoring a running one.

3. Stateful, suspendable execution

A running MicroVM keeps its memory, disk, and processes across the session. When it goes idle it can be suspended with state intact, then resumed when traffic returns. Installed packages, loaded data, and working files are all still there. MicroVMs support up to 8 hours of total runtime and auto-suspend after a configurable idle window. This is the part that breaks the old stateless-serverless assumption, in a good way.

What it looks like to operate

Two CLI calls carry most of the workflow. First, build the image:

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

Build logs stream to CloudWatch under /aws/lambda/microvms/<image-name>, and the finished image shows up with its own ARN and version. Then launch a MicroVM from it:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda returns a unique MicroVM ID and a dedicated endpoint URL, with the application already running because it resumed from the snapshot. No networking to configure. The idle-policy is where the lifecycle control lives: how long to stay idle before suspending, how long to stay suspended before terminating, and whether to auto-resume on the next request.

Where it fits, and where it does not

Reach for MicroVMs whenStay on regular Lambda when
You run untrusted or user-supplied code and need kernel-level isolationYour code is trusted and the work is a short, stateless transform
A session needs to hold state in memory across minutes or hoursEach invocation is independent and finishes in seconds
You want per-user dedicated environments without running the fleet yourselfYou are fine sharing a managed execution environment
Idle periods are normal and you want suspend-resume instead of paying to idleTraffic is steady and request-response is the whole shape

MicroVMs are not a replacement for functions, and they are not a cheap way to run a 24/7 server. The 8-hour ceiling and the suspend-resume model are built for sessions: a coding sandbox a user opens and leaves, a scan that runs for ten minutes, an analytics job that churns for two hours and then goes quiet. If your workload is a constantly-busy long-running service, that is still ECS or EC2 territory.

The snapshot caveat worth knowing

Because every MicroVM resumes from a pre-initialized snapshot, anything your app does during initialization that assumes freshness can surprise you. Unique IDs generated at startup, network connections opened at boot, random seeds, or ephemeral data loaded once can all be frozen into the snapshot and reused across launches. This is the same class of gotcha SnapStart users already know: if it must be unique or fresh per session, generate it after resume, not during init. AWS exposes hooks for this, and you will want them for anything connection-oriented or security-sensitive.

The takeaway

Lambda MicroVMs are the clearest signal yet that serverless is done being only stateless and short-lived. You now get a managed Firecracker sandbox with real isolation, snapshot-speed starts, and suspend-resume state, exposed as two API calls and an idle policy. For anyone building multi-tenant code execution, this removes the hardest, least differentiated part of the job: the isolation and lifecycle plumbing. Build the product, let Lambda run the microVM fleet.

Read this next

For the AI and agent angle on the same launch, why MicroVMs are built for running AI-generated code, see the field notes at ercan.ai. For consulting on AWS, serverless, and platform work, or just to say hello, start at ercanermis.com.