Give Every Agent Its Own Computer: AWS Lambda MicroVMs

written by Stefan Christoph

- 9 minutes read

🎬 Also available as a blog walkthrough video where I walk through the post and the demo.

TL;DR: AWS Lambda MicroVMs (launched 22 June 2026) gives every user, job, or AI agent its own isolated, stateful compute environment: a Firecracker microVM with VM-level isolation, near-instant launch and resume from a snapshot, and suspend/resume state for up to eight hours, all in one API call with no virtualization infrastructure to operate. Until now you had to pick two of isolation, speed, and state, and run the plumbing for the rest yourself. I built a small demo where Amazon Bedrock writes Python and a per-session microVM runs it, keeps its state across a suspend, and stays sealed off from a second microVM. The code is on GitHub. This is the clean answer to “where does my agent’s code actually run?”
Disclaimer: I’m a solutions architect who builds things to understand them. This is a builder’s field report on a feature I tested and a demo I wrote, not authoritative guidance. If I’ve got something wrong, tell me.

The Idea That Stuck

At a machine learning conference last year, the idea that every AI agent should get its own computer stuck with me. Its own place to run code, keep some state, and not step on anyone else’s work. It made plain intuitive sense. An agent that writes and runs code is a lot less scary when that code executes somewhere boxed off from everything that matters.

The trouble was always operational. Giving each agent a real, isolated environment meant standing up and babysitting infrastructure, and even then you had to choose what to give up. So the idea sat in my head as a nice principle with an expensive footnote.

On 22 June 2026, AWS shipped the primitive that makes “a computer per agent” a single API call. It is called AWS Lambda MicroVMs [1], and it is built on Firecracker, the same virtualization that already powers more than 15 trillion Lambda invocations a month [1] [3].

Pick Two, Then Build the Third Yourself

Run someone else’s code and you want three things at once: strong isolation so a bad snippet can’t reach anything else, a fast start so the user isn’t staring at a spinner, and retained state so the session survives an idle gap. The old menu made you choose.

Virtual machines give you real isolation, but they take minutes to start [3]. Containers start in seconds, but their shared kernel needs serious hardening before you trust it with code you didn’t write [3]. Functions start fast and isolate well, but they are built for short request-response work, not a long interactive session that has to remember what happened a minute ago [3]. You could always wire up Firecracker yourself and get all three, at the cost of operating your own virtualization stack, which is exactly the engineering nobody actually wanted to own.

Lambda MicroVMs collapses that choice. You get VM-level isolation from Firecracker, near-instant launch and resume from a snapshot, and the ability to suspend and resume a running environment with its state intact for up to eight hours [1]. One service, all three, none of the plumbing.

How It Works

The model is image-then-launch. You bake an environment once, then stamp out cheap, fast copies of it [2]:

  1. Bake the image once. Package your application and a Dockerfile into a zip, upload it to S3, and call CreateMicrovmImage. Lambda runs your Dockerfile, starts the app, and snapshots the fully initialized memory and disk.
  2. Launch on demand. RunMicrovm resumes a microVM from that snapshot, so the app is already running the instant the call returns. It did not boot; it resumed.
  3. Connect. Each microVM gets its own dedicated HTTPS endpoint that speaks HTTP/2, gRPC, and WebSockets, with no load balancer to set up. You mint a short-lived auth token and attach it to ordinary HTTPS requests.
  4. Suspend when idle. Memory and disk are snapshotted to a low idle cost.
  5. Resume on demand. State returns intact; from the client’s side, the pause never happened.
  6. Terminate. Release all resources when the session ends, or hand suspend/resume to an idle policy.

Here is the rough shape in two CLI calls:

# 1. Bake the image once (runs your Dockerfile, snapshots the running app)
aws lambda-microvms create-microvm-image \
  --code-artifact uri=s3://<bucket>/artifact.zip \
  --name code-sandbox \
  --base-image-arn arn:aws:lambda:<region>:aws:microvm-image:al2023-1 \
  --build-role-arn <build-role-arn>

# 2. Launch a per-session microVM from the snapshot
aws lambda-microvms run-microvm \
  --image-identifier <image-arn> \
  --execution-role-arn <exec-role-arn> \
  --idle-policy '{"maxIdleDurationSeconds":900,"autoResumeEnabled":true}'

The Demo: Bedrock Writes the Code, a MicroVM Runs It

To make it concrete I wired up the smallest thing that proves the point. A driver script asks Amazon Bedrock to write a Python snippet, then runs that snippet inside a per-session microVM rather than on my laptop. The microVM is the agent’s computer.

