AWS Lambda MicroVMs: What They Are, Pricing (Running vs Suspended), How to Run Your First One From a Dockerfile, the Auth Token, Idle Policy and Snapshot Rules, and MicroVMs vs Fargate and AgentCore

AWS Lambda MicroVMs give each user, session or job its own small virtual machine, built from your Dockerfile and started from a snapshot in moments. Lambda suspends it when idle and resumes it with its memory and disk intact. They are made for running code you did not write: AI coding assistants, notebooks, build jobs and vulnerability scanners. You pay per second for the baseline you choose. On Graviton in US East that is $0.0000276944 per vCPU-second and $0.0000036667 per GB-second, about $0.126 an hour for the default 2 GB / 1 vCPU. The cost shock runs in your favor: a suspended MicroVM pays only snapshot storage, about $0.0002 an hour for 2 GB of state. That is more than 99% less than a running one, so the setting that decides your bill is how quickly idle MicroVMs suspend. You start one with three CLI calls: create-microvm-image, run-microvm, and create-microvm-auth-token for the token every request must carry.

Ethan's side project is a small coding-practice site where students run their own Python and JavaScript in the browser. He had been running every student's code on one shared server, which worked right up until a student wrote an infinite loop that took the whole thing down during a class. "I need everyone in their own box," he told Jake, "and I can't afford a server per student." Jake, who runs one shop, did the arithmetic anyway: "Thirty students, thirty boxes, all day?" Ethan shook his head. "Thirty boxes that go to sleep the moment they stop typing."

This guide explains Lambda MicroVMs in plain English, works out what they cost when running and when suspended, walks through the official first-MicroVM steps with the AWS CLI, and covers the idle policy, the snapshot rule that catches most people, the roles and tokens, and how MicroVMs compare with the other ways to run code on AWS. If Lambda is new to you, start with what AWS Lambda is.

What Lambda MicroVMs are, in plain English

Lambda now comes in three forms. Event Functions are classic Lambda: a handler that gets an event and returns a result. Web Functions run a Node.js web server for you. MicroVMs are the third: a whole small virtual machine running whatever your Dockerfile installs, given to one user, session or job at a time, with hardware-level isolation from every other MicroVM. All three share the same Firecracker virtualization underneath.

What makes MicroVMs different from just renting a server is the snapshot. When you build a MicroVM image, Lambda starts your application, waits until it is fully initialized, and saves a snapshot of its memory and disk. Every MicroVM you run from that image starts from the snapshot instead of booting, so it is ready almost instantly. When nobody is using it, Lambda suspends it, saving its current state, and stops charging for compute. When a request arrives, it resumes where it left off: same files, same running processes, same open editor tabs.

That combination targets one specific job that was awkward on AWS before: running code that is not yours, written by users or by an AI agent, where each person needs a fully isolated, stateful environment, most of them are idle most of the time, and nobody wants to manage a fleet of virtual machines.

Jake: "So it's a hotel room per guest, and housekeeping freezes the room when they step out."

Ethan: "And unfreezes it with the coffee still warm."

How MicroVMs work: images, MicroVMs, connectors and hooks

