AWS Lambda MicroVMs: Secure AI & Untrusted Code Execution
Every team that has tried to run code it did not write has hit the same wall. The moment your product lets a customer upload a script, or you let an AI agent execute the code it just generated, you are responsible for keeping that code from touching everything else you run. Until now the only honest answers were to spin up a fleet of throwaway virtual machines and babysit them, or to bolt on a third party sandbox and hope it holds. AWS Lambda MicroVMs, announced at the AWS Summit in New York and now in preview, gives you a managed way to run that code with real virtual machine isolation and no servers to manage, and it matters because the number of businesses running customer code or AI output has gone from a niche to a default.
In short, Lambda MicroVMs is a new serverless compute primitive that puts each session in its own dedicated micro virtual machine with no shared kernel and no shared resources between users, so untrusted code from one customer cannot reach another customer or the underlying system. It launches in near real time using Firecracker snapshots, it preserves memory and disk state, and it can suspend an idle environment and resume it later with everything intact for up to eight hours. You pay for what runs, you do not run the virtualization layer, and you get fine grained control over networking on the way in and out. For anyone building AI agents, code interpreters, or multi tenant execution features, this closes a gap that used to demand a dedicated platform team.
Why Isolation Stopped Being Optional
For most of the last decade, the riskiest code most businesses ran was their own. You trusted your engineers, you reviewed pull requests, and the blast radius of a bad deploy was your own service. That assumption quietly broke. If your product runs customer supplied scripts, if you offer a notebook or a plugin system, or if you have wired an AI model into a loop where it writes code and then runs it, you are now executing software that nobody on your team read before it ran. That is a different security posture and it needs a different boundary.
Containers were never designed to be that boundary. They share a kernel with the host, and a shared kernel means a single kernel level escape can put one tenant’s code in reach of another. Plenty of teams run untrusted workloads in containers anyway, and they spend real engineering effort hardening them with seccomp profiles, user namespaces, and gVisor style runtimes to make up the difference. It works until it does not, and the failure mode is the kind that ends up in an incident review and a customer email. A micro virtual machine raises the wall. Each environment gets its own kernel and its own slice of hardware, so the thing keeping tenants apart is the hypervisor rather than a set of container flags you have to get exactly right.
What AWS Lambda MicroVMs Actually Gives You
The headline is isolation, but the design choices around it are what make this usable rather than just secure. Each session runs in its own micro virtual machine built on Firecracker, the same lightweight virtualization technology that already sits underneath Lambda and handles more than fifteen trillion function invocations a month. That pedigree matters, because it means the isolation model has been tested at a scale very few platforms will ever see.
The second thing you get is state. A normal Lambda function is stateless by design, which is fine for request and response work but useless when you need an environment to remember what happened a moment ago. MicroVMs preserve memory and disk between invocations within a session, so an AI agent can install a package, write a file, run a command, read the result, and keep going without rebuilding its world every step. That single change is what turns serverless from a request handler into something that can host an interactive session.
The third thing is suspend and resume. When a MicroVM goes idle, it suspends and preserves both memory and disk while it sleeps, which means you stop paying for it to sit there. When the next request arrives it resumes with everything exactly where it was. You can drive this with a lifecycle policy, for example suspending automatically after fifteen minutes of inactivity, or you can call the suspend and resume operations directly from your own code. State can be held this way for up to eight hours, which covers the natural rhythm of a user who steps away and comes back. The result is the economics of serverless applied to a workload that used to force you to choose between paying for idle machines and throwing away expensive setup work.
Finally you get control over the network on both sides. On ingress you can manage port access and support modern protocols including HTTP/2, gRPC, and WebSockets, which means real interactive applications and not just batch jobs. On egress you choose whether the environment can reach the public internet or only your VPC, which is exactly the lever you want when the code inside is something you do not fully trust.
Where This Earns Its Keep
The clearest fit is AI agents that execute code. If you are building an agent that reasons by writing and running scripts, you need somewhere for that to happen that is fast to start, holds state across steps, and cannot reach the rest of your account if the model does something unexpected. That is the exact shape of a MicroVM. The agent gets a stateful sandbox per session, you get a hard boundary, and you do not stand up a Kubernetes cluster to make it happen.
The second fit is any product feature that runs customer code. Online coding platforms, data tools that let analysts run their own transformations, automation products that execute user defined steps, and anything with a plugin model all share the same need. Each customer session can run in its own isolated environment, and because idle environments suspend rather than burn money, you can offer this without your cost line scaling linearly with every dormant session.
The third fit is the messier middle ground of internal tooling, where an engineer wants to give the wider company a way to run a script or a report without handing out broad access to production. A MicroVM per request gives you a clean, disposable, isolated place for that work with permissions scoped to exactly what the job needs.
How It Compares to What You Are Probably Doing Now
If you run untrusted code today, you are almost certainly doing one of three things. You might be running it in hardened containers and carrying the ongoing burden of keeping that hardening correct as your platform and the kernel change underneath you. You might be spinning up and tearing down EC2 instances or Fargate tasks per job, which gives you strong isolation but leaves you owning orchestration, cold starts, and the cost of capacity that sits idle between jobs. Or you might be paying a third party sandbox provider, which works but adds a vendor, a data path outside your account, and a bill that climbs with usage.
MicroVMs collapse those trade offs. You get the isolation of a separate virtual machine, the startup speed of a snapshot rather than a cold boot, the cost profile of suspend on idle rather than pay for idle, and the operational load of a managed service rather than a platform you maintain. It is not the right tool for every workload, and for trusted first party code that does not need a hard tenant boundary a plain Lambda function or an ECS service is still simpler and cheaper. The point is narrower and more useful than a replacement for everything: when the code is untrusted or generated and you need it isolated, stateful, and cheap at rest, this is now a first class option on AWS rather than a platform you have to build.
What to Do About It
Start by being honest about where you already run code you did not write, because most teams have more of it than they think once AI features and customer scripts are counted. List those workloads and look at how each one is isolated today. If the answer for any of them is a shared kernel container running untrusted input, that is the first candidate to move. Then map the lifecycle: how long a session needs to live, how much state it needs to hold, and what it needs to reach on the network, because those three answers tell you whether MicroVMs fit and how to set the suspend policy and egress rules. Since the feature is in preview, treat the first move as a controlled pilot on one workload, measure the cold start and resume behaviour against your real traffic, and confirm the cost model holds up once idle environments are suspending as expected before you commit a customer facing feature to it.
If you are building anything that runs AI generated code, or you already operate a feature that executes customer input and you have been quietly worried about the isolation behind it, this is worth a serious look now rather than after an incident force the question. HAZERCLOUD helps founders and engineering teams design these execution boundaries properly, choose between MicroVMs, containers, and dedicated compute for each workload, and roll them out without surprises in the security review or the bill. If you want a clear assessment of how your untrusted and AI generated workloads should run on AWS, get a free consultation at https://hazercloud.com/contact/ and we will map it with you.
