What Are AWS Lambda MicroVMs? How Stateful Computing and VM-Level Isolation Are Shaping the Future of Serverless

\n

Serverless: The Function Is Done, but the Server Doesn’t Disappear Anymore

A user asks an AI, “Write this code for me.” A few seconds later, they run the generated code and check the result. But where, exactly, is that code running?

With the traditional Serverless model, the answer was relatively simple. When an event occurs, a function runs, and once the task is complete, the execution environment no longer needs to remain active. For tasks that finish in a single request—such as image resizing, webhook processing, or file conversion—this approach is highly efficient.

But the story changes when you need to run AI-generated code, let users repeatedly modify and execute code in a browser-based IDE, or have an agent carry forward the context of a previous task into the next one. The execution environment can no longer be merely a “function that is called once and then ends.” It must become a workspace that preserves state and context for a certain period of time.

This is precisely where AWS Lambda MicroVMs come in.

While traditional AWS Lambda is optimized for short, stateless, event-driven function execution, Lambda MicroVMs introduce a new Serverless execution environment that combines VM-level isolation, fast startup and resumption, and state preservation. Developers still do not need to provision or operate servers themselves. However, the execution environment does not instantly lose all context simply because a request has ended.

This distinction is especially important in the age of AI. Code generated by AI is convenient, but it is not always trustworthy. It may involve risks such as unintended file access, excessive resource consumption, or calls to vulnerable dependencies. For that reason, it is safer to run generated code in isolated environments separated by task, rather than inside the core process of the application.

Lambda MicroVMs point toward an approach designed for these needs: providing an independent execution space for each user, agent, or task. In other words, it offers VM-like isolation boundaries without requiring developers to operate servers.

Start as simply as a function, but when necessary, carry the task’s context forward like a server.
This is the new vision of Serverless presented by Lambda MicroVMs.

Serverless no longer means only “a function that disappears after execution.” It is expanding into an execution layer that encompasses workloads requiring persistent context and strong isolation—including user code, AI agents, and interactive development environments.

MicroVMs Born at the Boundary Between Serverless and Virtual Machines

Traditional serverless is fast and convenient. Developers only need to write functions, while the cloud handles server provisioning, patching, and automatic scaling. However, the execution environment is fundamentally ephemeral. Because there is no guarantee that the same execution context will remain after an invocation ends, session and task state must be managed separately in external storage such as databases and caches.

Traditional virtual machines (VMs), on the other hand, offer relatively extensive control over the operating system and execution environment, making them well suited to long-running, stateful workloads. However, they also place the burden of instance creation, security patching, capacity planning, failure response, and scaling policies on the operator.

So, is it possible to have the operational convenience of serverless together with the isolation and persistence of VMs? AWS Lambda MicroVMs are a compute model that begins with precisely this question.

A Serverless Execution Environment Beyond Function Execution

Lambda MicroVMs provide small, VM-based execution environments through a serverless model. Developers do not need to create or operate VMs directly, while the execution environment delivers stronger isolation and state-preservation capabilities than a simple, one-off function container.

Three capabilities are at the core of this model:

• VM-level isolation
  Each workload runs in an independent MicroVM, making it possible to isolate untrusted programs such as user code, plugins, and AI-generated code.

• Fast startup and resumption
  Rather than going through the heavy boot process of a traditional VM, the goal is to provide an experience where workloads can start quickly or resume from a previous state.

• State preservation
  Unlike typical FaaS, where the entire context disappears after every invocation, MicroVMs can preserve execution state between interactions. This makes them a more natural fit for session-based tasks and multi-step workflows.

In other words, whereas traditional AWS Lambda is closer to a “function that runs briefly in response to an event,” Lambda MicroVMs are closer to a “stateful, isolated Serverless execution space.”

Bridging the Gap Between FaaS and VMs

Rather than replacing FaaS, MicroVMs complement it by addressing areas that FaaS has traditionally struggled to handle.

| Category | Traditional FaaS | Traditional VM | Lambda MicroVMs | |---|---|---|---| | Operational responsibility | Managed by the cloud | Managed by the operator | Managed by the cloud | | Execution model | Short, event-driven execution | Continuous execution possible | Fast execution with persistent context | | State management | Primarily external storage | Local environment can be used | Supports preservation of execution-environment state | | Isolation level | Function- and container-based isolation | VM-level isolation | VM-level isolation | | Suitable workloads | Webhooks, file processing, queue consumption | Long-running services, complex servers | AI code execution, sandboxes, web IDEs |