A MicroVM moves through the states PENDING, RUNNING, SUSPENDING, SUSPENDED, TERMINATING and TERMINATED; an image through CREATING to CREATED, or CREATE_FAILED with build logs in CloudWatch. The /run hook is the one you will use most: it receives a per-MicroVM payload (a tenant ID, a session's settings) at start, which is how one image serves many users.

Lambda MicroVMs pricing: running vs suspended

Prices in US East (N. Virginia), AWS price list of October 22, 2026:

You pay the baseline you configure for every second the MicroVM runs. If the workload spikes above it, up to 4x, you pay only for the extra vCPU and memory actually used, for the seconds it is used. Turned into hours, for the default size:

A MicroVM left running all month at baseline costs about $92 on Graviton. The same MicroVM suspended whenever its user is away, say running two and a half hours a day, costs a few dollars. A larger worked example: 100 developers each with a coding sandbox used 2.5 hours on 20 workdays, with six suspend-resume cycles a day, comes to about $1,241 a month: $12.41 per developer. Graviton is about 15% cheaper than x86 for the same size, so build for Arm unless your code needs x86.

How to run your first Lambda MicroVM, step by step

These are the official first-MicroVM steps, with the AWS CLI (a version recent enough to have the lambda-microvms commands) and an S3 bucket in a supported Region.

1. Create the build role. An IAM role trusted by lambda.amazonaws.com for sts:AssumeRole and sts:TagSession, with s3:GetObject on your bucket and logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents (add ecr:GetAuthorizationToken and ecr:BatchGetImage if your Dockerfile pulls from a private ECR repository).
2. Write the app and Dockerfile. A minimal Node.js server on port 8080:

   // app.js
   const http = require('http');
   http.createServer((req, res) => {
     res.writeHead(200, { 'Content-Type': 'application/json' });
     res.end(JSON.stringify({ status: 'ok', path: req.url }));
   }).listen(8080, () => console.log('Listening on port 8080'));

   # Dockerfile
   FROM node:24-alpine
   WORKDIR /app
   COPY app.js .
   EXPOSE 8080
   CMD ["node", "app.js"]

3. Zip and upload: zip app.zip app.js Dockerfile, then aws s3 cp app.zip s3://your-bucket/app.zip.
4. Build the image:

   aws lambda-microvms create-microvm-image \
     --name my-first-microvm-image \
     --code-artifact uri=s3://your-bucket/app.zip \
     --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
     --build-role-arn arn:aws:iam::123456789012:role/MicrovmBuildRole

   Check with aws lambda-microvms get-microvm-image --image-identifier my-first-microvm-image until state is CREATED. If it says CREATE_FAILED, the build logs are in CloudWatch under /aws/lambda-microvms/my-first-microvm-image.
5. Run a MicroVM with internet access in and out, suspending after 15 idle minutes:

   aws lambda-microvms run-microvm \
     --image-identifier my-first-microvm-image \
     --ingress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
     --egress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS" \
     --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300}'

   The response gives the microvmId, the endpoint and "state": "PENDING"; wait for RUNNING with get-microvm --microvm-identifier ....
6. Get a token and call it:

   aws lambda-microvms create-microvm-auth-token \
     --microvm-identifier mvm-01234567-abcd-ef01-2345-6789abcdef01 \
     --expiration-in-minutes 30 \
     --allowed-ports '[{"allPorts": {}}]'
   
   curl https://mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.us-east-1.on.aws/ \
     -H "X-aws-proxy-auth: TOKEN_FROM_THE_authToken_FIELD"

   The reply is your app's {"status":"ok","path":"/"}.
7. Clean up: aws lambda-microvms terminate-microvm --microvm-identifier .... Delete the image too if you are done, remembering its one-week minimum storage charge.

Ethan's version replaced the Node.js server with a small Python service that runs a student's code and streams the output; one image, one MicroVM per student, started when they open an exercise. The first class ran thirty of them at once, and one infinite loop only hurt its own author.

The idle policy: the setting that decides your bill

The idle policy has three required values:

• maxIdleDurationSeconds: how long a MicroVM can go without inbound traffic through its endpoint before Lambda suspends it. The minimum is 60 seconds.
• suspendedDurationSeconds: how long it can stay suspended before Lambda terminates it for good. Suspended state can be kept for up to 8 hours.
• autoResumeEnabled: whether a request to a suspended MicroVM wakes it automatically. With false, you call resume-microvm yourself.

Idle is measured by inbound requests, so background work inside the MicroVM does not keep it awake: a long build with no incoming traffic can be suspended mid-job if the idle time is too short. Match the value to the work. Interactive sandboxes do well at a few minutes; batch jobs should either receive progress polls or simply set maximumDurationInSeconds and terminate when done. Each suspend and resume costs a little snapshot I/O (about one cent for 2 GB), so suspending every 60 seconds for a user who types in bursts can cost more than staying awake. Five to fifteen minutes is the usual balance.

The snapshot rule: every MicroVM starts identical

Because every MicroVM from one image version resumes from the same snapshot, everything in memory at snapshot time is shared by all of them: random seeds, generated IDs, session secrets, cryptographic keys, and open network connections. If your app creates a secret key at startup, thirty students get the same key. The rules:

1. Generate unique values after a MicroVM starts, not during the image build, ideally in the /run lifecycle hook.
2. Use your language's cryptographically secure random number generator (CSPRNG), not a seeded one created at startup.
3. If your app uses OpenSSL, use the Lambda base container image that includes a snapshot-compatible build.
4. Re-check network connections after start and resume; AWS SDK clients usually reconnect on their own, database connections may not.

The same snapshot that makes start-up instant also captures the processes, files written during the build, and file descriptors, so anything you install in the Dockerfile is ready the moment a MicroVM starts.

Roles and tokens

• Build role: used while building images (S3 read, CloudWatch Logs). The /ready and /validate hooks run under it.
• Execution role (optional, passed to run-microvm): what the running MicroVM may do in AWS. Without one, there are no runtime logs in CloudWatch and no AWS access from inside, which is often exactly right for untrusted code. The /run, /resume, /suspend and /terminate hooks run under it.
• Auth tokens: port-scoped and short-lived (up to 60 minutes). Issue them from your backend per user and session, scope them to the ports the user needs, and never give users the AWS credentials that create them. A separate create-microvm-shell-auth-token issues tokens for shell access.

For code written by users or AI agents, start with no execution role and egress limited to what the sandbox really needs; add permissions only when a feature requires them.

Sizes and limits

• Lifetime: maximumDurationInSeconds from 1 to 28,800, so 8 hours at most per MicroVM.
• Tokens: up to 60 minutes each.
• Base images: Lambda-managed Amazon Linux 2023; versions move from AVAILABLE to DEPRECATED (60 days, still usable), EXPIRING (30 days, no new images), EXPIRED (cannot build or run), or RECALLED for critical security issues. Rebuild your images when a new base version appears.
• Regions: 14 as of October 22, 2026, after Asia Pacific (Hong Kong, Malaysia, Thailand) and Europe (Spain) were added.

Lambda MicroVMs vs Event Functions, Web Functions and Fargate

The question that decides it: whose code is it, and is the user there all the time? Your own code, short runs: Event Functions. Your own web app: Web Functions or Fargate. Someone else's code, per-user state, mostly idle: MicroVMs. Lambda Web Functions covers the middle option in detail.

Firecracker: the open-source microVM engine underneath (tutorial, Windows, macOS, gVisor)

When Lambda builds a MicroVM image, it runs your Dockerfile, starts your application and captures a Firecracker snapshot of the fully initialized state. Firecracker is the open-source virtual machine monitor AWS built for Lambda and Fargate and released under the Apache 2.0 license, and it is why people searching for Lambda MicroVMs also search for "Firecracker microVM tutorial". The short version of how it works: Firecracker uses the Linux kernel's KVM to run each workload in its own small virtual machine, with its own guest kernel, and leaves out everything a function or container does not need. It emulates only six devices (network, block storage, vsock, a memory balloon, a serial console and a minimal keyboard controller used only to stop the microVM), which is what makes a startup under 125 ms and a memory footprint under 5 MiB per microVM possible.

Where Firecracker runs, and where it does not:

This is the practical difference from Lambda MicroVMs: the managed service gives you Firecracker's isolation and snapshots with no KVM host, no .metal instance and no networking setup of your own, billed per hour of running or suspended time instead.

A Firecracker tutorial in five steps, as the project's getting-started guide runs it on a Linux host with KVM (it is for learning, not production, where Firecracker runs inside its jailer):

1. Check KVM access: [ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL". If it fails, add your user to the kvm group or grant access with setfacl.
2. Get the binary from the project's releases page (firecracker-<version>-<arch>.tgz), or build it from source with the project's devtool.
3. Get a guest kernel and a root file system: an uncompressed Linux kernel (vmlinux) and an ext4 image; the guide downloads both from the project's CI artifacts and adds an SSH key to the root file system.
4. Start Firecracker with an API socket: sudo ./firecracker --api-sock /tmp/firecracker.socket. It waits for instructions.
5. Configure and boot it over the API from a second terminal with curl --unix-socket: PUT /boot-source (kernel path and boot arguments), PUT /drives/rootfs (the ext4 image), PUT /machine-config (vCPUs and memory), a network interface backed by a tap device, then PUT /actions with {"action_type": "InstanceStart"}. A moment later you can SSH into the guest at its private address.

Firecracker vs gVisor, the other comparison people make, is a comparison of two different ideas rather than two products of the same kind:

Other alternatives sit on either side: QEMU is the general-purpose virtual machine monitor that Firecracker trims down (Firecracker is written in Rust and keeps only the minimal device model), and plain containers share the host kernel with no VM at all. If you want microVM isolation on AWS without running any of this yourself, that is the job Lambda MicroVMs now does.

Troubleshooting by symptom

create-microvm-image ends in CREATE_FAILED

Read the build logs in /aws/lambda-microvms/IMAGE-NAME. Common causes: the Dockerfile fails, the app never signals readiness, or the build role cannot read the S3 object.

No build logs appear

The build role lacks the CloudWatch Logs permissions, or none was given. Add logs:CreateLogGroup, CreateLogStream and PutLogEvents.

Requests to the endpoint are rejected

Every request needs a valid token in the X-aws-proxy-auth header, scoped to the port you call and not expired (60 minutes at most).

The MicroVM suspends in the middle of a job

Idle time counts inbound requests only. Raise maxIdleDurationSeconds for batch work, or send periodic requests while it runs.

Every MicroVM has the same random values or IDs

They were generated during the image build and captured in the snapshot. Generate them in the /run hook with a CSPRNG.

The aws lambda-microvms command does not exist

Your AWS CLI predates the service. Update the CLI to a current version.

The MicroVM disappeared after a few hours

It reached maximumDurationInSeconds (8 hours at most) or its suspended time ran out. Start a new one from the image; save user work to S3 if it must outlive the session.

The bill is higher than expected

MicroVMs are staying awake: check the idle policy, background polling that counts as traffic, and MicroVMs nobody terminated.

Frequently asked questions

At the end of the first month Ethan's MicroVM bill was smaller than the old shared server, because most of the thirty sandboxes spent most of the day asleep. Jake asked whether the students noticed the sleeping. "Only when they come back," Ethan said. "Their code is exactly where they left it."

Revision note. Written October 23, 2026, with Lambda MicroVMs prices from the AWS price list for US East (N. Virginia), the lambda-microvms API (version 2025-09-09) and the Lambda developer guide as they stood on that date. "Let sleeping dogs lie," the saying goes; with MicroVMs, letting them sleep is the whole saving.