What's New

AWS has launched Lambda MicroVMs, a new serverless compute primitive that delivers VM-level isolation, near-instant launch and resume speeds, and stateful execution for running user- or AI-generated code. Built on Firecracker virtualization—the same technology powering over 15 trillion monthly Lambda function invocations—MicroVMs allow developers to give each user or job a dedicated, isolated compute environment without managing virtualization infrastructure. The service eliminates the historical trade-off between strong isolation, fast startup, and state retention that previously forced developers to choose between competing approaches.

How It Works

• Image creation: Developers package application code and a Dockerfile into a zip archive, upload it to Amazon S3, and call the Lambda API to create a MicroVM image; Lambda executes the Dockerfile, starts the application, and captures a snapshot of the fully initialized environment.
• MicroVM launch: When an isolated environment is needed (per user, job, or session), the developer calls run-microvm, and Lambda launches a MicroVM from the pre-captured snapshot with near-instant startup times.
• Dedicated networking: Each running MicroVM receives its own dedicated HTTPS endpoint supporting HTTP/2, gRPC, and WebSockets—no load balancers or additional ingress infrastructure required.
• Suspend/resume lifecycle: Idle MicroVMs can be suspended (preserving full memory and disk state) to reduce costs, then resumed transparently when traffic returns; this can be triggered automatically via lifecycle policies or programmatically via suspend-microvm and resume-microvm API calls, with a maximum suspension window of 8 hours.
• Termination: When a session ends, the developer terminates the MicroVM to release all resources.
• Full OS capabilities: MicroVMs support installing system packages, mounting filesystems, and fine-grained egress networking including public internet access and VPC connectivity.
• Tooling integration: MicroVMs can be provisioned and managed via the AWS Lambda console, AWS CloudFormation, AWS CDK, or the Agent Toolkit for AWS for agentic workflows.

Why It's Important

• Eliminates a hard architectural trade-off: Previously, developers had to choose between VMs (strong isolation, slow start), containers (fast start, weaker isolation), or FaaS (fast, but stateless and not designed for interactive sessions); Lambda MicroVMs delivers all three properties simultaneously.
• Reduces engineering burden: Building custom virtualization infrastructure for multi-tenant code execution requires deep expertise and significant ongoing operational investment; Lambda MicroVMs offloads this entirely to AWS.
• Enables a new class of AI-native applications: As AI agents increasingly generate and execute code autonomously, having a secure, fast, stateful sandbox per agent or session becomes a critical infrastructure requirement that this service directly addresses.
• Cost efficiency through suspend/resume: The ability to pause idle environments while preserving state means developers are not paying for full VM uptime during user inactivity, making interactive and long-running session workloads economically viable.
• Proven at scale: Firecracker's track record powering Lambda Functions at 15 trillion+ monthly invocations provides strong confidence in the reliability and security of the underlying isolation technology.

How It's Different

• vs. Traditional VMs: VMs offer strong isolation but take minutes to start and require infrastructure management; Lambda MicroVMs provide equivalent VM-level isolation with near-instant launch and zero infrastructure management.
• vs. Containers: Containers share the host kernel, requiring significant custom hardening to safely run untrusted code; MicroVMs use hardware virtualization via Firecracker, providing a stronger security boundary without custom hardening effort.
• vs. AWS Lambda Functions: Standard Lambda functions are optimized for short-lived, stateless, event-driven workloads and are not designed for long-running interactive sessions that retain state across interactions; MicroVMs are explicitly designed for stateful, session-oriented execution.
• vs. Self-managed Firecracker: AWS manages all virtualization infrastructure, networking, snapshot management, and lifecycle operations; developers interact only through a high-level API and console, avoiding the need for in-house Firecracker expertise.
• Dedicated per-user networking: Each MicroVM gets its own HTTPS URL, eliminating the need to build and manage shared load balancer or ingress routing layers common in container-based multi-tenant architectures.
• Snapshot-based startup: Rather than booting from scratch, MicroVMs launch from a pre-initialized application snapshot, making startup times competitive with container cold starts while maintaining full VM isolation.

When to Prefer It

• Interactive coding environments and IDEs: When each user session requires a persistent, isolated terminal or REPL environment that retains state (installed packages, file changes, running processes) across interactions.
• AI agent sandboxes: When an AI coding assistant or autonomous agent needs to execute generated code safely, with each agent or conversation getting its own isolated environment to prevent cross-contamination.
• Data analytics platforms: When end users submit and run arbitrary data processing scripts or notebooks that must be isolated from one another for both security and resource fairness.
• Vulnerability scanning and security tooling: When executing potentially malicious or untrusted code samples in a controlled environment where strong isolation is a hard requirement.
• Multi-tenant SaaS with user-supplied code: When a platform allows customers to write and run custom logic (e.g., plugins, automations, game scripts) and each tenant must be fully isolated from others.
• Long-running interactive sessions with idle periods: When users frequently context-switch away and back, making the suspend/resume capability valuable for cost control without sacrificing session continuity.
• CI/CD job runners: When each build or test job requires a clean, isolated environment that can be launched quickly and discarded after completion.

Availability

• GA Status: Generally available as of June 22, 2026.
• Supported Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland).
• Pricing model: Charged per instance-second for baseline compute resources while the MicroVM is running; additional resources consumed above the baseline are charged only for the active duration of that excess usage; no charge during suspension.
• Suspend/resume limit: MicroVMs can be suspended and resumed for up to 8 hours, after which resources must be released.
• Management interfaces: Available via AWS Lambda console, AWS CloudFormation, AWS CDK, and the Agent Toolkit for AWS (GitHub).
• Connectivity protocols: Each MicroVM receives a dedicated HTTPS URL supporting HTTP/2, gRPC, and WebSockets.
• Networking: Supports both public internet egress and VPC access for private resource connectivity.

Related Resources

• https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html
• https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms
• https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/serverless-skills/aws-lambda-microvms
• https://aws.amazon.com/lambda/pricing/