Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs | Amazon Web Services (opens in new tab)
AWS Lambda MicroVMs provide isolated, stateful execution environments for running untrusted user- or AI-generated code without managing virtual machine infrastructure. Built on Firecracker, they combine VM-level isolation, near-instant startup and resume, and persistent memory and disk state. The post concludes that MicroVMs fill the gap between slow, isolated VMs, less-secure containers, and stateless event-driven Lambda functions.
The Need for Isolated, Stateful Execution
- AI coding assistants, online development environments, analytics tools, vulnerability scanners, and game servers increasingly need a dedicated environment for each user or session.
- Traditional options involve tradeoffs:
- VMs provide strong isolation but often take minutes to start.
- Containers launch quickly but share a kernel and require extensive hardening for untrusted workloads.
- Standard serverless functions are designed for short, request-response workloads rather than long-running interactive sessions.
- Building custom virtualization infrastructure requires significant security, operations, and virtualization expertise.
What Lambda MicroVMs Provide
- Each user or session receives its own Firecracker-powered MicroVM.
- MicroVMs offer:
- Dedicated VM-level isolation with no shared kernel between users.
- Rapid launch and resume from a pre-initialized snapshot.
- Persistent memory, disk state, and running processes during a session.
- Automatic suspension during inactivity to reduce idle costs.
- Automatic resume when new traffic arrives.
- Firecracker already powers AWS Lambda at large scale, providing an established virtualization foundation.
Creating a MicroVM Image
The example packages a Flask application and Dockerfile into a ZIP archive and uploads it to Amazon S3.
The Dockerfile uses:
FROM public.ecr.aws/lambda/microvms:al2023-minimalIt installs Python and dependencies, copies the Flask application, and starts it with Gunicorn on port 5000.
An image is created with the
aws lambda-microvms create-microvm-imagecommand, specifying:- The S3 code artifact
- An image name
- An AWS-provided base image ARN
- An IAM build role
Lambda builds the image, initializes the application, and captures its memory and disk state in a Firecracker snapshot.
Build logs are available in CloudWatch under
/aws/lambda/microvms/<image-name>.
Launching and Managing a MicroVM
- A MicroVM is launched from the image ARN with
run-microvm. - The example configures an idle policy that:
- Suspends the MicroVM after 15 minutes of inactivity.
- Keeps it suspended for up to 5 minutes.
- Automatically resumes it when traffic returns.
- Lambda assigns a unique MicroVM ID and provides a dedicated HTTPS endpoint.
- No separate networking setup is required.
- The application is already running when the MicroVM becomes available because it resumes from the image snapshot.
Request Handling and State Preservation
- Clients authenticate requests using a short-lived token in the
X-aws-proxy-authheader. - The Flask API responds immediately after launch.
- When the MicroVM becomes idle, Lambda snapshots and stores its memory and disk state.
- A later request resumes the environment with the application state intact, making suspension effectively invisible to the client.
Underlying Execution Model
- Lambda MicroVMs use an image-then-launch workflow:
- Build and initialize an environment once.
- Snapshot the initialized state.
- Launch future MicroVMs by resuming that snapshot.
- This avoids repeating operating-system and application startup work.
- The combination of Firecracker isolation, snapshot-based startup, and suspend/resume lifecycle control makes MicroVMs suitable for secure, interactive, multi-tenant workloads.
For applications that must safely execute untrusted code while preserving session state and responsive startup times, Lambda MicroVMs offer a managed alternative to building custom VM infrastructure.