AWS Nitro Sandboxes leva isolamento de workloads por hardware aos pods do Amazon EKS

O problema que o recurso ataca é conhecido: containers Kubernetes compartilham o kernel do host, então uma falha em um pode comprometer os vizinhos. O remédio clássico é uma máquina dedicada por workload, o que sai caro porque a maior parte dela fica ociosa. Os Nitro Sandboxes trocam isso por uma VM leve por pod, apoiada no Nitro System. Cada pod ganha seu próprio kernel de guest, e o Nitro Hypervisor impõe em hardware a fatia de CPU e memória, de modo que nem o host EC2 nem os pods vizinhos enxergam a memória ou o estado de CPU do sandbox.

Na prática, o opt-in é uma linha na spec: runtimeClassName: isolated-sandbox. A RuntimeClass carrega node selector e toleration, e o EKS Auto Mode provisiona um node compatível sob demanda. Imagens, pipelines de deploy e Helm charts não mudam. Pod Identity, EBS, EFS, CloudWatch, VPC CNI, kubectl exec, logs e port-forward seguem iguais, e o recurso passa em todos os testes de conformidade do Kubernetes. Exige Kubernetes 1.36 ou superior. Em EKS padrão, com node groups próprios ou Karpenter, é preciso um AMI habilitado para sandbox, descrito no guia do usuário.

Há dois modos. O isolated protege o host e os vizinhos do que acontece dentro do container. O confidential trata até o operador da máquina como não confiável: o Nitro Security Module mede o que subiu no sandbox e assina um documento de attestation, e o AWS KMS só libera a decriptação se o documento atestar a imagem do sistema e a política Cedar configurada. Também existe a anotação sandbox.amazonaws.com/network-isolated, que deixa a VM sem rede além do loopback. Recursos ainda compartilhados no node (banda de rede, I/O de disco, DNS, logs, entradas de conntrack) vêm com throttles configuráveis ligados por padrão.

Em 10 de novembro de 2026, o CEVIU noticiou "AWS lança Nitro Sandboxes com isolamento por hardware para workloads no EKS, ECS e EC2", com visão ampla do lançamento em vários serviços. A matéria de agora aprofunda o recorte do EKS: o mecanismo por pod, o opt-in por RuntimeClass, os dois modos e o exemplo de um agente de código rodando isolado. Em 12 de junho de 2026, o CEVIU já havia publicado "Como a verificação formal torna o AWS Nitro o primeiro hipervisor de nuvem formalmente verificado", sobre o Nitro Isolation Engine, e em 24 de junho de 2026 "AWS Lambda lança MicroVMs para sandboxes isoladas". O isolamento por VM leve para código não confiável, portanto, já aparecia no Lambda e agora chega ao Kubernetes.

Para quem opera plataforma, a leitura é que o custo de isolar deixa de ser uma máquina por tenant ou por agente. Dá para empacotar vários pods isolados no mesmo node sem mexer em pipeline. Para quem roda agentes de IA, CI com privilégio elevado ou SaaS multi-tenant, o modo confidential pode virar evidência para auditoria. Vale medir overhead e cold start no seu caso antes de adotar em larga escala.