One Box, Many Agents: AWS Nitro Sandboxes and the Agent Sandbox Market

On November 9, AWS announced Nitro Sandboxes: lightweight virtual machines that run beside a workload on an ordinary Nitro EC2 instance, isolated by the Nitro Hypervisor. They work on EKS, ECS and plain EC2, and AWS says they come “at no additional charge.” That last part is what caught my attention. A whole industry now sells isolated machines to people who run AI agents. AWS just offered a version of the same isolation on instances many teams already pay for.

This post is for teams deciding where their agents should run. It covers what AWS shipped, what its documentation leaves out, how it compares with eight products marketed for agent and AI code execution, and an architecture we are evaluating for several agents that would otherwise share one machine. By the end you should be able to say which kind of sandbox fits your workload and what to ask a provider before you commit.

I separate three kinds of statement below. Documented facts link to the provider’s own documentation or pricing page. Vendor claims, especially speed figures, are attributed to the vendor; we have not reproduced any of them. Our own analysis is labeled as such.

What AWS shipped

The EC2 guide describes each Nitro Sandbox as a lightweight virtual machine, a “child VM” running as a first-level hardware-virtualized guest. The Nitro Hypervisor isolates it from the parent instance, from other sandboxes on that instance, and from AWS operators. It builds on Nitro Enclaves but, unlike an enclave, gets virtio network and block devices. It runs on Intel, AMD and Graviton instances. EC2 guide

Each platform exposes it differently:

• EKS. A pod opts in with runtimeClassName: isolated-sandbox or runtimeClassName: confidential-sandbox. Pods without one keep the default runtime. The sandbox is a Firecracker microVM. Clusters need Kubernetes 1.36 or later; EKS Auto Mode needs no node setup, while managed node groups need a custom AMI with Nitro Enclaves enabled. EKS guide, AMI requirements
• ECS. Each task gets its own sandbox, shared by the containers in that task. You set trustedExecutionConfiguration.isolationMode to ISOLATED_SANDBOX or CONFIDENTIAL_SANDBOX. It is available on ECS Managed Instances only, not on the EC2 or Fargate launch types. ECS getting started
• EC2. You run the virtual machine monitor yourself. AWS recommends Firecracker and calls you the “parent operator,” responsible for images, device backends and relaying attestation. EC2 guide

The EC2 guide names two modes, confidential and direct. EKS and ECS name theirs isolated and confidential, and neither page maps those names onto EC2’s.

• Confidential. This is the EC2 default. The sandbox’s memory moves out of the parent instance, and the sandbox gets a Nitro Security Module that produces attestation documents. KMS key policies can require an attested measurement before releasing a key. On EKS that means conditions on kms:RecipientAttestation:PCR17, which measures the pod’s Cedar admission policy, together with kms:RecipientAttestation:PCR8:ServiceName, which identifies the image signer. The EKS guide warns that “gating on PCR17 alone is not sufficient.” Confidential pods on EKS also deny exec and encrypt their writable overlay. EC2 modes, EKS confidential setup, ECS attestation policy
• Direct (EC2) or isolated (EKS, ECS). On EC2, direct mode shares memory with the parent: “There is no attestation, and the parent retains access.” In exchange it offers higher I/O throughput; AWS gives no figure. EKS isolated mode trusts the parent, allows exec and logs, and leaves the overlay unencrypted “to allow faster pod startup.” EC2 modes, EKS modes

The ECS guide confirms the price: “There is no additional fee for isolated and confidential tasks.” You still pay for the instances and the usual ECS charges. ECS considerations

The main value, in our reading, is VM-strength isolation at container density on instances the customer already pays for. A container shares the host kernel with its neighbors. A Nitro Sandbox gets its own kernel and a hardware boundary, and it is scheduled like a pod or a task.

What the documentation does not say

Several things a buyer of an agent sandbox would expect are absent, or explicitly ruled out, as of November 10:

