AWS Nitro Sandboxes give each EKS pod or ECS task its own hardware-isolated microVM

AWS has launched Nitro Sandboxes, lightweight virtual machines managed by the Nitro hypervisor that give an EKS pod, an ECS task or a standalone workload its own hardware-isolated VM on a shared EC2 instance. AWS frames it directly for agents: run “LLM-generated code in an isolated environment of its own” while packing many agent workloads onto one instance.

They are available now on most Nitro-based EC2 instances, in all commercial Regions, at no additional charge.

How it works on EKS

In a normal cluster, pods on one node share a Linux kernel, so a container escape or kernel bug can reach a neighbour. The EKS guide describes the fix as opt-in per pod: set runtimeClassName to isolated-sandbox or confidential-sandbox. A shim on the node then starts a Firecracker microVM for the pod, and an agent inside it runs the containers. Pods without the setting keep the default runtime.

There are two modes:

• Isolated protects the node and other pods from a compromised workload. The node keeps full control, so exec, logs and stats still work, and IMDS and Pod Identity credentials are allowed by default.
• Confidential protects the workload from the node. The policy pins image digests, arguments, environment variables and mounts, and denies exec, stdin and process listing from the host.

AWS says Pod Identity, the VPC CNI, EBS, EFS and S3 storage, and CloudWatch keep working. Cryptographic attestation lets you release secrets only to sandboxes that have proven their integrity. On plain EC2 you can bring your own AMI, orchestration and virtual machine monitor, with Amazon Linux and Firecracker supported natively.

The caveat for untrusted code

For code that must not touch the network, a pod annotation, sandbox.amazonaws.com/network-isolated: "true", boots the sandbox with no network device at all: no DNS, no IMDS and no Pod Identity credentials. AWS’s own guide warns this “is not absolute isolation”, because the guest’s vsock channel can still reach guest-bound ports. HTTP and TCP probes and kubectl port-forward also stop working in that mode.

Why this matters

Until now, a per-agent microVM usually meant a separate service such as Render Sandboxes or Modal’s VM Sandboxes, billed on top. If your agents already run on EKS or ECS, Nitro Sandboxes add that boundary inside your own cluster at no extra charge. Start with isolated mode for agent code runners, read the vsock warning before you rely on the network-isolation annotation, and remember that isolated mode passes AWS credentials in by default, so scope the pod’s role tightly.