AWS just removed the last good excuse not to isolate your Kubernetes workloads. Nitro Sandboxes, launched November 9, gives each opted-in EKS pod, ECS task, or EC2 workload its own lightweight VM — backed by the same Nitro Hypervisor that runs AWS itself — at no additional charge. Standard containers share a kernel; Nitro Sandboxes do not. That difference is the entire story.
What You’re Actually Getting
Standard Linux containers rely on namespaces and cgroups for isolation. These are lightweight and efficient, but they share the host kernel. One unpatched kernel CVE, one escape from a privileged container, and an attacker is on your node — with access to credentials, volumes, and the network paths of every neighboring tenant.
Nitro Sandboxes gives each opted-in pod its own Linux kernel, isolated by hardware. A kernel exploit in one sandbox cannot reach the host or any other pod. This isn’t a software shim intercepting syscalls — it’s the same hypervisor Amazon uses for EC2. The boundary is real.
Enabling it takes one field in the pod spec:
spec:
runtimeClassName: isolated-sandboxThat’s it on EKS Auto Mode. No runtime daemon to manage, no separate node pools to maintain, no complex admission webhooks. EKS Managed Node Groups require a custom Nitro Sandbox AMI, but Auto Mode handles that automatically.
Two Modes, One Decision
AWS ships two runtime classes. The choice comes down to whether you trust your own infrastructure operators.
isolated-sandbox gives the pod its own kernel. The host node is trusted. This covers the vast majority of use cases: multi-tenant apps, CI/CD pipelines, AI agent tool execution. Memory overhead is 256 MiB per sandbox pod — the scheduler accounts for this automatically.
confidential-sandbox goes further: the memory is encrypted, and the host node is treated as untrusted. Even AWS operators cannot read the contents of a confidential sandbox. Secrets are only released to workloads that pass cryptographic attestation via KMS. This is the mode for healthcare data, financial records, or anything where compliance requires proof that your cloud provider can’t see the plaintext. The overhead doubles to 512 MiB per pod, and you’ll need a Cedar policy and KMS attestation setup before it’s useful.
Who Should Enable This Now
Three categories of teams should flip this flag immediately.
AI agent platforms. Anthropic, OpenAI, and Cursor all support architectures where the model’s reasoning loop runs in their cloud while tool execution — file writes, shell commands, API calls — runs on your infrastructure. Every tool call is a code execution you didn’t write. Running those tool executions inside Nitro Sandboxes gives you hardware-enforced limits on what any single agent invocation can reach.
Multi-tenant SaaS. If your Kubernetes cluster runs workloads for multiple customers, a container escape from one customer’s pod previously meant you had an incident affecting every customer. Nitro Sandboxes doesn’t prevent every possible attack, but it removes the “escape to kernel, pivot to adjacent tenant” path entirely.
CI/CD pipelines. Build jobs frequently run docker build, execute untrusted test scripts, or spin up agent-driven automation with elevated privileges. Historically this required dedicated build node pools — entire EC2 instances sitting mostly idle to enforce tenant separation. With Nitro Sandboxes you get the same isolation guarantee while sharing hardware across build jobs.
The Density Math You Need to Know
The 256 MiB overhead per isolated pod is real and the scheduler accounts for it. On a node with 16 GiB of allocatable memory, you’re losing roughly 4 GiB to sandbox overhead before a single application byte runs — assuming 16 sandbox pods. Plan capacity accordingly and don’t just enable this on existing production clusters without modeling the impact first.
The hard ceiling: sandboxes per node cannot exceed 5x the node’s vCPU count. Memory typically becomes the binding constraint before that limit, but it’s worth knowing. AWS claims up to 896 lightweight VMs on a single EC2 instance for dense workloads.
What It Doesn’t Replace
Nitro Sandboxes is not AWS Lambda MicroVMs — that’s a separate service with a different operational model (AWS runs the fleet, you call an API). It’s also not available on EKS Fargate. And the 256 MiB overhead means it’s probably not the right tool for small, latency-sensitive pods where you’re already packing densely.
Users of Kata Containers or gVisor get roughly equivalent protection through different mechanisms, but both require significantly more operational work to maintain at scale. Nitro Sandboxes removes that overhead entirely for teams already on EKS.
The Bottom Line
The traditional argument against pod-level isolation was cost: either you pay for dedicated nodes, or you accept shared-kernel risk. AWS just made that trade-off obsolete. If you’re running any untrusted code, any multi-tenant workload, or any AI agent tool execution on EKS, there’s no longer a credible reason not to sandbox it. Add the runtimeClassName field, account for the memory overhead, and move on.