For example, tasks that finish quickly on a per-request basis—such as image resizing, payment webhook processing, and message queue consumption—remain highly efficient with traditional Serverless functions. By contrast, workloads where sessions and execution context are important, such as browser-based IDEs, code execution platforms, and validating programs generated by AI agents, may be better suited to the MicroVM model.

Why MicroVMs Matter Now

In environments where AI generates code, users execute code directly in their browsers, and services accept external plugins, executing code itself becomes a security boundary. In particular, AI-generated code must be evaluated not only for whether it functions correctly, but also for risks such as file access, network calls, and excessive resource consumption.

MicroVMs provide this untrusted code with a separate, isolated space while reducing the burden of managing servers directly. In other words, they offer a new option for services that need strong isolation but cannot afford to maintain an entire VM operations team.

Lambda MicroVMs are a representative example of how Serverless is expanding beyond a simple function-execution model into a secure code-execution platform for the age of AI.

The Most Practical Way to Stop Trusting AI-Generated Code in a Serverless Environment

Who can guarantee that code generated by AI is not malicious? The moment a single line of script gains access to the file system, network, or credentials, ordinary function execution alone is no longer enough.

The problem is not limited to AI intentionally generating malicious code. Code that installs the wrong package, enters an infinite loop, prints secrets stored in environment variables, or sends excessive network requests can also pose a serious risk to a service. User-uploaded plugins and automation scripts written by LLMs should be handled according to the same standards.

The most practical principle is simple:

Never run AI-generated code inside a trusted application process.

A suitable option for implementing this principle is a Serverless-based isolated execution environment such as AWS Lambda MicroVMs. Instead of having the application server execute AI-generated code directly, the system delivers the code to an independent MicroVM for each task and retrieves only the result.

Why Isn’t Ordinary Function Execution Enough?

Traditional FaaS is highly efficient for short, well-defined event-driven tasks such as image transformation, webhook processing, and queue-message consumption. AI code execution, however, is different in nature.

• Temporary files and dependencies may need to persist during execution.
• Multiple stages of command execution and debugging sessions may continue over time.
• Execution environments must be separated for each user.
• Access to external networks, file systems, and credentials must be controlled.

In such cases, the simple model of “calling a function” makes it difficult to design sufficient session persistence, isolation boundaries, and execution policies. Lambda MicroVMs provide VM-level isolation and state preservation while relieving developers from having to operate VM provisioning, patching, and capacity planning themselves.

A Secure Architecture for Executing AI-Generated Code

The recommended architecture separates the frontend, the trusted API layer, and the untrusted code-execution layer.

1. The user requests code execution.
2. The API validates the code and execution policy, then creates a MicroVM execution task.
3. The isolated MicroVM runs the code with restricted permissions.
4. Only the necessary results—such as standard output, error logs, and generated files—are returned to the API layer.
5. Once execution is complete, the environment is discarded according to policy, or its state is preserved only for approved sessions.

The core principle of this structure is to retrieve the execution results without handing over execution privileges. Even if the AI-generated code fails or behaves unexpectedly, the potential damage can be confined to that MicroVM and that individual task.

Security Principles That Must Be Applied Alongside It

Introducing MicroVMs does not automatically make the system secure. The principle of least privilege must still be applied within the isolated environment.

• Minimize IAM permissions: Grant the execution environment only the AWS permissions it absolutely needs. Wherever possible, leave its default permissions nearly empty.
• Block the network by default: Restrict external communication by default and allow only necessary destinations, such as package repositories or internal APIs.
• Use short-lived credentials: Instead of long-term access keys, use tokens with limited scope and short expiration times.
• Set resource limits: Limit CPU, memory, disk space, execution time, and concurrent executions to prevent infinite loops and resource exhaustion.
• Separate sensitive information: Do not inject environment variables, secrets, or production database credentials directly into the code execution environment.
• Maintain observability and audit logs: Record the execution requester, code hash, network attempts, and error logs so that incidents can be investigated and handled effectively.

Operational Benefits of Serverless

