EKS Nitro Sandboxes 2026: Hardware-Isolation je Pod

TL;DR

Mit EKS Nitro Sandboxes läuft jeder Pod, der die RuntimeClass isolated-sandbox oder confidential-sandbox setzt, in einer eigenen hardwareisolierten MicroVM des Nitro-Hypervisors. AWS verlangt keinen Aufpreis, der Cluster braucht Kubernetes 1.36 oder neuer. Für Frankfurt widersprechen sich Ankündigung und Dokumentation noch, GPUs werden nicht unterstützt.

Was hat AWS am 9. November angekündigt?

AWS hat Nitro Sandboxes als leichtgewichtige VMs unter dem Nitro-Hypervisor eingeführt, nutzbar für EKS-Pods, ECS-Tasks und eigene VMs auf EC2. Jeder Pod bekommt einen eigenen Kernel und eine Hardware-Grenze statt des geteilten Node-Kernels. Laut Ankündigung entstehen keine Zusatzkosten.

Die EKS-Dokumentation beschreibt zwei Modi:

Modus	RuntimeClass	Vertrauen in den Node	Typischer Zweck
Isoliert	isolated-sandbox	Node vertrauenswürdig	Node und andere Pods vor kompromittiertem Container schützen
Vertraulich	confidential-sandbox	Node nicht vertrauenswürdig	Daten vor Node-Betreibern schützen, Freigabe von KMS-Schlüsseln per Attestierung

Im vertraulichen Modus sind exec und Prozesslisten gesperrt, jeder Pod trägt eine Cedar-Policy, und AWS KMS gibt Schlüssel nur frei, wenn die gemessenen PCR-Werte passen. Mit der Annotation sandbox.amazonaws.com/network-isolated startet ein Pod ganz ohne Netzwerkgerät, gedacht für generierten oder fremden Code.

Was bedeutet das für Teams in Deutschland?

Für deutsche Teams zählt zuerst die Region. Die Ankündigung nennt alle kommerziellen Regionen, das EKS User Guide spricht am 10. November 2026 nur von den kommerziellen US-Regionen. Bis AWS das klärt, sollten Sie Frankfurt (eu-central-1) selbst testen. Zur European Sovereign Cloud macht AWS keine Angabe.

Fachlich ist die Neuerung für drei Fälle interessant: mandantenfähige Plattformen, auf denen mehrere Kunden oder Fachbereiche einen Cluster teilen, CI-Runner mit fremdem Code und KI-Agenten, die selbst Code erzeugen und ausführen. Auf EKS ist diese Isolation jetzt per RuntimeClass verfügbar, ohne eigene Laufzeit zu betreiben. Welche Isolationsstufe Agenten-Plattformen brauchen, haben wir in Agenten-Runtime-Plattformen 2026 beschrieben.

Die Grenzen laut Considerations: keine GPU-Durchreichung, kein hostNetwork, keine User Namespaces, kein In-place-Resize, ein EBS-Volume nur für einen Pod. Pro Node darf die vCPU-Summe aller Sandboxes das 5-Fache der Node-vCPUs nicht übersteigen. Je Pod gelten standardmäßig 4096 ausgehende Verbindungen und 100 DNS-Anfragen pro Sekunde. Auf SMT-Instanzen steht Sandbox-Pods effektiv nur etwa die Hälfte der vCPUs zur Verfügung, Graviton ist nicht betroffen.

Wie schneiden AKS und GKE im Vergleich ab?

AKS und GKE bieten Pod-Sandboxing schon länger, technisch aber anders. AKS setzt auf Kata Containers mit Hyper-V, GKE auf gVisor oder MicroVMs. EKS verlangt mit Kubernetes 1.36 die höchste Mindestversion und bindet dafür die Attestierung direkt an AWS KMS. Für Wechsler zählt vor allem, ob GPU-Workloads isoliert werden müssen.

Merkmal	EKS Nitro Sandboxes	AKS Pod Sandboxing	GKE Sandbox
Technik	Firecracker-MicroVM auf Nitro	Kata Containers, Hyper-V	gVisor oder MicroVM (Kata)
RuntimeClass	isolated-sandbox	kata-vm-isolation	gvisor / microvm
Mindestversion	Kubernetes 1.36	Kubernetes 1.27	k. A.
GPU	nein	k. A.	nur gVisor, Teilmenge
Einschränkung	Instanztypen mit Nitro Enclaves	nur Azure Linux, kein Arm64	MicroVM nur GKE Standard

Quellen: AKS-Dokumentation, GKE-Dokumentation. Die übrigen Unterschiede der Anbieter zeigt das Profil von AWS EKS.

Was sollten Sie jetzt tun?

Prüfen Sie zuerst Version und Region, dann einen einzelnen Workload. Am einfachsten geht das mit EKS Auto Mode, das Sandbox-Nodes ohne eigenes AMI bereitstellt. Eigene Node Groups brauchen ein angepasstes AMI und aktivierte Nitro Enclaves im Launch Template.

1. Cluster-Version prüfen: Unter 1.36 ist zuerst ein Upgrade nötig, Fristen stehen in EKS Kubernetes 1.37.
2. In eu-central-1 einen Testpod starten:

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-test
spec:
  runtimeClassName: isolated-sandbox
  containers:
  - name: main
    image: public.ecr.aws/amazonlinux/amazonlinux:2023
    command: ["sleep", "3600"]
    resources:
      limits:
        cpu: "2"
        memory: 512Mi

3. Bleibt der Pod Pending, ist die Region oder der Instanztyp noch nicht freigegeben.
4. Memory-Requests mit Puffer planen, denn der Gast-Kernel belegt 1 bis 2 Prozent.

FAQ

Was kosten EKS Nitro Sandboxes?

AWS berechnet laut Ankündigung keinen Aufpreis. Sie zahlen weiter die EC2-Instanzen und die EKS-Cluster-Gebühr. Indirekt steigen die Kosten, weil Sandbox-Speicher fest reserviert ist und auf SMT-Instanzen nur etwa die Hälfte der vCPUs nutzbar ist.

Funktionieren Nitro Sandboxes in Frankfurt?

Das ist am 10. November 2026 unklar. Die Ankündigung nennt alle kommerziellen Regionen, die EKS-Dokumentation nur US-Regionen. Testen Sie eu-central-1 vor einer Planung selbst.

Nitro Sandboxes vs. gVisor: Was ist der Unterschied?

gVisor fängt Systemaufrufe im Userspace ab, Nitro Sandboxes starten eine echte MicroVM mit eigenem Kernel unter dem Nitro-Hypervisor. Nitro bietet zusätzlich Attestierung, unterstützt aber keine GPUs.

Lösen Nitro Sandboxes das CLOUD-Act-Thema?

Nein. Der vertrauliche Modus schützt Daten vor Node-Betreibern, AWS bleibt aber ein US-Konzern. Die rechtliche Einordnung ändert sich dadurch nicht.

Quellen

1. AWS What's New: Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 (09.11.2026) (abgerufen 10. November 2026)
2. Amazon EKS User Guide: Sandboxing on Amazon EKS with isolated and confidential pods (abgerufen 10. November 2026)
3. Amazon EKS User Guide: Run a pod in isolated mode (abgerufen 10. November 2026)
4. Amazon EKS User Guide: Sandboxing considerations (abgerufen 10. November 2026)
5. Amazon EC2 User Guide: Isolate workloads with AWS Nitro Sandboxes (abgerufen 10. November 2026)
6. Microsoft Learn: Pod sandboxing with AKS (abgerufen 10. November 2026)
7. Google Cloud: GKE Sandbox (abgerufen 10. November 2026)