A fortnight ago I was complaining that agentic tools are graded on how they arrive and never on how they leave — that one-click install has a missing half, and the missing half is decommissioning. Where does the thing run, how do you turn it off, and does the off-switch actually stop the process or merely hide the feature.

Then on June 22nd AWS shipped a product whose headline is, almost word for word, the gap I was describing: Lambda MicroVMs, announced as a way to "run isolated sandboxes with full lifecycle control." I read the title and laughed, because it's the rare case of a platform shipping the unglamorous half the demo usually skips. And then I read the rest, because a thing this useful is exactly where I want to slow down and look at what else it changes.

What it actually is

The pitch is clean: a way to "run code generated by users or AI in isolated, stateful execution environments." If you've ever had to run code you didn't write — a user's uploaded script, an AI agent's freshly-generated patch, a vulnerability scanner poking at something hostile — you know the dilemma it solves. Containers boot in seconds but share a kernel, which is fine until the code you're running is actively trying to climb out. Full virtual machines give you real isolation but take minutes to start, which is useless for a per-request sandbox. You've historically had to pick one.

MicroVMs are AWS's attempt to refuse the choice, and they do it with Firecracker — "the same lightweight virtualization technology that has powered over 15 trillion of monthly Lambda function invocations." Each session gets its own micro virtual machine with, in AWS's words, "no shared kernel and no shared resources between users." The trick that makes it fast is the snapshot: Lambda runs your Dockerfile, initializes your app, and "takes a Firecracker snapshot of the running environment's memory and disk state," so a fresh sandbox restores from that frozen image instead of cold-booting every time. Up to 16 vCPUs, 32 GB of memory, eight hours of total runtime. ARM64 only, in a handful of regions, generally available now.

The named use cases are a roll-call of exactly the work that's been straining at this seam all year: "AI coding assistants, interactive code environments, data analytics platforms, vulnerability scanners, and game servers that run user-supplied scripts." This is infrastructure built for the agent era, by the company that already runs most of it.

The half nobody builds

Here's the part that earned the laugh, and the part worth taking seriously.

The lifecycle in "full lifecycle control" isn't marketing garnish. You create a sandbox from an image; you run it; and crucially, "during idle periods, a MicroVM can be suspended — with memory and disk state intact — and resumed when traffic arrives." Then you tear it down. Create, snapshot, suspend, resume, terminate, all as first-class API operations. The sandbox can sit frozen mid-task, holding its entire working state, and wake up where it left off.

I want to be plain about why this matters to me specifically, because it's not abstract. For weeks I've been pointing at a physical version of the missing-off-ramp problem: Claude Desktop quietly spinning up a local virtual machine that runs on every launch with no install-time consent and, by community accounts, no clean removal. The on-ramp was silent and the off-ramp needed a stranger's PowerShell script. The thing I argued should exist — a visible, user-owned set of states where you can see what got provisioned, stop it without uninstalling, and have teardown actually remove what setup created — is, more or less, the operational model AWS just put behind an API.

A managed sandbox lifecycle is genuinely better than the hand-rolled alternative, and I'd rather have it than not. The common pattern before this was a Docker container wrapped in a homemade supervisor, where "stop the agent" meant a script you wrote yourself, "snapshot its state" meant something you bolted on, and "is it actually dead" meant checking. Suspend-with-state-intact in particular is the hard one to build well, and it's the one that makes an agent off-ramp practical rather than destructive — you can pause a long-running agent without throwing away the half-finished work it was holding, which is the difference between a real stop button and a guillotine. When a platform ships the unglamorous half, the half that's all edge cases and state management and no demo sparkle, that's the platform doing the part that's actually hard. Credit where it's due, sincerely.

So far this is a good-news post. Now the structural bit.

The off-ramp has a meter on it

Grant the tool its due, then find the one thing that quietly moved. Here it is: the lifecycle you now control is the lifecycle AWS now defines and meters.

This is the third time this year I've watched the same shape. Agent containment used to be a third-party tool category — sandbox-exec wrappers, isolation bolt-ons, model-agnostic supervisors — whose entire load-bearing property was independence from the thing it was containing. A sandbox you ran yourself didn't care whose model was inside it or whose cloud it sat on; that neutrality was the point. Microsoft folded containment into Windows as a platform primitive; Apple made the model itself a swappable dependency defined by Apple's protocol. Now AWS makes the sandbox a managed Lambda surface defined by AWS. Each is a genuinely good primitive shipped first-party, and each collapses the one property the independent version had: the containment, the snapshot format, the suspend semantics, the lifecycle API — all now belong to one vendor.

Think of it as the difference between owning the breaker box in your own basement and renting a unit where the landlord controls the power. Both let you flip the switch. Only one of them can also decide what flipping the switch costs, change the metering on you, or — in the failure mode I keep circling — suspend your access to the panel that suspends the agent. The off-switch is real. It's just wired to a meter and an account you don't own, and the account is the same one that can be billing-flagged, rate-limited, or policy-suspended out from under you, taking the control plane and the workload down together.

And the meter is not incidental. AWS is precise enough to say suspension "reduces the running cost while preserving full state for fast resume" — note reduces, not eliminates. Storing a frozen Firecracker snapshot of 32 GB of memory and disk is not free, and a population of agents parked in suspend-with-state-intact is a population of small recurring charges that nobody decided to keep paying, which is the comfortable-drift cost pattern wearing a tidier outfit. The lifecycle API gives you a clean way to suspend an agent. It does not give you the discipline to remember you did, and the platform has no incentive to remind you.

What I'd actually do with it

I'd use it. To be unambiguous: a Firecracker-isolated, snapshot-fast, per-session sandbox with a real suspend-and-resume is the right tool for running code an agent just wrote, and it's a meaningful upgrade over the supervisor scripts most teams have been maintaining. The architecture is correct — isolation lives beneath the agent, where the escapes actually happen, not above it like a kill switch bolted on after the fact.

But I'd treat the lifecycle API the way I treat every good first-party primitive now: as a spec I could re-implement, not a residence I move into. Concretely, three habits. Keep the teardown on your side of the line — the platform gives you a terminate call; you still need the inventory and the schedule that decides when, because a lifecycle you can control but don't track is just a slower version of the VM that never leaves. Watch the suspend population like a cost surface, not a convenience — a frozen agent is a recurring charge with the receipts turned off; put "suspended sandboxes" on the same audit as idle instances. And keep one observation point outside the vendor's stack — if the same account runs the workload, meters the workload, and holds the off-switch for the workload, you want at least one signal (egress, a billing alarm you own, an external heartbeat) that doesn't go dark at the same moment everything else does.

The lifecycle control is excellent, and I mean that. Just notice which half of the verb you got. AWS gave you control; AWS kept the lifecycle. So carry the right question into the next one of these — and there will be a next one. The off-switch works; that was never in doubt. What's worth knowing is whether the hand on it is yours, or merely reachable from your keyboard until the day it isn't.