Traditional sandbox servers require teams to manage pools of containers or VMs directly. Infrastructure must remain available even during periods of low demand, while image updates, security patches, and autoscaling policies also fall to the operations team.

By contrast, the Serverless MicroVM approach reduces the burden of provisioning and scaling execution environments. It is especially advantageous for services with irregular workloads, such as online IDEs, educational coding platforms, AI agent platforms, and vulnerability-scanning SaaS products.

Ultimately, the important thing is not to treat AI like a “trusted developer.” AI-generated code should be handled just like code uploaded by an external user and executed in an independent environment with minimal privileges. This is the most practical and scalable code-execution security strategy for the age of AI.

AI Agents and Serverless: A New Operating Model That Rents a Server for Every Task

We are entering an era in which AI agents generate code for each task, execute it, analyze errors, and then revise it. In this environment, is simply keeping a few fixed servers running at all times really enough?

The code generated by agents is difficult to trust, workloads are hard to predict, and execution environments must be completely isolated from one another. AWS Lambda MicroVMs address these challenges by introducing a new Serverless operating model in which AI agents obtain their own isolated execution space only when they need it.

Create an Execution Environment Only When the Agent Needs One

With the traditional server operating model, the servers that applications or agents will use must be prepared in advance. Even when traffic is low, those servers continue running, and additional capacity must be reserved to handle sudden spikes in workload.

MicroVMs change this process.

When an AI agent requests a task such as code execution, testing, vulnerability scanning, or data processing, AWS prepares the execution environment it needs. Once the task is complete, there is no need to manually clean up or patch the infrastructure. Instead of managing server life cycles, development teams can focus on the agent’s workflow and permission policies.

In other words, this is less like always owning servers and more like renting a secure execution space on a per-task basis.

Handle Everything from Code Generation to Revision in an Isolated Workspace

The typical workflow of an AI agent is more complex than a simple API call.

1. The agent interprets the requirements.
2. It generates code.
3. It runs or tests the generated code.
4. It analyzes error logs and results.
5. It revises the code and runs it again.

This process may require temporary files, dependencies, execution results, debugging information, and other session state. In a completely stateless FaaS environment, that state must continually be moved to an external database or storage system, which can make interactive execution flows more complicated.

Lambda MicroVMs are designed to support state persistence in the execution environment. This makes it easier to build a structure in which a single agent task can continue across multiple stages while leveraging the context from previous executions. For example, they are well suited to the iterative workflow of a coding agent that creates project files, runs tests, and modifies the code based on failed tests.

Not “One Server per Agent,” but “One Isolated Space per Task”

The important point is that MicroVMs are not simply a technology for providing faster servers. Their core value lies in VM-level isolation.

Code generated by AI, scripts uploaded by users, and code from external plugins can all be potentially dangerous. They should therefore never be executed directly within the application’s core backend processes.

An architecture based on MicroVMs makes it possible to achieve the following separation:

• Isolated execution environments for each agent or user
• Minimizing the impact of a code execution failure on other tasks
• Containing malicious code or excessive resource consumption
• Fine-grained IAM permissions and network policies for each task
• Limiting access through short-lived credentials

For example, in a SaaS-based AI coding platform, there is no reason to process code created by User A and User B within the same execution process. Running each task in an independent MicroVM makes it possible to contain failures and security risks within smaller boundaries.

How the Serverless Operating Model Changes the Division of Responsibilities

Under this model, developers do not directly manage VM images, patch operating systems, respond to host failures, or plan capacity. AWS handles the provisioning, scaling, and maintenance of the execution environment, while teams focus on application-level controls such as:

• Deciding which tasks should run in MicroVMs
• Designing CPU, memory, and time limits for each task
• Configuring least-privilege IAM policies
• Applying network policies based on a default-deny principle
• Collecting execution logs and audit records
• Defining retry and disposal policies for failed tasks

This goes beyond the simple idea of “not operating servers.” It means designing a structure in which an AI agent requests an execution space only when needed, completes its work in an isolated environment, and then disappears.

A Realistic Architecture That Combines Fixed Servers and MicroVMs

There is no need to move every workload to MicroVMs. For general web APIs, webhook processing, image conversion, and queue-based asynchronous tasks, existing FaaS offerings such as AWS Lambda may be simpler and more efficient.

