For more than ten years, AWS Lambda has meant one thing to most of us: write a handler, attach a trigger, and let AWS take care of everything else. In July 2026, AWS launched Lambda MicroVMs, and “Lambda” now covers a second, quite different kind of compute.
So if you’re designing a new workload today, you’ll probably ask yourself: should this be a Lambda function or a MicroVM? In this post I’ll cover how each one works, where they differ, and a simple way to choose between them.
The Shared Foundation: Firecracker
The two services have more in common than you might expect. Every Lambda function invocation already runs inside a Firecracker microVM. That’s the lightweight virtualization technology AWS open-sourced, and it gives you hardware-level isolation with very fast startup. Lambda SnapStart then used Firecracker’s snapshotting to restore pre-initialized environments instead of booting them from scratch.
Lambda MicroVMs take that same building block and hand it to you directly. With Lambda functions, AWS manages the microVM for you and you never see it. With MicroVMs, you work with the microVM itself, but you still don’t manage any servers or virtualization infrastructure.
That’s the key idea for the rest of this post. Functions abstract the environment away. MicroVMs give you the environment.
Lambda Functions: Event-Driven and Stateless
Lambda functions are built around events. An S3 upload, an API Gateway request, an SQS message, or an EventBridge rule triggers your code. The code runs, returns a result, and Lambda decides whether to keep the execution environment warm or throw it away.
What you get:
Automatic scaling across thousands of concurrent invocations
Pay-per-request and per-millisecond billing, with nothing to pay when idle
A huge integration ecosystem with native triggers from more than 200 AWS services
A 15-minute maximum run time per invocation
Statelessness by design, so anything that needs to persist goes to DynamoDB, S3, or a cache
This model works very well for APIs, data pipelines, stream processing, automation, and glue code. You don’t control which environment serves which request, and you shouldn’t need to. If you need long-running orchestration, Lambda Durable Functions and Step Functions already cover that.
Lambda MicroVMs: Isolated, Stateful Environments You Control
MicroVMs are built around sessions rather than events. You give each user, tenant, or job its own dedicated, isolated compute environment and control its lifecycle yourself.
In practice it works like this:
Build a MicroVM image. You provide a Dockerfile. Lambda runs it, starts your application, and takes a Firecracker snapshot of the fully initialized memory and disk state.
Launch a MicroVM per session. Each one starts from that snapshot with dependencies already loaded, so it’s ready almost instantly, and it gets its own dedicated HTTPS endpoint. You talk to it over plain HTTPS, WebSockets, or gRPC.
Suspend and resume. With an idle policy, the MicroVM suspends automatically after a period of inactivity and keeps its memory and disk state. When the next request arrives, it resumes within seconds exactly where it stopped. Sessions can last from a few minutes up to 8 hours.
Scale both ways. Each MicroVM starts with a baseline (2 GB / 1 vCPU by default, up to 8 GB / 4 vCPUs) and can automatically scale vertically up to 4x during peaks. You can also launch several hundred MicroVMs within a minute.
Connect to private resources. Outbound internet works by default. For VPC resources such as RDS or Redshift, you attach a Lambda Network Connector.
There’s no trigger model here. Your application calls an API to launch a MicroVM, and then sends traffic straight to its endpoint.
Side-by-Side Comparison
When to Choose Lambda Functions
Go with a function when:
Your workload is triggered by events and finishes in seconds or minutes
Each request is independent, with no need for memory between calls
You run your own trusted code
You want the deepest AWS service integration and the simplest operating model
Traffic is spiky and you want to pay nothing while idle
That still covers most serverless workloads. MicroVMs don’t replace functions.
When to Choose Lambda MicroVMs
Go with a MicroVM when:
You run untrusted or just-in-time code written by users or generated by an LLM, and each piece needs hard VM-level isolation from the others
Users expect to come back to where they left off, with installed packages, loaded datasets, and running processes still there
Sessions are long and interactive, with idle gaps between activity
You need elevated OS-level capabilities inside the sandbox
Typical examples include AI coding agents and their code-execution sandboxes, browser-based IDEs and notebooks, vibe-coding platforms, data analytics workspaces where analysts keep multi-gigabyte datasets in memory all day, vulnerability scanners, and ephemeral CI/CD build environments.
Before MicroVMs, teams building these products usually ran their own Firecracker or container fleets, wrote their own snapshot logic, and managed capacity themselves. MicroVMs turn all of that into a managed service.
A Simple Decision Rule
Ask yourself one question:
Does my code need its own long-lived, isolated machine, or does it only need to react to something?
If it reacts to something, use a Lambda function.
If it needs its own machine (isolated, stateful, and tied to a specific user or session), use a Lambda MicroVM.
You can also combine them. A common pattern is a Lambda function behind API Gateway that handles authentication and session routing, launches or resumes a MicroVM for each user, and passes requests to that MicroVM’s endpoint. The function is the control plane and the MicroVM is the workspace.
Final Thoughts
Lambda functions made servers invisible. Lambda MicroVMs make sandboxes easy to use. As more applications run code that their developers didn’t write themselves, especially code generated by AI agents, per-session isolation stops being a niche need and becomes a regular architectural concern.
My advice: keep building with functions by default, and use MicroVMs when isolation, state, and session ownership start to matter.