DEV Community

Cover image for AWS Lambda MicroVMs: I Tested the New Stateful Serverless Primitive
AWS Community Builders profile image Alexey Vidanov
Alexey Vidanov for AWS Community Builders

Posted on

AWS Lambda MicroVMs: I Tested the New Stateful Serverless Primitive

#lambda #serverless #aws #firecracker

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()
Enter fullscreen mode Exit fullscreen mode

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"]
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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}'
Enter fullscreen mode Exit fullscreen mode

Response:

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

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}
Enter fullscreen mode Exit fullscreen mode

Suspend the MicroVM. Resume it. Send another request:

{"requests_served": 5, "uptime_seconds": 454.1, "pid": 1}
Enter fullscreen mode Exit fullscreen mode

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}]'
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

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

Sources

Top comments (0)