AWS Lambda MicroVMs: Isolated, Stateful Sandboxes for AI and User Code

TL;DR: AWS Lambda MicroVMs (launched June 22, 2026) is a new serverless compute primitive that hands every user, session, or AI agent its own isolated Firecracker sandbox — with VM-level isolation, near-instant snapshot resume, and full memory + disk state preserved for up to 8 hours. It’s purpose-built for running untrusted or AI-generated code without managing virtualization, and it ends the old “pick two of isolation, speed, and state” trade-off.

---

What is AWS Lambda MicroVMs?

A MicroVM is a lightweight virtual machine. Lambda MicroVMs is a serverless service that launches one of these VMs on demand — one per user, per session, or per job — and hands you a dedicated HTTPS endpoint to talk to it. No servers, no clusters, no load balancers to manage.

It is not a new flavor of Lambda functions. Functions are short-lived, stateless, and event-driven. A MicroVM is a long-lived, stateful environment with a full operating system — you can install system packages, mount filesystems, and run a real HTTP server inside it. You control its lifecycle directly: launch, suspend, resume, terminate.

Underneath, it runs on Firecracker, the same VMM that powers Lambda’s 15 trillion-plus monthly invocations. Firecracker gives each MicroVM a real KVM-backed VM boundary — its own guest kernel, no shared kernel with other tenants — while staying small enough to start fast and pack densely.

---

Why Does It Matter?

If you run code you didn’t write — code from your end users, or increasingly code generated by an AI agent — you have always had to pick two of three:

• Containers: fast and cheap, but a shared kernel means weak isolation for untrusted code.
• Full VMs / EC2-per-tenant: strong isolation, but slow to start and you manage everything.
• Lambda functions: fast and managed, but stateless and capped at 15 minutes.

MicroVMs collapse that trilemma into one primitive: VM-grade isolation and near-instant start and state that survives idle periods. That is exactly the shape of the agentic moment — an AI coding assistant generates code that must execute somewhere with no access to the agent’s own credentials or memory, and the work often spans multiple steps with pauses in between.

The concrete win: an idle environment suspends (memory and disk frozen, no compute charge) and resumes intact when traffic returns. So a user can walk away from a notebook for an hour, come back, and their packages, variables, and files are still there — without you paying for an hour of idle compute.

---

How It Works

The lifecycle is image → run → suspend/resume → terminate:

  Dockerfile + code ──zip──> S3
          │
          ▼  create-microvm-image
   ┌──────────────────────────────┐
   │  Lambda runs your Dockerfile │
   │  starts your app, then takes │
   │  a Firecracker SNAPSHOT of   │
   │  the fully-initialized state │  ──> reusable MicroVM IMAGE
   └──────────────┬───────────────┘
                  │  run-microvm  (launch N from one image)
                  ▼
   ┌──────────────────────────────┐      dedicated HTTPS endpoint
   │   MicroVM (per user/session) │  <───  mvm-xxxx.lambda-microvm
   │   own kernel, memory, disk   │        .<region>.on.aws
   └───┬───────────────────┬──────┘        (HTTP/2, gRPC, WebSockets)
       │ idle              │ traffic
       ▼                   ▼
   suspend  ◄────────►  resume      (memory + disk preserved, up to 8h)
   (no compute charge)
       │
       ▼ terminate  (release all resources)

Because each MicroVM resumes from a pre-initialized snapshot, it skips application boot entirely — that is where the near-instant startup comes from. One image can launch many MicroVMs, so the expensive Dockerfile build happens once and every tenant gets a cheap, fast clone.

---

Hands-On: Step-by-Step

This walks through building an image and running a MicroVM with the AWS CLI. The commands live under the aws lambda-microvms namespace.

1. Create the IAM build role Lambda assumes during image creation. Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": ["sts:AssumeRole", "sts:TagSession"]
  }]
}

