AWS Nitro Sandboxes brings hardware VM isolation to every EKS pod, ECS task and EC2 container

AWS introduced Nitro Sandboxes for EKS, ECS and EC2. Each pod, task or lightweight VM runs inside its own hardware-enforced isolation boundary while sharing an EC2 instance's resources. It extends the Nitro system's zero operator access and cryptographic attestation from full instances down to individual containers, at what AWS calls near-native performance.

Matt Wood, AWS's chief AI and technology officer, framed it around coding agents: "An AI coding agent needs room to work. It needs to install dependencies, run code, test an idea, and try again. Giving it those capabilities also means deciding what that code can reach if something goes wrong." Standard containers share an operating-system kernel, so a kernel vulnerability can break isolation. Nitro Sandboxes removes that shared-kernel risk.

The launch fits a crowded field of agent sandboxes. Projects such as Firecracker-based microVMs, gVisor and NVIDIA's new OpenShell sandbox target the same problem. AWS's advantage is offering isolation as a native Kubernetes and ECS primitive instead of a separate service, and pairing it with Bedrock AgentCore.

Sandboxing is necessary but not sufficient. The same week brought the Strands CVE, in which credentials leaked through a model-chosen proxy, an attack that hardware isolation would not stop. Pricing and real-world performance overhead are what to watch.