AWS Lambda MicroVMs explained: safely running untrusted and AI-generated code

TL;DR: AWS Lambda MicroVMs are a new way to run code you cannot trust, one sealed sandbox per user, safely and at scale. They combine the strong isolation of a virtual machine, the fast startup of a container, and a session that stays alive for up to 8 hours and pauses when idle. They exist because a wave of products now run code written by end users or by an AI, and that code needs to be sealed off from everything else.

Key takeaways

The problem: running untrusted or AI-generated code safely, for many users at once.
The old options each had a dealbreaker: virtual machines were slow, containers were not isolated enough, and Lambda functions timed out and forgot everything.
MicroVMs combine all three strengths: real isolation, near-instant start, and a long-lived session you only pay for while it runs.
The mental shift: you think in sessions (a workspace per user), not one-off function calls.
At launch: ARM64 only, five regions, and pricing per vCPU-second plus memory plus snapshot reads and writes.

What problem do Lambda MicroVMs solve?

More and more products run code that the company itself did not write. A user pastes a script into an online editor and hits Run. An AI coding assistant writes code and then runs it to check that it works. A data platform lets customers upload a program to crunch their own data. In every case, the code is untrusted: it could be buggy, or it could be malicious.

That code has to run somewhere sealed off, so one bad program cannot crash the system or read another user’s data. The hard part is doing this safely, instantly, and for many people at the same time.

Until now you had three ways to run code, and each had a catch:

A full virtual machine. Very well isolated, but slow to start (often minutes) and you pay for it even while it sits idle.
A container. Starts fast, but it shares the host’s operating system, so the wall between one user and the next is thin. That is risky for code you cannot trust.
A Lambda function. Well isolated and fast, but built for short tasks: it stops after 15 minutes and forgets everything between runs.

None of these gave you a sandbox that is safe, fast, and able to stick around.

What are AWS Lambda MicroVMs?

Lambda MicroVMs are a new serverless building block that combines the best of all three options. AWS describes three properties:

Real virtual-machine isolation. Each session runs in its own MicroVM, powered by Firecracker (the same technology behind Lambda), with no shared kernel and no shared resources between users.
Near-instant start and resume. Using snapshots, a MicroVM can boot and wake up almost immediately, instead of the minutes a normal VM takes.
Long-lived, stateful sessions. A MicroVM keeps its memory and disk for up to 8 hours. You can suspend it when nobody is using it, then resume it exactly where it left off.

The combination is the point. Before, you had to give up one of these to get the others. MicroVMs let you keep all three at once, with no servers to manage.

How are MicroVMs different from a regular Lambda function?

A regular Lambda function is request and response. You call it, it runs for a short time, it returns an answer, and it disappears. Nothing is remembered for next time.

A MicroVM is the opposite. You spin up a persistent environment for a single user or session. It stays around. When no one is using it, it pauses, and you stop paying for compute. When traffic comes back, it wakes up with its memory and files intact.

So the unit you think in changes. With Lambda you count one-off invocations. With MicroVMs you think in sessions: a private, ongoing workspace for each user.

What can you build with Lambda MicroVMs?

This building block was missing for a whole category of products. Good fits include:

AI coding assistants that write code and need to actually run it to confirm it works.
Online editors and notebooks, where a user hits Run and their code executes on your servers.
AI agents that take real actions, not just suggest them, and need a safe place to do the work.
Coding-interview and data platforms that run code submitted by people you do not know.
Security tools that deliberately run suspicious files to analyze them.

The common thread: untrusted or AI-generated code, one isolated workspace per user, running safely and at scale.

How different industries could use this

The pattern is the same everywhere: run code you cannot fully trust, sealed off, per user. What changes is the setting.

Healthcare. Let researchers or partners run analysis scripts against patient data, each in its own sealed sandbox, so one team’s code can never reach another’s protected health records.
Finance. Give analysts or customers a place to run their own models and backtests against sensitive data, isolated per user so untrusted code cannot leak positions or account details.
Education. Power coding courses and auto-graders where thousands of students run code at once, each in a fast, disposable box that resets cleanly between attempts.
Cybersecurity. Detonate suspicious files or malware in a throwaway environment with hard isolation, so nothing it does can escape to real systems.
SaaS and developer tools. Offer “run it in the browser” or AI-assistant features that execute user- or AI-written code safely on your own servers.
Data and analytics. Let customers upload and run custom transformations on their datasets, each job isolated and kept alive for the length of their session.

The common thread again: the moment your product runs someone else’s code, you inherit their risk. A sealed, per-user sandbox is how you take the capability without the exposure.

What are the limitations at launch?

A few things to weigh before you build on it:

ARM64 only at launch, so your code and dependencies must run on ARM.
Five regions at launch: US East (N. Virginia and Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo).
A different pricing model. You pay per vCPU-second, per memory GB-second, and for snapshot reads and writes. That is closer to Fargate than to classic Lambda, so the cost math is different. Check the AWS Lambda pricing page for current rates before you estimate.
A different mental model. Because you manage sessions rather than fire-and-forget calls, you have to decide when to create, suspend, resume, and tear down each environment.

The bottom line

Lambda MicroVMs fill a real gap: a safe, fast, long-lived sandbox for code you cannot trust, one per user, with no servers to run. If you are building anything that executes user-supplied or AI-generated code, this is the kind of primitive that used to require stitching together your own infrastructure. Now it is a managed service.

Worth reading the official launch post in full: https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/

FAQ

What are AWS Lambda MicroVMs?

They are a serverless building block for running untrusted or AI-generated code in an isolated sandbox, one per user or session. Each runs in its own Firecracker MicroVM with strong isolation, starts and resumes almost instantly, and can stay alive (with memory and disk preserved) for up to 8 hours, pausing when idle.

How are Lambda MicroVMs different from regular Lambda functions?

Regular Lambda is request-and-response: it runs briefly and forgets everything. MicroVMs are persistent sessions: you spin one up per user, it keeps its state, it suspends when idle so you stop paying, and it resumes where it left off. You think in sessions, not one-off calls.

Why not just use a container to run untrusted code?

Containers start fast but share the host’s operating system, so the isolation between users is thinner than a virtual machine. For code you cannot trust, that shared kernel is a risk. MicroVMs give each session full VM-level isolation while keeping container-like startup speed.

What can you build with Lambda MicroVMs?

AI coding assistants that run the code they write, online editors and notebooks, AI agents that take actions, coding-interview and data platforms that run code from strangers, and security tools that run suspicious files. Anything that runs untrusted or AI-generated code per user.

What are the limitations of Lambda MicroVMs at launch?

At launch they run on ARM64 only, are available in five regions (N. Virginia, Ohio, Oregon, Ireland, Tokyo), and use a pricing model based on vCPU-seconds, memory GB-seconds, and snapshot reads and writes. They also require a session-based mental model rather than fire-and-forget calls.