Eine Kubernetes Sandbox gibt jedem Pod einen eigenen Kernel, statt ihn mit allen Nachbarn auf dem Node zu teilen. AWS hat dafür am 9. November 2026 Nitro Sandboxes für EKS, ECS und EC2 angekündigt. Der Artikel ordnet ein, wann Sie diese Isolation brauchen, wie sie auf EKS funktioniert und welche Alternativen es gibt, falls Sie nicht auf AWS sind.
Was ist eine Kubernetes Sandbox und warum reichen Namespaces nicht?
Eine Kubernetes Sandbox ist eine zusätzliche Isolationsschicht unter dem Pod, meist eine MicroVM oder ein Kernel-Proxy, sodass ein Ausbruch aus dem Container nicht automatisch den Node erreicht. Gewöhnliche Container teilen sich den Kernel des Hosts. Das macht sie schnell, bedeutet aber auch: Eine Schwachstelle im Kernel oder in der Container-Runtime betrifft potenziell jeden Pod auf demselben Node.
Namespaces, RBAC und Network Policies ziehen logische Grenzen darüber, aber keine harten. Wie dünn solche Grenzen sein können, zeigte zuletzt der Namespace-Bypass in der EKS Network Policy. Für Mandanten, die sich vertrauen, ist das Alltag und ausreichend. Es wird kritisch, wenn Sie Code ausführen, den Sie nicht geschrieben haben: Kundencode in einer SaaS-Plattform, Build-Jobs fremder Teams oder von einem LLM generierte Skripte, die ein KI-Agent ausführt.
Die übliche Notlösung war bisher ein eigener Node pro sensibler Workload. Das funktioniert, ist aber teuer, weil der Großteil der Maschine ungenutzt bleibt. AWS beschreibt genau dieses Problem als Ausgangspunkt für die neue Funktion.
Wie funktionieren Nitro Sandboxes auf EKS?
Jeder Pod bekommt eine leichtgewichtige VM mit eigenem Betriebssystem, die der Nitro Hypervisor in Hardware vom Node und von den Nachbar-Pods trennt. Laut AWS-Containers-Blog schneidet der Hypervisor dafür eine isolierte Scheibe aus CPU und Speicher einer laufenden Instanz heraus. Der Container-Runtime startet die Container nicht auf dem Node-Kernel, sondern bootet darin eine VM.
Aktiviert wird das über eine Kubernetes-RuntimeClass, nicht über eine neue API. Auf EKS Auto Mode genügt laut AWS eine Zeile in der Pod-Spezifikation:
spec:
runtimeClassName: isolated-sandboxDie RuntimeClass trägt Node-Selector und Toleration mit, Auto Mode startet bei Bedarf einen passenden Node. Pod Identity, VPC CNI, EBS, EFS und CloudWatch laufen laut AWS unverändert weiter. Es gibt zwei Modi: isolated-sandbox liefert die VM-Grenze, confidential-sandbox ergänzt verschlüsselten Speicher und kryptografische Attestierung, sodass Geheimnisse nur an Sandboxes herausgegeben werden, die ihre Integrität nachgewiesen haben. Ein Annotation-Schalter startet die VM zusätzlich ohne Netzwerk außer Loopback, was für reine Rechenjobs mit fremdem Code sinnvoll ist.
Wer eigene Node-Gruppen oder Karpenter nutzt, braucht ein Sandbox-fähiges AMI, das AWS im User Guide beschreibt. Auto-Mode-Nodes lassen sich ansonsten über die NodeClass anpassen; ob und wie sich beides kombinieren lässt, steht in der AWS-Dokumentation zu Sandboxes.
Was kosten Nitro Sandboxes und was verlangen sie von Ihrem Cluster?
Die Sandboxes selbst kosten laut AWS nichts extra (Stand: November 2026, laut EKS-FAQ); Sie zahlen die EC2-Instanzen und den Cluster wie bisher. Das eigentliche Gewicht liegt woanders: Jede VM braucht eigenen Speicher und eigene CPU-Anteile, und wie hoch dieser Overhead pro Pod ausfällt, hängt von der Workload ab. Messen Sie ihn mit Ihren Images, bevor Sie Node-Größen und Requests festlegen.
Drei Rahmenbedingungen sollten Sie vor dem Einsatz klären. Erstens die Region: AWS nennt die kommerziellen Regionen und Nitro-basierte Instanzfamilien auf Intel, AMD und Graviton. Wer in einer anderen Partition arbeitet, etwa in der AWS European Sovereign Cloud, muss die Verfügbarkeit gesondert bestätigen. Zweitens die Beobachtbarkeit: kubectl exec und kubectl logs laufen laut AWS weiter wie gewohnt, aber Werkzeuge, die auf dem Node in Container-Prozesse schauen, sehen nicht mehr hinein, denn die VM ist von außen bewusst undurchsichtig. Das betrifft Runtime-Security-Agenten, die per eBPF am Host arbeiten. Drittens die Eignung: Nicht jede Workload braucht das. Eine eigene Sandbox pro Pod für interne, vertrauenswürdige Services ist Aufwand ohne Gewinn.
Welche Alternativen gibt es zu Nitro Sandboxes?
Wer nicht auf EKS Auto Mode setzt oder nicht auf AWS läuft, hat mit Kata Containers, gVisor und Firecracker etablierte Wege zur Pod-Isolation, die ebenfalls über RuntimeClasses eingebunden werden. Kata Containers startet Pods in leichtgewichtigen VMs, gVisor fängt Systemaufrufe in einem Kernel im Userspace ab. Beide müssen Sie selbst betreiben: Node-Images, Hypervisor-Unterstützung und Updates liegen bei Ihnen. Der Vorteil von Nitro Sandboxes ist, dass AWS diesen Teil auf Auto Mode übernimmt.
Außerhalb von Kubernetes kommt AWS Lambda MicroVMs in Frage, am 22. Juni 2026 angekündigt, für isolierte, zustandsbehaftete Umgebungen pro Nutzer mit Firecracker darunter. Das passt, wenn Ihre Anwendung ohnehin Sessions pro Endnutzer verwaltet und keinen Cluster betreiben soll. Für bestehende Kubernetes-Plattformen mit eigenem Scheduling und vorhandenen Manifesten ist die RuntimeClass der kleinere Schritt.
Ein Entscheidungsraster hilft: Brauchen Sie Isolation zwischen Mandanten oder gegenüber fremdem Code, und läuft der Cluster auf EKS Auto Mode, ist Nitro Sandboxes der kürzeste Weg. Läuft er auf eigenen Nodes, vergleichen Sie den Aufwand für das eigene AMI mit dem Betrieb von Kata oder gVisor. Und wenn es nur darum geht, Teams voneinander zu trennen, die einander vertrauen, genügen Namespaces mit sauberen Network Policies weiterhin.
So prüfen Sie heute, ob Sie eine Sandbox brauchen
Listen Sie die Workloads in Ihren Clustern, die Code ausführen, den Sie nicht selbst geprüft haben: Kunden-Plugins, CI-Jobs aus Fremd-Repositories, Agenten mit Code-Ausführung. Prüfen Sie für jede, ob sie heute auf Nodes mit anderen Workloads läuft und welche Service-Account-Rechte der Pod hat. Nehmen Sie eine dieser Workloads in einen Testcluster auf EKS Auto Mode, setzen Sie runtimeClassName: isolated-sandbox und vergleichen Sie Startzeit und Speicherbedarf mit dem normalen Pod. Dieser Vergleich liefert Ihnen die Zahlen, die für die Entscheidung fehlen.
Häufige Fragen
Brauche ich für Nitro Sandboxes EKS Auto Mode?
Nein, aber Auto Mode ist der einfachste Weg. Dort liefert jeder Cluster die Runtime-Klassen mit, und Auto Mode startet passende Nodes bei Bedarf. Bei eigenen Node-Gruppen oder Karpenter funktionieren dieselben Pod-Spezifikationen, sobald die Nodes ein Sandbox-fähiges AMI nutzen, das Sie nach AWS-Anleitung selbst bauen.
Kosten Nitro Sandboxes extra?
Laut AWS fallen für Nitro Sandboxes keine zusätzlichen Gebühren an (Stand: November 2026). Sie zahlen weiterhin die zugrunde liegenden EC2-Instanzen und den EKS-Cluster. Wie viel Speicher und CPU die VM pro Pod zusätzlich bindet, nennt AWS in den gesichteten Quellen nicht; das müssen Sie mit Ihrer Workload messen.
Was ist der Unterschied zwischen isolated und confidential Mode?
Der isolated-Modus liefert die Hardware-Grenze einer eigenen VM pro Pod. Der confidential-Modus, den Sie optional aktivieren, ergänzt laut AWS verschlüsselten Speicher und kryptografische Attestierung, damit Sie vor der Übergabe sensibler Daten prüfen können, was tatsächlich läuft. Er behandelt den Node als nicht vertrauenswürdig.
