AWS Nitro Sandboxes: a hardware-isolated VM per EKS pod, ECS task or AI agent, at no extra charge

Amazon Web Services announced on 9 November 2026 that AWS Nitro Sandboxes are generally available: lightweight virtual machines, managed by the Nitro Hypervisor, that give a single Amazon EKS pod, Amazon ECS task or ordinary workload its own hardware-isolated VM on a shared EC2 instance. AWS pitches it first at one problem: running code that an AI agent wrote, and that nobody has reviewed, without giving it a shared kernel to attack.

Key points

• AWS Nitro Sandboxes are available today in all commercial regions, on most Nitro-based EC2 instances, at no additional charge, according to AWS's announcement.
• Each sandbox is a child VM with its own isolation boundary; on EKS and ECS, AWS says enabling it is a "one-line change" and each pod or task gets its own VM.
• The default confidential mode moves the sandbox's memory out of the parent instance's reach and supports cryptographic attestation; direct mode gives up attestation for I/O speed.
• Sandboxes run only on instance types that support AWS Nitro Enclaves, and GPU passthrough into a sandbox is currently unavailable, per the EC2 documentation.
• The total vCPUs given to sandboxes on one instance can't exceed five times that instance's vCPU count, and sandbox memory is not overcommitted.

What happened

In its "What's New" post, AWS described Nitro Sandboxes as lightweight VMs that can host an EKS pod, an ECS task, or a lightweight VM, "including AI agents running inside them", each in its own hardware-isolated virtual machine on the AWS Nitro System. The stated use is to run untrusted, multi-tenant or regulated workloads inside the resources of one instance, instead of paying for a separate instance per workload.

AWS says the sandboxes run with near-native EC2 performance and inherit the isolation of the Nitro hypervisor. They can also be attested: a workload proves its integrity cryptographically, and secrets are released only to sandboxes whose measurements match what the owner expects. For EKS and ECS the announcement says Pod Identity, the VPC CNI, EBS, EFS, S3 and CloudWatch all work unchanged. For people who want full control, sandboxes can be launched directly on EC2 with your own AMI, orchestration and virtual machine monitor (VMM). Amazon Linux and Firecracker are supported natively, and AWS says patches for other options are available.

Background

Containers share the host's Linux kernel. That is efficient, but it means a kernel bug or a misconfiguration can turn a compromised container into a compromised node. The usual answers have been a separate VM per tenant (strong, but a separate instance per workload costs more), user-space kernels or Kata-style microVMs, or nested virtualization.

AI agents sharpened the question. An agent that writes and executes code on demand is, from a security point of view, a stream of untrusted programs. AWS's documentation lists "sandbox AI agents that generate and run untrusted code" as a main use case, giving each agent session a hardware-isolated boundary. Nitro Sandboxes build on AWS Nitro Enclaves, the existing isolated-VM feature, but add what the documentation calls mechanisms for the parent instance to implement virtual hardware such as network and block devices. That lets a sandbox use ordinary VPC networking and EBS storage, which a classic enclave (which talks to its parent over a single local vsock channel) does not.

How it works

Per the EC2 User Guide, a sandbox runs as a first-level, hardware-virtualized guest alongside the instance. The parent supplies vCPU, memory and I/O, while the Nitro System enforces the boundary and provides attestation. The parent instance, other sandboxes and AWS operators are all kept out; AWS says this lets you isolate a workload even from your own operators.

Every sandbox runs in one of two modes, chosen at creation and fixed while it runs:

• Confidential mode (the default). The Nitro System moves the sandbox's memory out of the parent so the parent cannot read it. The sandbox has a Nitro Security Module for attestation. A common pattern is to put a condition in an AWS KMS key policy so that KMS releases a secret only to a sandbox whose measurements match. The entropy device is not supported in this mode.
• Direct mode. The parent shares the sandbox's memory. There is no attestation and the parent can read the memory. AWS says the trust model equals a standard nested VM, offered for higher I/O throughput when the sandbox and parent belong to the same trusted party.

