AWS Lambda MicroVMs

Overview

What is AWS Lambda MicroVMs?

Start a MicroVM, connect to it over HTTP, and begin executing code for your AI or human users. No infrastructure to manage, no capacity to plan, no isolation expertise required.

Lambda MicroVMs takes the Firecracker micro-virtualization that has always run underneath AWS Lambda and exposes it directly as a primitive you can address and hold open. Instead of firing a stateless function and getting a response, you launch your own isolated sandbox that preserves full memory and disk state, suspends when idle, and resumes on demand — sized for workloads that execute untrusted, user- or AI-generated code.

15T+Monthly Lambda invocations on the same Firecracker tech

8 hrsMemory + disk state preserved per session

4×Vertical burst above your baseline at peak

JWEPer-MicroVM token auth + dedicated URL

Capabilities

What it does

Isolated, stateful execution at Lambda speed

Launch an isolated Firecracker-powered sandbox that starts near-instantly and preserves full memory and disk state for up to 8 hours. Suspend automatically when idle, resume on demand.

Multi-tenant, with serverless simplicity

Each MicroVM gets a dedicated URL and JWE-based authentication; route each tenant's traffic to their MicroVM. Lambda manages network routing and isolation — separate kernel, memory, and disk per tenant.

Flexible scaling, lifecycle & state

Scale resource use on demand — vertically burst up to 4× your baseline at peak. Control the full lifecycle: launch, suspend, resume, and terminate on your terms.

Use cases

What can you build with Lambda MicroVMs?

AI coding assistants & agent sandboxes

A separate execution boundary per task — no access to agent state, no shared state across users, with state persisting across multi-step tasks.

Interactive development platforms

Browser-based dev environments where each user gets an isolated environment instantly, with packages and dependencies preserved across interactions.

Vulnerability scanning & security testing

VM-level containment per session keeps malicious code off other users and the host. Environments spin up and tear down on demand with no residual state.

Data analytics platforms

Each user keeps packages, results, and context for up to 8 hours, suspends when idle, and resumes near-instantly — no re-computation between sessions.

CI/CD & developer productivity

An isolated environment per pipeline stage for PR and third-party code. Stages launch near-instantly and resume where they left off — no shared state between jobs.

Architecture

Where does Lambda MicroVMs fit?

AWS positions MicroVMs as the missing rung between a stateless Lambda function and an always-on container or VM. Here's how it lines up against neighbouring compute options — the comparison and "best for" column are our synthesis, not AWS copy.

Option	Isolation	State	Lifespan	Best for
Lambda functions	Micro-VM (Firecracker)	Stateless / ephemeral	≤ 15 min per call	Event-driven glue, APIs, short jobs
Lambda MicroVMs	Micro-VM (Firecracker)	Full memory + disk; suspend/resume	≤ 8 hr session	Per-user / per-agent code sandboxes
Fargate (ECS/EKS)	Container (Firecracker-isolated task)	Ephemeral unless wired to storage	Long-running	Services, batch, scheduled work
EC2	Full VM	Persistent	Unbounded	Always-on, custom kernels, GPUs
Self-hosted Firecracker	Micro-VM	DIY snapshots	You manage	Full control / on-prem, max effort

Early voices

Who's using it

“AWS continues to broaden compute options… Lambda MicroVM is among the most compelling new AWS compute primitives for stateful, agentic workloads tested.”

Randall HuntCTO, Caylent

“Lambda MicroVMs provides Firecracker isolation, snapshot-based fast starts, and suspend/resume — letting isolated workloads carry private engines.”

Auxten WangDirector, ClickHouse

“Setting up Lambda MicroVMs was straightforward. Within hours we offered developers a fully isolated, secured sandbox with agentic capabilities.”

Christoph LummeEnterprise Architect, Siemens Switzerland

“Lambda MicroVMs are compelling for secure isolation and tight permissions while aligning cost to actual resource usage.”

Rustem FeyzkhanovSr. Manager, Snorkel AI

Pricing

How much does it cost?

AWS prices Lambda MicroVMs across three dimensions — and notably publishes no concrete per-unit numbers on the product page:

① Compute

Per-second, based on baseline and peak usage. Provision for baseline, burst up to 4× when workloads demand it.

② Snapshots

Snapshot operations plus snapshot storage — the cost of saving and restoring memory/disk state.

③ Data transfer

Standard network egress for traffic in and out of your MicroVMs.

Suspended MicroVMs incur no compute charges. View AWS's detailed pricing →

Availability

Available now — June 2026

Launched June 23, 2026. Generally available in five AWS Regions at launch:

US East (N. Virginia) US East (Ohio) US West (Oregon) Asia Pacific (Tokyo) Europe (Ireland)

