Executive Summary
Nitro Sandboxes move the boundary. Every sandboxed pod on Amazon EKS now runs its own guest kernel inside a hardware-partitioned slice of an EC2 instance that is already running, and AWS says the result passes every Kubernetes conformance test. The mechanism is real. The opt-in is a single pod field, which is the interesting part, because it turns isolation from an infrastructure decision into per-workload configuration.
The finding most coverage will skip is that the same field cuts both ways. Anyone who can create a pod can select a RuntimeClass, and anyone who can create a pod can leave it off, so a mandatory isolation rule has to live in admission policy and nowhere else. What the sandbox does not separate is what tenants actually contend for. Network bandwidth, disk I/O, DNS and conntrack stay shared. Buy the boundary, then write the rule that requires it.
Amazon EKS will now boot a virtual machine for a single pod. AWS announced Nitro Sandboxes on 9 November, and the shape is the unusual part. The hypervisor does not spin up a new instance. It carves a hardware-isolated slice of CPU and memory out of an instance that is already running, which AWS calls a Nitro Partition, and the container runtime boots the pod kernel inside that slice. The pod gets an operating system no neighbor shares, and the node keeps packing many sandboxes onto one host because the boundary is enforced in silicon.
Adoption is one field. On EKS Auto Mode you set runtimeClassName to isolated-sandbox and nothing else moves. Same image, same entrypoint, same Pod Identity credentials, same volumes, same CNI. On standard EKS you build a sandbox-enabled AMI first, which is the honest cost of not using Auto Mode.
VM per pod is a decade old. The enforcement point is not.
Kata Containers has been running containers inside lightweight virtual machines for years, and gVisor takes a different route by intercepting syscalls in userspace. Firecracker, also AWS, has been the microVM under Lambda since 2018. So isolation is not the announcement. The claim that pods get strong security isolation for the first time is about this platform, not the industry.
What is new is where the wall sits. Earlier VM-per-pod designs boot a guest under a nested hypervisor or hand the workload to a separate microVM host. Nitro takes the slice from an instance that is already running and lets the EC2 control plane hand it to the pod runtime. That is why a node can be shared densely, and why the integration is a RuntimeClass rather than a runtime swap.
Passing Kubernetes conformance proves the API behaves. It does not prove the workload is safe. A pod that reads a secret it should not read, inside a perfect sandbox, is still a pod that read too many secrets. The boundary limits blast radius, and the Hugging Face breach was a case of nothing rejecting a privileged pod rather than a case of the wrong runtime.
Kubernetes pod isolation is now set by whoever writes the manifest
runtimeClassName is a normal pod field, and RuntimeClass objects are cluster scoped. Someone who holds pod-create permission can point a workload at isolated-sandbox. The same person can point it at the default runtime instead. That is a policy problem wearing a YAML costume.
If a tenant contract or an auditor requires hardware isolation, the control that enforces it is admission, whether that is Kyverno, OPA Gatekeeper or a ValidatingAdmissionPolicy. A tainted node pool documents where a pod runs. It says nothing about whether the pod asked for the boundary.
Memory is separated. I/O is throttled, not separated.
Read the shared-resource paragraph of the EKS user guide twice. Network bandwidth, disk I/O, DNS queries, log output and connection tracking all stay on the node, held back by throttles that are on by default and configurable. That is a real improvement over a noisy neighbor with no limits. It is not isolation, and a tenant that needs a hard throughput floor still needs dedicated capacity.
Confidential mode attacks a different threat, which is you. The Nitro Security Module measures what booted and signs an attestation document. Key Management Service releases a secret only when that document matches the expected image and a Cedar policy allows it, so a cluster administrator cannot read pod memory. That is the mode with a compliance story, and the policy file becomes the thing an auditor reads.
Three questions to run against your own cluster this week. Which workloads would fail an audit that demanded cryptographic proof of isolation rather than a signed checklist. Which ones would break if a sandbox added two seconds to start. And which admission rule stops a pod from choosing a weaker runtime than its data requires.
Related reading. The gVisor speedup turned out to live in the host kernel rather than in the sandbox code, and NVIDIA preview control plane handed every tenant admin tells the same story through credentials instead of kernels.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.