One API call returns an isolated microVM with its own HTTPS endpoint, already running. Bedrock writes Python, the microVM runs it, state survives a suspend/resume, and a second microVM starts empty and sealed off. The waits are trimmed to fit; it is a real run in Europe (Ireland).

The clip shows three moves. The first is speed: RunMicrovm hands back an endpoint, and a plain GET answers on the first request because the app resumed from the snapshot instead of cold-starting. The second is state. Bedrock writes a small program, the microVM runs it and gets the answer in a fraction of a millisecond, then I set a variable and write a file, suspend the microVM, and resume it. The variable and the file are still there. The third is isolation: a second microVM launched from the same image starts with an empty workspace and a different identity, with no shared kernel and nothing visible from the first. That is the whole “computer per agent” idea, working.

Not Just My Toy — Claude’s Agents Run Here Too

My demo is deliberately small, but the pattern is not a toy. Anthropic’s Claude Managed Agents [5] use Lambda MicroVMs as a self-hosted sandbox. Anthropic hosts the agent loop and the Claude model; each session’s tool calls — the bash, read, write, edit a coding agent actually runs — execute inside a microVM in your AWS account, on infrastructure you control. You decide what is installed, what network it can reach, and which resources it can touch.

The shape is the same as my demo, just productionised. A session.status_run_started webhook hits a launcher Lambda in your account, which calls RunMicrovm; your worker claims the session, runs the tool calls in /workspace, and posts results back to Anthropic; the microVM is suspended or terminated when the session ends [5]. One microVM per session, never sharing state. Even the secrets are handled carefully: your Anthropic key stays in AWS Secrets Manager and is read by the microVM’s execution role at runtime, so it never travels through the launcher [5]. There is a working reference implementation on aws-samples [6].

That is the part that made this launch click for me. “Every agent gets its own computer” stopped being a tidy principle the moment a frontier-model platform shipped it as the default way to run untrusted agent code — with you owning the environment it runs in. The flexibility cuts both ways: the same primitive backs my fifty-line Bedrock demo and Anthropic’s production agent sandboxes.

Two Gotchas Worth Your Time

The demo went together cleanly in the end, but two things cost me real time, and both are easy to avoid once you’ve seen them.

The first was a trust-policy mismatch. In my testing, the IAM example I copied wrote the build role’s aws:SourceArn condition with a slash before the image name, but the actual image ARN uses a colon. The slash pattern never matched, so the role refused to assume and the build failed with an unhelpful error. A wildcard on the microvm-image prefix fixed it. If your image build fails on an assume-role error, check that condition first.

The second was a Python version surprise. The minimal AL2023 base image I started from ships Python 3.9 when you dnf install python3. My app used str | None union annotations, which 3.9 rejects at import, so the application never finished starting, the readiness hook timed out, and the image build failed. The one-line fix is from __future__ import annotations, or pin a newer Python in the Dockerfile.

There is a subtler one worth knowing. Anything your app computes at import time, including a “unique” identity, gets frozen into the snapshot and is therefore shared by every microVM cloned from it. If you want each microVM to be genuinely distinct, generate that identity in the runtime hook that fires on launch, not at import. That is why the two microVMs in the demo report different IDs.

What It Costs, Roughly

You pay for baseline compute while a microVM is running, and only for the extra resources during the moments your workload spikes above that baseline, with the ability to scale vertically to four times the baseline during peaks [1] [2]. A suspended microVM drops to a low idle cost, which is the point of suspend/resume for bursty interactive work. For the actual numbers, see the Lambda pricing page [4]; I’m deliberately not quoting figures that can drift.

Try It Yourself

The demo is small on purpose: a Flask sandbox app with its lifecycle hooks, a Dockerfile, and a Bedrock-to-microVM driver. It is enough to launch a microVM, have a model write code, run it in isolation, and watch state survive a suspend.

The code is on GitHub: stechr/schristoph-blog-samples → 2026-06-24-aws-lambda-microvms. Clone it, point it at a region where MicroVMs is available (it launched in five, including Europe (Ireland) [1]), and give your agent a computer of its own.

The idea that stuck with me at that conference turned out to need one API call. Where does your agent’s code run today, and what would change if every session got its own machine?

Sources

Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

🎬 Also available as a blog walkthrough video on YouTube

❤️ Created with the support of AI (Kiro)

📝 Last updated: June 24, 2026 — Added the walkthrough video link.