AWS Lambda MicroVMs: I Tested the New Stateful Serverless Primitive

What just happened

On June 22, 2026, AWS quietly launched AWS Lambda MicroVMs. Not a Lambda feature update. A new compute primitive sitting between AWS Lambda Functions (stateless, 15-min max) and EC2 (full VM, you manage everything).

Each MicroVM is an isolated Firecracker VM with its own HTTPS endpoint, running your code from a pre-built snapshot. Stateful. Up to 8 hours. Suspend when idle, resume on demand.

I tested it the same week. Here's what I found.

The test setup

A minimal Python HTTP server packaged as a Dockerfile:

from http.server import HTTPServer, BaseHTTPRequestHandler
import json, time, os

class Handler(BaseHTTPRequestHandler):
    start_time = time.time()
    request_count = 0

    def do_GET(self):
        Handler.request_count += 1
        body = json.dumps({
            "message": "Hello from Lambda MicroVM!",
            "uptime_seconds": round(time.time() - Handler.start_time, 2),
            "requests_served": Handler.request_count,
            "pid": os.getpid()
        })
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(body.encode())

HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()

The Dockerfile:

FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 && dnf clean all
WORKDIR /app
COPY app.py .
EXPOSE 8080
CMD ["python3", "app.py"]

How it works

Three steps:

1. Zip code + Dockerfile → upload to Amazon Simple Storage Service (Amazon S3)
2. create-microvm-image builds the container, starts the app, takes a Firecracker snapshot of memory and disk
3. run-microvm launches from that snapshot

Every launch resumes from the pre-initialized state. No cold boot. Your app is already running the moment the MicroVM starts.

aws lambda-microvms create-microvm-image \
  --name hello-microvm-test \
  --code-artifact "uri=s3://my-bucket/artifact.zip" \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789:role/MicroVMBuildRole

Image build took about 3 minutes. Once done:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:123456789:microvm-image:hello-microvm-test \
  --execution-role-arn arn:aws:iam::123456789:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":300,"suspendedDurationSeconds":60,"autoResumeEnabled":true}'

Response:

{
  "microvmId": "microvm-489fbc1b-1c73-3b37-a9f2-266d0173cb94",
  "state": "RUNNING",
  "endpoint": "34cf7dac-bb5c.lambda-microvm.us-east-1.on.aws"
}

The numbers

Metric	Measured
Image build	~3 minutes
Launch API call	1.17s
Time to RUNNING	~12s
First request (from snapshot)	911ms
Warm request latency	~340ms
Suspend → Resume	1.86s

The 340ms warm latency includes my network round-trip from Hamburg to us-east-1. The actual compute latency is lower.

Statefulness proof

This is the part that matters. After three requests:

{"requests_served": 3, "uptime_seconds": 434.76, "pid": 1}

Suspend the MicroVM. Resume it. Send another request:

{"requests_served": 5, "uptime_seconds": 454.1, "pid": 1}

Same PID. Counter continued from where it left off. Uptime kept ticking (includes suspended time). Full memory and disk state preserved across suspend/resume.

Authentication

Each request needs a JWE token generated via the API:

aws lambda-microvms create-microvm-auth-token \
  --microvm-id microvm-489fbc1b \
  --expiration-in-minutes 15 \
  --allowed-ports '[{"port":8080}]'

The token goes in the X-aws-proxy-auth header. Short-lived, scoped to specific ports. No way to hit someone else's MicroVM.

What this replaces

Before Lambda MicroVMs, running untrusted code (AI-generated, user-submitted) meant:

• Containers with custom hardening — shared kernel, escape risk, significant engineering to harden
• EC2 per user — minutes to start, expensive, you manage everything
• Lambda Functions — 15-min max, stateless, no interactive sessions

Lambda MicroVMs fills the gap: VM-level isolation with serverless operational model. No capacity planning. No kernel to patch. Suspend when idle, pay only for snapshot storage.

Specs and limits

• Compute: 0.5–8 GB RAM baseline, burst to 32 GB. 0.25–4 vCPU baseline, burst to 16.
• Disk: up to 32 GB
• Runtime: max 8 hours
• Architecture: ARM64 only (for now)
• Protocols: HTTP/1.1, HTTP/2, gRPC, WebSocket, SSE
• Regions: us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1

Pricing model

Three dimensions:

• Compute: per-second, based on your chosen baseline + peak usage above it
• Snapshot operations: read/write when launching or suspending
• Snapshot storage + data transfer

Suspended MicroVMs cost only storage. No compute charges while idle.

Who should care

If you're building any of these, Lambda MicroVMs changes your architecture:

• AI agent sandboxes (execute generated code safely)
• Browser-based IDEs (each user gets their own env)
• CI/CD runners (isolated per job, no shared state)
• Jupyter/analytics (state persists across sessions)
• Vulnerability scanning (disposable, isolated)

What I'd watch

• ARM64 only is a constraint for workloads compiled for x86
• 5 regions at launch means some customers wait
• The snapshot-based model means your app's initialization needs to be snapshot-friendly (no stale connections, no clock-sensitive state at init) - Pricing details not fully public yet at time of writing

Getting started

You need AWS CLI v2.35.10+. The lambda-microvms service is a separate command namespace:

aws lambda-microvms list-managed-microvm-images --region us-east-1
aws lambda-microvms create-microvm-image --help
aws lambda-microvms run-microvm --help

The base image (al2023-1) is Amazon Linux 2023 minimal. Your Dockerfile adds what you need on top.

Pricing

Lambda MicroVMs bills per second across three dimensions. You configure a baseline and pay for
burst capacity only when used.

Compute (eu-west-1):

• vCPU: $0.0000291572 per second
• Memory: $0.0000038603 per second per GB

You pay baseline while running. Burst above baseline is charged only for the seconds consumed
at peak, not for the full duration.

Snapshot operations and storage are charged separately (pricing not fully detailed at
launch).

Real-world example: Playwright browser automation

Baseline: 1 vCPU / 2 GB RAM. Chromium bursts to 2 vCPU + 4 GB for 3 seconds during page render.

Simple scrape (stays at baseline) — 5s duration → $0.000185 per invocation → $1.85 at 10K/month

Heavy page (burst 3s of 8s) — 8s duration → $0.000405 per invocation → $4.05 at 10K/month

Full PDF render (burst 5s of 12s) — 12s duration → $0.000996 per invocation → $9.96 at 10K/month

A Playwright job that needs 4 GB for 3 seconds of an 8-second run costs half of what a fixed 4 GB allocation would for the full duration. Configure for your typical workload, let Lambda handle the spikes.

Suspended MicroVMs incur only snapshot storage costs. No compute charges while idle.

Try it yourself

I packaged everything above, plus the part this post skips (making a MicroVM publicly accessible), into a starter kit. One command deploys any app to a MicroVM with public CloudFront access:

→ github.com/vidanov/lambda-microvm-starter

Four example apps: an interactive notebook, a sandboxed code runner, an HTML-to-PDF service, and an AI agent with runtime governance. Public or private mode.

Two things this test did not cover, both of which matter near real workloads:

• Public access. There is no public mode. Every request needs an auth token. The fix is CloudFront + Lambda@Edge, and it took 13 problems to get right.
• Governance. A MicroVM isolates the environment. It does not govern what the code inside does. For AI agents, that second layer is the whole game.

Both are in the follow-up.

---

Tested June 24, 2026. Lambda MicroVMs launched June 22 in preview.

Sources

• Blog: https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/
• Product page: https://aws.amazon.com/lambda/lambda-microvms/
• CLI: aws-cli v2.35.10+ (aws lambda-microvms)