AI agents can generate and execute code quickly, but that means enterprises may not be able to have a person inspect every piece of code before it runs.
AWS said its answer to that problem is Lambda MicroVMs. This service keeps AI agents in lightweight, isolated virtual machines in case the unreviewed code is malicious, flawed or behaves unexpectedly – without the operational burden of deploying traditional VMs at scale.
AWS is positioning the technology as a way to combine the security boundaries of virtual machines with the operational model of serverless computing.
In this email Q&A, Barry Cooks, vice president of compute abstractions at AWS, discusses the security problem Lambda MicroVMs is intended to solve, how the technology differs from traditional virtual machines and Lambda Functions – AWS’ service for running predefined, developer-written code – and where its protections stop.
The AI Innovator: What problem is AWS solving with Lambda MicroVMs?
Barry Cooks: When enterprises adopt agentic workflows at scale, the pace at which code is produced and executed makes rigorous review prior to execution very difficult. Agents generate code on the fly, users submit code in interactive sessions, and the volume keeps growing. The traditional expectation that everything running in production has been thoroughly reviewed simply doesn’t hold in that world.
That creates a tradeoff: Slow down to review everything, or move fast and accept risk. Lambda MicroVMs eliminates that tradeoff. You get VM-level isolation, near-instant launch and resume, and full lifecycle control, so enterprises can keep pace with agentic workflows without accepting the risk that comes from running unreviewed code in a shared environment.
How do Lambda MicroVMs change what enterprises can safely let AI agents do that they might not trust them to do today?
The blocker for most enterprises isn’t whether the agent can write useful code. It’s whether they trust the execution environment. Lambda MicroVMs changes the risk calculus. Each agent session gets its own dedicated virtual machine. No shared kernel, no shared memory, no shared state between users. Even if the agent generates dangerous code, the blast radius is contained to that one environment. It can’t affect other users, other sessions, or the underlying system.
That unlocks use cases enterprises have been cautious about: AI coding assistants that install packages and run builds, security scanners that execute potentially malicious code, data analytics platforms where users run arbitrary queries. The isolation was always the prerequisite. Lambda MicroVMs delivers it without the operational overhead that previously made it impractical at scale.
The idea of virtual machines isn’t new. Why should CIOs choose Lambda MicroVMs?
Traditional VMs solve isolation well. What they don’t solve is operational agility at scale. If your enterprise needs thousands of isolated environments on demand, one per user, one per AI agent session, traditional VMs require capacity planning, provisioning that takes minutes, teams to patch and maintain them, and you pay for idle time around the clock.
Lambda MicroVMs delivers the same VM-level isolation with a serverless operational model. Environments launch in milliseconds from a pre-initialized snapshot. They suspend to drop cost when idle and resume with full state intact, memory, disk, running processes, exactly where they left off. There’s no infrastructure to manage, no servers, no capacity planning, no patches.
The value proposition for a CIO isn’t that we invented VMs. It’s that you get VM-level security with serverless operational simplicity, and your teams stop spending months building isolation infrastructure and start shipping product features.
How will isolating AI agents in its own Lambda MicroVM reduce enterprise risk, and are there still limitations business leaders should understand?
Each agent session runs in a dedicated virtual machine with complete memory and process isolation. No shared kernel, no shared state between users. A compromised or runaway agent cannot access other users’ data or environments. Code execution is fully contained; even root-level access inside the MicroVM can’t escape the isolation boundary. Environments can be terminated immediately, leaving no residual state.
There are boundaries worth understanding. Sessions max out at eight hours, so if you need something running for days, you’ll need to architect around that. We’re in five regions today and expanding. And isolation protects the execution layer, but it doesn’t make the model itself safer. You still need guardrails on what the agent is allowed to generate in the first place.
Is this just another Lambda feature or is there a larger infrastructure vision behind this new offering?
Lambda MicroVMs is a new compute form factor that reflects how AWS sees infrastructure evolving for the AI era.
Lambda Functions solved event-driven compute: stateless, developer-authored code optimized for high-throughput ephemeral workloads like API backends, data transforms, and automation. Lambda MicroVMs solves a different problem: stateful, isolated sessions for user- or AI-generated code with full lifecycle control. They’re complementary, not competitive.
As enterprises build interactive platforms, multi-tenant SaaS, and AI-powered workflows, they need compute that matches new workload patterns. The vision is that as AI agents become the primary consumers of compute, the infrastructure layer needs form factors where lifecycle decisions, when to launch, suspend, resume, terminate, are product logic, not infrastructure operations. AWS Lambda MicroVMs is the first primitive built specifically for that world.
Author
Get the latest insights about enterprise AI.
Subscribe to our newsletter. Thank you.