Permissions policy (replace the bucket name; add ecr:GetAuthorizationToken + ecr:BatchGetImage if your Dockerfile pulls from private ECR):

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::your-bucket-name/*" },
    { "Effect": "Allow",
      "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:*:*:*" }
  ]
}

2. Write the app and Dockerfile. A minimal HTTP server on port 8080:

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

# Dockerfile — your application layers only.
# The MicroVM OS comes from --base-image-arn, set separately in step 4.
FROM node:24-alpine
WORKDIR /app
COPY app.js .
EXPOSE 8080
CMD ["node", "app.js"]

3. Package and upload to S3:

zip app.zip app.js Dockerfile
aws s3 cp app.zip s3://your-bucket-name/app.zip

4. Create the MicroVM image. Lambda runs your Dockerfile, starts the app, and snapshots the running state:

aws lambda-microvms create-microvm-image \
  --name my-first-microvm-image \
  --code-artifact uri=s3://your-bucket-name/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

Poll until state flips from CREATING to CREATED (build logs land in CloudWatch at /aws/lambda/microvms/<name> on failure):

aws lambda-microvms get-microvm-image --image-identifier my-first-microvm-image

5. Run a MicroVM from the image, wiring ingress, egress, and an idle policy:

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}'

That idle policy suspends after 15 minutes idle, holds the suspend up to 5 minutes, and auto-resumes on traffic. The response carries the microvmId and an endpoint. Wait for RUNNING:

aws lambda-microvms get-microvm --microvm-identifier mvm-01234567-abcd-ef01-2345-6789abcdef01

6. Connect. Every request needs an auth token; mint one, then call the endpoint:

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-value>"
# {"status":"ok","path":"/"}

7. Clean up to stop charges and release resources:

aws lambda-microvms terminate-microvm \
  --microvm-identifier mvm-01234567-abcd-ef01-2345-6789abcdef01

---

Common Pitfalls

• Snapshot non-determinism. Because every MicroVM resumes from the same snapshot, anything your app generated at init — IDs, secrets, crypto material — is identical across all of them. Generate those values at request time using your language’s CSPRNG, and use the Lambda base image’s snapshot-compatible OpenSSL if you rely on it.
• Treating it like a function. A MicroVM is a long-lived VM, not a fire-and-forget invocation. If you never terminate-microvm (or never let the idle policy suspend it), you keep paying. Track and reap your MicroVMs.
• A wrong idle policy. Set maxIdleDurationSeconds too low and you suspend users mid-think; too high and you pay for idle compute. Tune it to your session pattern — short for bursty agent jobs, longer for human IDE sessions.
• Forgetting auth on every call. Requests without a valid X-aws-proxy-auth token are rejected. Tokens expire (--expiration-in-minutes), so refresh them for long sessions.
• Missing ECR permissions. If your Dockerfile pulls a base from private ECR, the build role needs ecr:GetAuthorizationToken and ecr:BatchGetImage or image creation fails.

---

When to Use / When NOT to Use

Reach for MicroVMs when isolation, state, and lifecycle control all matter at once. Don’t reach for them when one of the cheaper, simpler primitives already fits.

Need	Best fit	Why
Per-user/session sandbox for untrusted or AI-generated code	Lambda MicroVMs	VM isolation + state + fast resume, fully managed
Stateless, event-driven, short tasks	Lambda functions	Cheaper and simpler; no VM lifecycle to manage
Always-on service at steady high utilization	ECS/EKS/EC2	Constant load is cheaper on reserved/always-on compute
Long-running batch with no isolation need	Fargate / Batch	No per-tenant boundary required; orchestration built in
Interactive IDE, AI sandbox, notebook, RL env, per-stage CI	Lambda MicroVMs	Suspend/resume preserves packages and state across pauses

On cost: MicroVMs are priced across three dimensions — compute (per-second, against your baseline plus any peak above it), snapshot operations and storage, and data transfer. You provision a baseline and can vertically scale up to 4x during peaks, paying the baseline rate while running and only for active use above it. Suspended MicroVMs incur no compute charge — which is the whole economic point of the suspend/resume model for bursty, interactive workloads.

---

Key Takeaways

• Lambda MicroVMs is a new serverless primitive (June 22, 2026) — a Firecracker sandbox per user, session, or AI agent, not a Lambda function variant.
• It ends the isolation vs. speed vs. state trade-off: VM-grade isolation, snapshot-fast resume, and full memory + disk state for up to 8 hours.
• The model is image once, run many: build a snapshot from your Dockerfile, then launch cheap, fast clones per tenant via run-microvm.
• Suspend when idle, resume on traffic — idle MicroVMs preserve state and cost no compute, which is the killer feature for interactive and agentic workloads.
• Each MicroVM gets a dedicated HTTPS endpoint (HTTP/2, gRPC, WebSockets) with token auth; no load balancers to run.
• Mind snapshot non-determinism, always terminate what you launch, and tune the idle policy to your session shape.
• Available in N. Virginia, Ohio, Oregon, Tokyo, and Ireland; reach it via console, CloudFormation, CDK, or the Agent Toolkit for AWS.

---

Further Reading

• AWS Lambda MicroVMs — Developer Guide
• Create your first Lambda MicroVM
• Launch announcement (What’s New)
• Lambda MicroVMs product page
• Firecracker microVM project