AWS Lambda’s MicroVM-Powered sandboxes: Unleash full lifecycle control in isolation.

Today, we’re excited to introduce AWS Lambda MicroVMs — a brand-new serverless compute option within AWS Lambda that allows you to execute code created by users or AI inside isolated, stateful execution environments. You benefit from virtual machine–grade isolation, lightning-fast startup and resume times, and full control over the environment’s lifecycle and state — all without having to manage infrastructure or develop specialized knowledge in complex virtualization technologies. Lambda MicroVMs are built on Firecracker, the same lightweight virtualization engine that has powered more than 15 trillion Lambda function invocations every month.

Why customers need this

In recent years, a new category of multi-tenant applications has emerged — all of which share a common requirement: giving each end user a dedicated execution environment where code written by someone other than the application developer can run safely. AI coding assistants, interactive coding environments, data analytics platforms, vulnerability scanners, and game servers that execute user-supplied scripts all follow this pattern. Building this capability today forces a tough decision. Virtual machines provide strong isolation but require minutes to boot up. Containers start in seconds, yet their shared-kernel design demands substantial custom hardening to safely contain untrusted code. Functions as a service are tailored for event-driven, request-response workloads but aren’t built for long-running interactive sessions that must preserve environment state across user interactions. This leaves developers either compromising between performance and isolation, or dedicating significant engineering effort to build and maintain custom virtualization infrastructure that achieves isolated execution while still delivering low-latency experiences to end users. That kind of effort requires deep expertise and diverts engineering resources away from the product they’re actually trying to deliver.

Lambda MicroVMs were designed specifically to fill this gap. Each MicroVM provides a single end user or session with its own isolated environment that starts quickly, preserves memory and disk state for the entire duration of the session, and pauses to a minimal idle cost when the user steps away. Because the same Firecracker technology already powers AWS Lambda Functions, you benefit from the operational maturity of a service that has been running this stack at massive scale.

Let’s try it out

To get started, I opened the AWS Lambda console, where Lambda MicroVMs is now listed in the left-hand navigation panel. The first step is to create a MicroVM Image.

I bundled a Flask web application and its Dockerfile into a zip file and uploaded it to an Amazon Simple Storage Service (Amazon S3) bucket.

My Flask API – app.py

import logging

from flask import Flask, jsonify

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)


@app.route("/")
def hello():
    app.logger.info("Received request to hello world endpoint")
    return jsonify(message="Hello, World!")


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

My Dockerfile

FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 python3-pip && dnf clean all

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

I used the following command to create my MicroVM Image.

aws lambda-microvms create-microvm-image 
--code-artifact uri= --name  
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 
--build-role-arn 

You can also create the MicroVM Image through the AWS Console, as shown in the screenshot above. Once I ran the command, Lambda fetched the zip file, executed the Dockerfile, initialized the application, and captured a Firecracker snapshot of the running disk and memory state. Build logs streamed in real time to Amazon CloudWatch under /aws/lambda/microvms/, and when the image was ready it appeared in the console along with its Amazon Resource Name (ARN) and version number.

aws lambda-microvms run-microvm 
--image-identifier arn:aws:lambda:::microvm-image:my-image 
--execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole 
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Launching can also be done through the AWS Console or the CLI. I provided the image ARN and an idle policy set to automatically suspend after 15 minutes of inactivity and automatically resume on the next incoming request. No networking configuration was needed. Lambda assigned the MicroVM a unique ID, returned a dedicated endpoint URL, and started a new MicroVM with my Flask app already running, since it was restored from a snapshot. My Flask app was up and running the instant the launch finished. A single API call to get a fully initialized, bootstrapped compute environment.

To send traffic, I generated a short-lived authentication token using the CLI and included it in a standard HTTPS request via the X-aws-proxy-auth header. The request reached my Flask app immediately. I then let the MicroVM remain idle past the suspend threshold, at which point the MicroVM was suspended — its memory and disk state snapshotted and stored. I then sent another request, and it resumed with the application state fully intact. From the client’s perspective, the pause was completely invisible.

How it works

Under the hood, Lambda MicroVMs brings together three capabilities that, until now, no single AWS compute service offered in one package. The first is virtual machine–level isolation, which comes from Firecracker. Each session runs inside its own dedicated MicroVM with no shared kernel and no shared resources between users, so untrusted code from one user is fully contained within their own execution environment, with no access to other environments or the underlying host system. The second is rapid launch and resume. The model follows an image-then-launch approach: you create a MicroVM Image by providing a Dockerfile and code packaged as a zip artifact in Amazon S3, and Lambda runs your Dockerfile, initializes your application, and takes a Firecracker snapshot of the running environment’s memory and disk state. Every