AWS Lambda MicroVMs bring VM isolation to serverless

Key Takeaways

• Lambda MicroVMs run each user session in its own Firecracker VM with hardware-level isolation, targeting AI agents and untrusted code execution
• Snapshot-based launch resumes pre-initialized state instantly, with suspend/resume preserving memory and disk for up to 8 hours
• Available now in 5 regions on ARM64 with up to 16 vCPUs, 32 GB memory, and 32 GB disk per instance

AWS released Lambda MicroVMs, a serverless compute primitive that runs each user session or AI agent in its own Firecracker virtual machine. The service combines hardware-level isolation with snapshot-based instant launch and state preservation for up to eight hours. It's available now in five regions on ARM64, supporting up to 16 vCPUs, 32 GB of memory, and 32 GB of disk per instance.

This is a separate resource from Lambda Functions, with its own API. The target workload: long-running, stateful, multi-tenant applications that execute code the developer did not write. Think AI agents generating and running code, or SaaS platforms where customers upload scripts.

What problem does Lambda MicroVMs solve?

Teams building multi-tenant platforms that run untrusted code have faced a three-way tradeoff. VMs deliver strong isolation but take minutes to start. Containers launch quickly but share a kernel, requiring significant hardening for untrusted code. Functions optimize for event-driven request-response, not long-running interactive sessions.

Lambda MicroVMs collapses all three into one: VM-level isolation, near-instant launch, and stateful execution. The execution model is different from Lambda Functions. You create a MicroVM Image by uploading a Dockerfile and code artifact to S3. Lambda runs the Dockerfile, initializes the application, and snapshots the running memory and disk state via Firecracker. Every subsequent MicroVM launched from that image resumes from the pre-initialized snapshot rather than booting cold.

Call run-microvm, pass the image ARN and an idle policy, and the service returns a dedicated HTTPS endpoint with the application already running. No load balancers, no networking setup.

How suspend/resume changes interactive workloads

The suspend/resume lifecycle makes this practical for interactive use cases. When a user walks away from a coding session, the MicroVM suspends after a configurable idle window, snapshotting memory and disk. When traffic returns, it resumes with everything intact: installed packages, loaded models, working filesets.

DevelopersIO tested the full lifecycle with a Flask app in the Tokyo region. They confirmed that suspend and resume preserved application state seamlessly. From the client side, the pause never happened.

For teams running AI-generated code at scale, where millions of executions per day come from models that cannot be audited, this is a materially stronger boundary than container-level isolation. Each MicroVM runs in its own dedicated VM. No shared kernel, no shared resources between sessions. A container escape in one session cannot reach another session or the host.

How does it compare to Cloudflare, Google, and Azure?

The cross-hyperscaler comparison for agent-generated code is now complete. Each major cloud provider has shipped its answer, with different tradeoffs.

Cloudflare optimizes for edge latency and global distribution. Google targets Kubernetes-native portability. Azure integrates with its Logic Apps and Foundry agent platforms. AWS bets on stateful isolation with lifecycle control.

Community reaction: useful, but not magic

Practitioners on Reddit balanced launch excitement with pragmatism. One commenter challenged the framing that MicroVMs unlock something fundamentally new:

“Lambda MicroVMs don't really enable entirely new workloads that were impossible before. What they change is the cost/performance/security tradeoff. The biggest use cases are untrusted code execution, multi-tenant SaaS, AI agents, and highly isolated serverless workloads where containers weren't considered secure enough but full VMs were too heavy.”

— Reddit user in r/aws

The unlock, then, is VM-level isolation at near-serverless scale. Not impossible before, but expensive and operationally painful.

Technical specifications and limits

Networking supports inbound HTTPS on configurable ports with HTTP/2, gRPC, and WebSocket protocols. Each MicroVM gets a dedicated endpoint. The service uses the same Firecracker VMM that powers over 15 trillion monthly Lambda Function invocations.

• Up to 16 vCPUs, 32 GB RAM, 32 GB disk per instance
• ARM64 (Graviton) only at launch, 5 regions
• State preservation up to 8 hours via suspend/resume
• Snapshot-based launch from pre-initialized images
• Dedicated HTTPS endpoint per MicroVM

The 8-hour limit is a significant jump from Lambda Functions' 15-minute maximum execution time. For coding assistants, data science notebooks, or any workflow where users step away and return, this changes the architecture.

Frequently Asked Questions

How is Lambda MicroVMs different from Lambda Functions?

Lambda Functions are optimized for short-lived, event-driven workloads with a 15-minute maximum. Lambda MicroVMs target long-running, stateful sessions with up to 8 hours of state preservation and hardware-level VM isolation per session.

What regions support Lambda MicroVMs at launch?

AWS launched Lambda MicroVMs in five regions on ARM64 (Graviton) architecture. Specific regions were not detailed in the announcement.

Can Lambda MicroVMs run x86 workloads?

At launch, Lambda MicroVMs support ARM64 only. x86 support has not been announced.

Is Firecracker the same technology used in regular Lambda?

Yes. Firecracker is the lightweight VMM that powers over 15 trillion monthly Lambda Function invocations. Lambda MicroVMs use the same isolation technology with a different execution model optimized for stateful, long-running workloads.

What happens when a Lambda MicroVM suspends?

The MicroVM snapshots its memory and disk state. When traffic returns, it resumes from the snapshot with all state intact, including installed packages, loaded models, and working files.

Source: InfoQ