For a self-managed setup the documentation gives these steps: launch an instance type that supports Nitro Enclaves with the same option that enables them (--enclave-options Enabled=true), build a guest image that declares its needed capabilities, launch the sandbox with a VMM (AWS recommends Firecracker, configured with an "enclave": {} object), and verify the attestation before releasing secrets. Firecracker uses the Nitro Enclaves driver on the parent instead of KVM. Other VMMs such as QEMU need added Nitro Sandbox compatibility before attestation or confidential mode work.

Sandboxes get virtio block storage (local instance store or EBS, one sandbox per volume at a time), virtio-net networking with access to instance metadata, a vsock channel to the parent, and optional hot-plugged devices. Hot-unplug is not possible.

The numbers

AWS caps how densely you can pack sandboxes. The total vCPUs allocated across all sandboxes on an instance can't exceed five times the instance's vCPU count, and each sandbox's memory is dedicated rather than overcommitted, so memory can be the tighter limit. The documentation's own example is a 4-vCPU instance, which has a 20-vCPU budget:

1 vCPU each20

2 vCPUs each10

4 vCPUs each5

Maximum Nitro Sandboxes on a 4-vCPU instance, by vCPUs per sandbox (sandboxes)

	sandboxes
1 vCPU each	20
2 vCPUs each	10
4 vCPUs each	5

Source: AWS EC2 User Guide, Isolate workloads with AWS Nitro Sandboxes

Other limits from the same page: by default each vCPU takes a dedicated physical core from the Nitro Enclaves CPU pool and cores are allocated whole, though a cpu_overcommit setting lets vCPUs float over the parent's remaining CPUs. A sandbox's vCPU and memory can't be changed while it runs; you terminate and re-create it. Support covers instance families from the M5, C5 and R5 generations through the newer M8, C8 and R8 and Graviton M9g, C9g and R9g families, plus some storage-optimized and GPU families, but not every size: many families exclude their smallest and bare-metal sizes. Check the exact list for your instance type in the AWS documentation before planning a rollout.

What it means

For teams building agent platforms, the main effect is cost and simplicity. A VM boundary per agent session used to mean a VM per session, or running your own microVM fleet on metal. AWS now offers that boundary as a feature of regular instances, at no extra charge, and as an EKS or ECS setting. A per-pod hardware boundary in a multi-tenant cluster is also an obvious fit for regulated workloads and for running third-party models that must prove their integrity before receiving secrets.

It does not remove the operator's work. When you run your own orchestrator, AWS says you are the parent operator and responsible for building images with correct settings, treating all data from a sandbox as untrusted input, zeroing memory before contributing it, and relaying attestation traffic. The documentation also warns that the parent's network stack is shared: one sandbox can exhaust the connection-tracking table or the DNS resolver budget and deny network access to its neighbours, so you must cap or rate-limit these per sandbox. Isolation of compute and memory is not isolation of every shared resource.

AWS's own guidance is to use Nitro Enclaves for small, tightly scoped jobs, nested virtualization for workloads that must run their own hypervisor, and Lambda MicroVMs for people who want isolated tenants without managing servers or networking.

What we don't know yet

AWS has not published performance figures behind "near-native" in the pages we read, so that remains the company's claim. We did not find independent benchmarks or security reviews yet. Start-up latency per sandbox, the behaviour under heavy density, and when GPU passthrough will arrive (for agents that need a GPU) are not stated. The announcement says availability covers "most" Nitro-based instances, and the exact list should be checked.

What to watch next

Watch for independent testing of isolation and start-up time, support for GPU instances, and whether other VMMs gain attestation support. Also watch how agent platforms adopt it, and whether third-party sandbox vendors respond on price or features.

Sources

• AWS What's New: Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 (primary, 9 November 2026)
• Amazon EC2 User Guide: Isolate workloads with AWS Nitro Sandboxes