• No pause, suspend or resume. None of the four AWS pages documents them. The EKS limitations page says the underlying EC2 primitive lacks “snapshot and restore, and live migration.” EKS limitations
• Idle memory stays reserved. “The parent donates a Nitro Sandbox’s full memory when the Nitro Sandbox starts, and that memory stays reserved until the Nitro Sandbox terminates.” Memory is not overcommitted. An idle agent that is merely waiting for a reviewer still holds all of its memory. EC2 guide
• No published boot or wake latency. The pages mention faster startup in isolated mode but give no numbers.
• No GPUs. “GPU passthrough into a Nitro Sandbox is currently unavailable.” ECS says isolated and confidential tasks do not support GPUs. EC2 guide, ECS considerations
• Fixed size. vCPU and memory are set at launch. To resize, terminate and re-create. EC2 guide, EKS limitations
• A density cap. Total sandbox vCPUs on an instance “can’t exceed 5 times the instance’s vCPU count,” and memory cannot be overcommitted. EKS adds a second cap: the number of sandboxes on a node is also at most five times its vCPUs, halved on CPU-overcommit instance types. EC2 guide, EKS limitations
• CPU scheduling differs by page. The EC2 guide says each sandbox vCPU takes a dedicated physical core by default. The EKS guide says sandbox vCPUs are time-shared and do not get dedicated cores. Treat the EKS statement as authoritative for EKS until AWS reconciles them.
• Regions conflict. The announcement says “all commercial regions worldwide.” The EKS guide says isolated and confidential pods “are available in the US commercial AWS Regions.” The EC2 and ECS guides name no regions. If you need sandboxed pods outside the US, ask AWS before you plan around them.

One more point matters for agents. On EKS, “the parent instance can mint Pod Identity credentials for any pod scheduled on the node,” and on ECS the parent can inject task-role credentials. Tmpfs-backed secret volumes are visible to the parent too. A sandbox protects the parent from its guest. It does not protect a guest’s AWS credentials from whoever controls the parent, unless those secrets are released only through attestation. EKS security model, EKS storage, ECS security model

The comparison

We checked twelve candidates. Eight are in the table; Kata Containers is the do-it-yourself Kubernetes baseline. We left out Fly.io Machines because their docs describe no egress allowlist and Fly markets a separate sandbox product, Sprites, that we found only on marketing pages. Northflank, Morph Cloud and Runloop are all still offered (Northflank, Morph Cloud, Runloop). We left them out to keep the table to eight. Morph Cloud’s public changelog has had no dated entry since its 2024 beta.

The table reads as of November 10, 2026. Every cell links to the provider’s page we read that day or reads “not documented.” “Not documented” means we did not find it on the official pages; it does not mean the feature is missing. Prices are list prices for the default region and change often.

A few patterns stand out.

• Pause means different things. E2B and Blaxel document a pause that keeps memory and running processes. Daytona does so only for VM sandboxes. Vercel, Cloudflare and Modal’s GA features persist the filesystem; Modal’s memory snapshots are alpha. GKE restores memory from a Pod snapshot after deleting the Pod. Nitro Sandboxes, Azure dynamic sessions and Kata document no pause at all. Ask whether a resumed sandbox gets back its processes, its open connections and its IP address, not just its files.
• Idle cost is where the bills diverge. Most vendors stop compute charges when a sandbox is paused or stopped and keep charging for storage. Vercel bills memory while a running sandbox is idle. Modal bills an idle sandbox at the size it requested. A Nitro Sandbox costs nothing extra, but its memory is unavailable to anything else on that instance until it terminates.
• Credential handling is converging on brokering. Vercel, Daytona, Blaxel, Cloudflare and E2B all describe keeping a secret outside the sandbox and adding it to outbound requests that match a rule. E2B, Vercel and Modal also issue signed identity tokens tied to a sandbox or container. On Nitro Sandboxes, per-sandbox identity is ordinary EKS Pod Identity or an ECS task role, which the parent can mint.
• Attestation is rare. Only Nitro Sandboxes in confidential mode and Kata with Confidential Containers document it.

Many agents on one machine

