AWS Gives Every EKS Pod and ECS Task a Hardware VM of Its Own: Nitro Sandboxes Ship Free for Agent Code

Amazon Web Services has introduced Nitro Sandboxes, a new EC2 building block that wraps each container workload in its own hardware-isolated virtual machine. Announced November 9, the feature gives every Amazon EKS pod, ECS task or EC2-hosted container the security properties of the Nitro System - strong isolation, zero operator access to customer data, and attestation - while keeping the container experience developers already use. AWS named running LLM-generated code as a headline use case.

Architecturally, a Nitro Sandbox is a lightweight VM launched and controlled from the parent EC2 instance, running as a separate first-level guest with no nested hypervisor. The Nitro Hypervisor enforces the CPU and memory boundary in hardware, which AWS says keeps compute and memory at near-native EC2 performance. The design descends from Nitro Enclaves, AWS's existing confidential-computing primitive, but with three adjustments for container workloads: sandbox vCPUs can time-share cores with the parent instance, the parent can attach standard virtio network and block devices instead of only a vsock channel, and sandboxes can run through a standard virtual machine monitor such as Firecracker.

The agent-workload angle is deliberate. With coding agents and model-generated scripts increasingly run multi-tenant on shared hosts, a shared Linux kernel has become the weak point - one container's kernel vulnerability exposes every other container on the host, and cluster operators can reach all tasks running on it. AWS's answer is to make the default isolation unit a VM rather than a container. The company's AgentCore service already runs one microVM per agent task; Nitro Sandboxes extend that model to any EKS, ECS or EC2 workload a customer runs themselves.

Integration is deliberately shallow. In EKS and ECS, enabling sandboxes is described as a one-line change, with Pod Identity, VPC CNI, EBS, EFS, S3 and CloudWatch working as usual. On EC2, customers can bring their own AMI and VMM, with Amazon Linux and Firecracker supported natively. Cryptographic attestation can gate the release of secrets: a secret store verifies the sandbox's integrity measurements before handing over credentials, so neither the cluster administrator, the platform team, nor AWS can read pod or task memory.

Availability is broad. Nitro Sandboxes run on every EC2 instance type that supports Nitro Enclaves across general purpose, compute optimized, memory optimized, storage optimized and accelerated families, on Graviton, Intel and AMD processors, in all commercial regions - at no additional charge. Storage reaches sandboxes the same way it reaches instances: local instance store for scratch space, EBS for persistent volumes, and S3 or EFS over the network.

The timing is no accident. The current wave of agentic AI has put untrusted, machine-written code into production fleets at a scale hand-written software never reached, and cloud providers are racing to make VM-grade isolation cheap enough to apply per task rather than per tenant. With Nitro Sandboxes, AWS is betting that hardware isolation, not kernel hardening, becomes the default boundary for agent-generated code - and that making it free removes the last reason to run that code on a shared kernel.