A practical architecture could divide responsibilities as follows:

• Frontend, APIs, and event processing: Existing Serverless FaaS and managed services
• Session and business data storage: Databases, object storage, and caches
• AI inference and vector search: Managed AI and vector services
• Execution of AI-generated and user-provided code: Sandboxes based on Lambda MicroVMs

Ultimately, MicroVMs do not completely replace existing servers. Instead, they serve as the execution layer for the newly emerging untrusted code execution domain in the age of AI agents. For services in which agents generate code and validate it themselves, the critical question is no longer, “How many servers should we operate?” It is now: “How safe and independent an execution space can we provide for each task?”

The Core of Serverless Design: Not Every Workload Needs MicroVMs

Just because a technology is new does not mean every service should be moved to MicroVMs. In fact, a good architecture is not one that uses the most cutting-edge technology, but one that chooses an execution model suited to the characteristics of the workload.

AWS Lambda MicroVMs provide powerful advantages, including VM-level isolation, state persistence, and fast startup and restart times. However, these strengths truly shine in scenarios involving untrusted code execution, session persistence, and interactive workloads. Migrating even simple event processing to MicroVMs can introduce unnecessary complexity and cost.

Workloads Well Suited to MicroVMs

MicroVMs are worth considering first in the following cases:

• Executing code generated by users or AI

  • Online IDEs, code-grading services, and plugin platforms
  • Services that validate scripts or automation code generated by LLMs
  • SaaS applications that need to isolate execution environments for each user

• When the execution environment must preserve state

  • Long-running development sessions
  • Debugging and REPL environments
  • AI agents that need to retain task context across multiple steps

• Multitenant environments requiring strong isolation

  • Services that need to separate execution processes by tenant
  • Security services that analyze potentially malicious code or files
  • Vulnerability scanning and sandbox-based validation environments

For these workloads, MicroVMs are a more natural fit than traditional function-based execution models. They allow each user or task to have an independent environment while reducing the burden of server provisioning and operations through a Serverless approach.

Workloads Where Traditional Lambda Is More Efficient

Conversely, not every task requires state persistence and VM-level isolation. For the following types of work, a FaaS model such as traditional AWS Lambda is simpler and more efficient:

• Resizing images after an S3 upload
• Receiving webhooks and calling external APIs
• Processing SQS or Kafka messages
• Running scheduled batch jobs and sending notifications
• Data transformation, log cleanup, and certain stages of ETL
• Handling short-lived HTTP requests

These tasks generally follow a structure in which one event is completed by one function execution. There is little reason to preserve the state of the execution environment, and they do not involve untrusted code. In such cases, a proven Lambda-based Serverless architecture is faster to implement and easier to operate.

The Key Criterion Is Not “How New the Technology Is,” but the “Execution Boundary”

When deciding whether to adopt MicroVMs, it is useful to ask the following questions:

1. Is this code untrusted code generated by a user or AI?
2. Does the execution environment itself need to preserve state between invocations?
3. Is strong isolation required for each user, tenant, or agent?
4. Are long-running sessions and interaction more important than processing individual events?
5. Can the requirements not be met using only traditional Lambda combined with an external database and cache?

If the answer is “yes” to several of these questions, MicroVMs are likely to be a good fit. On the other hand, if the workload is short-lived, stateless, and event-driven, retaining traditional Lambda is the more reasonable choice.

A Practical Architecture: Separating the Roles of Lambda and MicroVMs

In practice, it is often more effective to divide responsibilities according to the role of each service rather than choosing only one of the two.

• Traditional Lambda: API processing, event collection, authentication, file processing, and queue-based asynchronous tasks
• MicroVMs: Executing AI-generated code, user-specific development environments, plugin sandboxes, and security analysis
• External data layer: Relational databases, NoSQL, object storage, Redis, and vector databases

For example, in an AI coding service, login, billing, and project storage APIs can be handled by traditional Lambda, while MicroVMs are allocated only when the user presses the execution button. This preserves the operational efficiency of a typical Serverless architecture while strongly isolating only the most dangerous and state-dependent code execution paths.

Ultimately, true architectural skill does not lie in applying MicroVMs everywhere. Using MicroVMs where isolation and state are required, and traditional Lambda for simple event processing, is the practical strategy that balances cost, security, and operability.