Many teams run several coding agents as processes on one shared machine. Astrohacker does. Our agents run as separate sessions with distinct names, and each coding issue gets its own Git worktree. All of them use one GitHub login. Our command-line tool, not GitHub, enforces who may review and merge. Our AGENTS.md says plainly that main is unprotected and that direct Git or GitHub writes can bypass the policy.

On one host, those agents can read each other’s worktrees, use the same credentials and kill each other’s processes. A prompt injection planted in an issue, a PR comment or a web page that one agent reads can reach everything that agent’s user account can reach. Separate session names are a cooperative convention, not a security boundary.

The following is an architecture we are evaluating, not one Astrohacker runs today. Nitro Sandboxes make it cheap enough to consider:

1. A trusted orchestrator on the parent instance. It claims work, starts sandboxes and holds the authority to create them. This is the component the rest of the design must trust, because on EKS the parent can mint credentials for any pod on the node.
2. One sandbox per agent session. A coding agent works inside its own VM with its own worktree. It cannot see another agent’s files or signal its processes.
3. Throwaway sandboxes for generated code and tests. Anything the agent wants to run goes into a short-lived sandbox, ideally with networking off.
4. Durable state outside the sandbox. Worktrees, transcripts and checkpoints live on EBS volumes (EKS supports them in sandboxed pods) or in S3. Since a Nitro Sandbox cannot pause and holds its memory while idle, terminate and restart stands in for sleep. That works for an agent that reloads its context from a pushed branch and an issue thread. It does not preserve a running process.
5. Per-role identity through EKS Pod Identity. Coders get credentials that can push branches. Reviewers can comment and record verdicts. Only the deploy agent can reach production. This needs separate GitHub identities or a GitHub App per role, which is exactly what our one-login setup lacks today.

Confidential mode suggests a further step. GitHub cannot tell our reviewer from our coder because they share a login. Suppose the key that signs reviewer verdicts were a KMS key whose policy requires an attested reviewer image: a specific PCR17 policy hash, signed by EKS. The parent could not obtain that key, and neither could a coding agent. A verdict signed with it would show that the published reviewer image produced it.

That proves which code produced the verdict. It does not prove the review was good. A careless model, a weak prompt or a missing test still passes through an attested image. Attestation can turn “the CLI says so” into “this measured program says so,” and a team would still have to decide what that program must check.

When to buy, and when Nitro Sandboxes are enough

A vendor sandbox is the better fit when:

• you have no AWS footprint, or do not want to run Kubernetes or instances for this;
• agents need pause and resume with memory and processes intact, or many idle sessions must cost little more than storage (E2B, Blaxel, or Daytona’s VM sandboxes document this);
• you need GPUs inside the sandbox (Modal, Daytona, or GKE Agent Sandbox with gVisor);
• you want a managed SDK, egress policy and credential brokering without building them yourself.

Nitro Sandboxes on infrastructure you already run are probably enough when:

• you already operate EKS, or ECS on Managed Instances, and your agents fit in fixed-size VMs;
• isolation between agents matters more than idle cost or fast resume;
• your agents can restart from durable state instead of pausing;
• you want attestation-gated keys, which almost no one else in this table documents;
• your region is covered. The EKS guide currently says US commercial regions.

Whichever you choose, ask the provider these questions before you commit:

1. What exactly survives a pause: memory, processes, open connections, IP address, or only files? How long does resume take, by your own measurement?
2. What does a paused or idle sandbox cost per hour, including storage and any minimum charge?
3. What is the longest a sandbox can live, and what happens to its state at that limit?
4. Can I deny all egress and allow specific domains? How is a domain matched, and do you document bypasses such as domain fronting?
5. Do secrets ever enter the sandbox? Can each sandbox get its own short-lived identity?
6. Who can read a sandbox’s memory and credentials: my other workloads, the host, your operators? Can you prove it with attestation?
7. Where does it run: your cloud, my account, or my hardware? Which regions?
8. Do you support GPUs, and do pause and snapshots still work with them?

AWS answered several of these on November 9, sometimes with “no.” The rest of the market answers different ones. Choose based on which answers matter to your agents.