Morgan's Blog

not an expert, always learning

No. 4835 words

AWS Nitro Sandboxes are a big deal, but I don’t think they’ll kill the agent sandbox space

Yesterday Amazon announced AWS Nitro Sandboxes and my timeline on X has been going bonkers about them, for good reason. I saw a lot of confusion about what AWS Nitro Sandboxes are, and why everyone is getting so excited about them so I’ll start by explaining what they are.

Right now, a lot of people are running agents in containers, but you can think of those containers like apartments in an apartment building. For anyone that has lived in an apartment building, you know plumbing, wiring, it’s all connected, shared by every apartment. Now to translate this into computer terms, think of all this wiring and plumbing, that’s shared by all the apartments as the operating system kernel.

A lot of teams run their agents in regular containers, and containers on the same machine all share one host kernel. This means that if one container gets compromised, this can spread to other containers. Just like in the apartment building, if someone messes with your water pipes and introduces a contaminant, that can easily spread to your neighbor’s pipes, because they’re all connected.

The normal(ish) way this has been handled is to use a dedicated machine for each sensitive workload, but holy moly is this both expensive, and a total waste of capacity since you rarely need a whole machine.

So now let’s talk about Nitro Sandboxes, and continue to extend the analogy here. Instead of each container being an apartment in an apartment building, think of each one as getting a tiny house, each with its own utilities, but all on the same plot of land. Now, if there’s a contamination issue, it just impacts that one house, not all the others.

Neat right?

Now I’m seeing a lot of tweets show up on my TL saying that Amazon is killing the agent sandbox space, but I’m not quite sure that’s the case.

If you look at solutions like Vercel Sandbox or Boat.dev, they also give every sandbox its own VM and kernel, the core difference here is really just what servers it runs on. What’s kinda funny is that Vercel Sandbox already runs on Firecracker, which AWS built and open-sourced years ago, and it’s the same thing AWS recommends for Nitro Sandboxes.

Boat.dev takes a similar path, giving you full Ubuntu VMs.

Now to be fair here, the one real security edge Nitro has is a “confidential” mode that keeps your sandbox private even from whoever runs the server, which matters a lot for regulated companies. And yes, this is an area where existing teams, using AWS, will probably use Nitro over another sandbox, but I think this is a fraction of the market.

Okay now let’s talk cost, since this is what I think a lot of people are pointing out, which is a fair point. Nitro runs on EC2 instances, that if you use AWS, and are already paying for, then yes, it could be cheaper, but you’re paying for those EC2 instances whether they’re busy or not, so you’d better keep them busy.

But you have to set up and manage everything yourself. Here’s an example.

Boat.dev sandboxes come with a full root Ubuntu VM, so you get Docker, every toolchain, public IPv4, etc. The VM stops to a snapshot when it’s idle and resumes exactly where it left off, and you get forking, a virtual desktop, and a CLI that can run things like Claude Code and Codex inside it. Nitro doesn’t have any of this, sooooo, you would have to set it all up yourself.

It’s kinda like saying S3 should kill Dropbox and Box, and yes, you can do everything Dropbox and Box can do, with S3, but then you essentially have to build your own version of Dropbox and Box, deploy it to your team, etc.

If you have a dev team that wants to use agent sandboxes, you can of course build your own version of something like Boat.dev or Vercel sandboxes, and run them on AWS w/Nitro, but then you’re owning that whole layer, and I think that’s going to cost a lot to manage at scale.

Going back to my analogy from the beginning to tie this all together, and because I love analogies.

Tiny houses already existed, but only in other people’s villages. What’s new is that AWS now lets you build them on your own land for free. But you still have to furnish the house, get Internet rocking, install a Ring doorbell on your door, get the lighting you like, etc. If you like the idea of setting up tiny houses for every engineer on your team, furnishing them, etc. sure, you can save raw cost by using Nitro, with your existing EC2 instances.

But just like Dropbox or Slack, which you could also build your own version of and scale out to your team…do you really want to take this on when you can pay someone else a fraction of what it would cost you, to do it for you?


Further roving

  1. No. 3
  2. No. 2
  3. No. 1