OffNet Chat analysis

What this actually is — and why it matters

Strip the marketing and Lambda MicroVMs is one sentence: Firecracker snapshot/restore, promoted from an internal implementation detail to a public, addressable primitive.

For years AWS ran Firecracker under the hood of Lambda and Fargate but only exposed it through the function abstraction — fire an event, get a response, lose your state. The entire sandbox-for-AI market (E2B, Modal, Daytona, Fly Machines, Cloudflare's container/sandbox SDK, Vercel Sandboxes, Runloop) grew up in exactly that gap. MicroVMs is AWS reclaiming it: you now get the raw micro-VM, a URL, a token, and an 8-hour memory.

Insight

The real unlock is statefulness, not isolation

VM-grade isolation has existed for ages (EC2, Fargate, DIY Firecracker). What was hard was cheap, fast, stateful, throwaway isolation. Suspend-on-idle + resume-with-memory-intact + pay-only-while-running is the combination that makes per-user and per-agent sandboxes economically sane. A notebook left open over lunch costs nothing while suspended, then resumes in milliseconds with every variable still in RAM.

Insight

This is an agent-era product, timed deliberately

The framing — "execute user- or AI-generated code," "no access to agent state," "separate execution boundary per task" — and the launch tagline ("you shouldn't have to choose between strong isolation and fast start-up speed") aim squarely at coding agents. As agents move from suggesting code to running it, untrusted-code execution becomes everyone's problem. AWS is selling the boundary that keeps an agent's generated rm -rf or exfiltration attempt off your credentials and off your other tenants.

Analysis

AWS entering a market the startups defined

E2B, Modal, and Daytona proved the demand and the UX (instant sandbox, SDK, snapshots). AWS's edge is gravity and integration — if your data, IAM, and VPC already live in AWS, a native sandbox primitive removes a vendor, a network hop, and a security review. The independents' edge is developer experience, multi-cloud neutrality, and not being another line on the invoice you're already trying to cut. Expect them to compete on polish and price.

Watch-outs

What to confirm before betting on it

The launch closed one gap we'd flagged — regions are now known (5 at GA). The open questions that remain:

• No concrete prices. "Three dimensions" with no numbers means TCO is unknowable until you model snapshot storage + per-second compute against your real idle/active pattern.
• No GPU story. If sandboxed code needs acceleration (model inference, CUDA), this isn't it — that work still lands on EC2/Fargate-GPU or your own hardware.
• Resource ceilings unspecified. "4× baseline" of what max vCPU/RAM? Plus supported kernels, languages, and egress rules.
• "Near-instant" ≠ specified. The cold-launch-vs-warm-resume latency gap matters for UX; get real numbers from the docs.
• Lock-in. The dedicated-URL + JWE + lifecycle API is AWS-shaped; portability back to self-hosted Firecracker is non-trivial.

Our take · relevance to us

Where it would (and wouldn't) fit OffNet Chat's stack

We run our own GPU box for inference and the message relay, so heavy model serving stays put — MicroVMs offers no GPU path. But for things we'd never run on that trusted host — executing model-generated code, sandboxing a contributor's build, detonating a suspicious payload — a throwaway, isolated, pay-per-second VM is exactly the right shape. The model: keep the GPU and trusted services on metal we own; rent disposable isolation in the cloud for anything untrusted.

TL;DR

Key pointers

1

Firecracker as a first-class primitive. Launch a micro-VM, get a dedicated URL + JWE token, talk to it over HTTP — an addressable sandbox, not a function invocation.

2

Statefulness is the headline. Full memory + disk preserved up to 8 hours; suspend on idle, resume near-instantly, pay compute only while running.

3

Built for the agentic moment. Marquee use case is safely running user- and AI-generated code with a hard boundary — no agent creds, no cross-tenant state.

4

Multi-tenancy built in. One MicroVM per tenant; AWS handles routing and isolation across kernel, memory, and disk.

5

Elastic within a session. Vertical burst up to 4× baseline at peak — scaling up, not just out.

6

Pricing has three axes. Compute (per-second, baseline + peak), snapshot ops/storage, and data transfer. Suspended = $0 compute. No public unit prices yet.

7

Available now in 5 regions. GA from June 23, 2026: N. Virginia, Ohio, Oregon, Tokyo, Ireland.

8

AWS's native answer to the sandbox startups. Direct competition for E2B, Modal, Daytona, Cloudflare Sandboxes, Fly Machines, Vercel Sandboxes.

9

Sweet spot vs. wrong tool. Great for dev environments, notebooks, CI stages, agent sandboxes, security detonation. Wrong for always-on services (EC2/Fargate) or sub-second stateless glue (plain Lambda) — and no GPU today.

Sources & further reading