kubernetessecurityPractitioner

AWS Nitro Sandboxes: Elevating Pod Security in EKS

5 min read AWS Containers BlogNov 9, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

In today's cloud-native environments, security is paramount. AWS Nitro Sandboxes address the critical need for workload isolation by leveraging hardware-enforced boundaries. This means that each pod operates within its own virtual machine, protecting both the host and neighboring pods from potential vulnerabilities and attacks originating from within a container.

The mechanics behind Nitro Sandboxes are impressive. They utilize the Nitro Hypervisor to carve out dedicated slices of CPU and memory for each pod, ensuring that no other pod or the EC2 host can access its memory or CPU state. This is a significant leap from traditional software-based isolation methods, as it relies on hardware capabilities to enforce security. You can easily enable this feature in your EKS cluster by specifying the runtime class in your pod configuration. For example, you can create a pod with the isolated sandbox by simply adding runtimeClassName: isolated-sandbox to your pod spec.

When deploying Nitro Sandboxes, ensure that your Kubernetes version is 1.36 or later. This is crucial for compatibility and to take full advantage of the security features provided. While the implementation is straightforward, always be aware of the performance implications of running multiple lightweight VMs on a single node, as resource contention can still occur if not managed properly.

Key takeaways

→Leverage AWS Nitro Sandboxes for hardware-enforced pod isolation.
→Utilize the Nitro Hypervisor to ensure dedicated CPU and memory slices for each pod.
→Specify `runtimeClassName: isolated-sandbox` in your pod configuration for enhanced security.
→Ensure your Kubernetes version is 1.36 or later to use Nitro Sandboxes effectively.

Why it matters

In production, the ability to isolate workloads at the hardware level significantly reduces the risk of lateral movement in the event of a breach, enhancing overall security posture.

Code examples

Bash

eksctl create cluster --name sandbox-demo --region us-west-2 --version 1.37 --enable-auto-mode

Bash

$ kubectl get runtimeclass
NAME                   HANDLER                AGE
confidential-sandbox   confidential-sandbox   5m
isolated-sandbox       isolated-sandbox       5m

YAML

1apiVersion: v1
2kind: Pod
3metadata:
4  name: hello-sandbox
5spec:
6  runtimeClassName: isolated-sandbox   # <-- the only change
7  containers:
8    - name: hello
9      image: public.ecr.aws/amazonlinux/amazonlinux:2023
10      command: ["sh", "-c"]
11      args:
12        - |
13          echo "/sys/class/dmi/id/product_name:  $(cat /sys/class/dmi/id/product_name )"
14          echo "disks:   $(ls /sys/block | tr '\n' ' ')"
15          sleep infinity

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

AWS Nitro Sandboxes: Elevating Pod Security in EKS

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Harnessing OpenShell on Kubernetes: A Practical Guide for Platform Engineers

OpenKruise Agents v0.6.0: Elevating Sandbox Security and Automation

Mastering Isolation and Security in Kubernetes: Scale with Confidence