AWS Nitro Sandboxes isola cada pod do EKS numa VM dedicada por hardware

O que mudou

A AWS lançou o AWS Nitro Sandboxes para o Amazon EKS, um RuntimeClass que faz cada pod rodar dentro da sua própria máquina virtual leve, isolada em hardware pelo mesmo Nitro System que já separa instâncias EC2 umas das outras. Até aqui, Kubernetes compartilha o kernel do host entre todos os containers do node: rápido e barato, mas uma falha de isolamento em um container pode vazar para os vizinhos. A solução de sempre era dedicar uma instância inteira por carga sensível, o que funciona, mas deixa capacidade ociosa e aumenta a fatura.

O recurso tem dois modos. O isolated mode protege o host e os pods vizinhos do que acontece dentro do container: cada sandbox roda em sua fatia de CPU e memória, aplicada em hardware pelo Nitro Hypervisor, que nem o host nem outros pods conseguem ler. O confidential mode vai além e trata até o operador da máquina como não confiável: o Nitro Security Module mede o que subiu dentro do sandbox e assina um documento de atestação que o workload apresenta ao AWS Key Management Service (KMS), que só libera segredos se a atestação bater com a imagem e a política Cedar configuradas.

Na prática, o opt-in é uma linha no pod spec: runtimeClassName: isolated-sandbox ou confidential-sandbox. Não muda imagem de container, pipeline de deploy ou Helm chart. kubectl exec, kubectl logs e kubectl port-forward continuam funcionando normalmente, e o AWS Nitro Sandboxes passa em todos os testes de conformidade do Kubernetes.

Onde está disponível

Segundo a AWS, o recurso está disponível hoje em todas as AWS Commercial Regions, em todas as famílias de instância habilitadas para Nitro (Intel, AMD e Graviton). Como sa-east-1 (São Paulo) é uma região comercial da AWS, o recurso está incluído nessa cobertura; a fonte não detalha, porém, nenhuma exceção ou atraso de rollout por região.

O requisito que muda o planejamento de cluster é a versão do Kubernetes: Nitro Sandboxes exige Kubernetes 1.36 ou mais recente. Quem está em versões anteriores do EKS precisa fazer o upgrade do control plane antes de cogitar o recurso, o que vale colocar no roadmap de manutenção já no próximo ciclo de versões suportadas.

No EKS Auto Mode, as RuntimeClasses isolated-sandbox e confidential-sandbox já vêm prontas em todo cluster, sem add-on para instalar. No EKS padrão, com node groups próprios ou Karpenter, o mesmo pod spec funciona desde que o node rode uma AMI habilitada para Nitro Sandboxes, documentada no guia de usuário da AWS.

Quanto custa

A fonte não traz uma tabela de preço específica para o Nitro Sandboxes. O texto do AWS Containers Blog não menciona uma cobrança adicional por sandbox: o mecanismo carve uma fatia de CPU e memória de uma instância EC2 já em execução (uma "Nitro Partition"), e a instância em si segue cobrada pelo modelo padrão de EC2/EKS, por hora e por família de instância.

Ou seja, quem já paga por instâncias Nitro-enabled (praticamente todo o parque atual em Intel, AMD e Graviton) não precisa somar uma linha de custo nova só para ligar o RuntimeClass, mas a economia real depende de quanto bin-packing o cluster ganha ao colocar vários pods isolados num node só em vez de dedicar uma máquina por carga. Vale tratar essa conta no FinOps do time antes de generalizar o uso, porque a fonte não quantifica esse ganho.

Como começar

O caminho mais curto é um cluster em EKS Auto Mode. Com eksctl:

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

Conferir se as RuntimeClasses já estão lá (nada para instalar):

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

O opt-in inteiro é uma linha no spec do pod:

apiVersion: v1
kind: Pod
metadata:
 name: hello-sandbox
spec:
 runtimeClassName: isolated-sandbox # <-- a única mudança
 containers:
 - name: hello
 image: public.ecr.aws/amazonlinux/amazonlinux:2023
 command: ["sh", "-c"]
 args:
 - sleep infinity

Rodando kubectl logs nesse pod, o product_name em /sys/class/dmi/id/product_name aparece como 8i.enclave (o sufixo .enclave confirma que o container subiu dentro de um Nitro Sandbox), e os discos aparecem como vda, vdb, vdc (virtio), em vez dos nvme0n1/nvme1n1 que um pod comum veria no mesmo node. Trocar isolated-sandbox por confidential-sandbox ativa o modo confidencial; acrescentar a anotação sandbox.amazonaws.com/network-isolated: "true" sobe a VM sem rede nenhuma além de loopback.

O exemplo mais completo da AWS, no repositório sample-eks-nitro-sandbox (pasta examples/getting-started/coding-agent/), roda um agente de IA que lê uma issue do GitHub, escreve um fix, roda os testes e abre um pull request inteiramente dentro do sandbox.

A segurança desse workload não depende de revisar o código do agente: ela está no ApplicationNetworkPolicy do EKS Auto Mode, que libera egress só para CoreDNS e para os hostnames HTTPS do Amazon Bedrock e do GitHub (uma NetworkPolicy padrão do Kubernetes não consegue filtrar por hostname). Essa política só é aplicada depois de setar enable-network-policy-controller: "true" no ConfigMap do amazon-vpc-cni em kube-system, um detalhe que quem administra VPC e CNI do cluster precisa conhecer antes de confiar no isolamento de rede do sandbox.

O que muda para quem já usa EKS

Para quem já opera clusters EKS em produção, o Nitro Sandboxes não troca peças do ambiente: Pod Identity, Amazon EBS, Amazon EFS, CloudWatch e VPC CNI continuam entregando credencial, storage, métrica e rede exatamente como antes. A diferença está na fronteira: o host não vê dentro da VM do pod, e a VM não vê o node nem os vizinhos, o que muda o cálculo de risco de rodar múltiplos tenants ou cargas não confiáveis no mesmo node sem dedicar instância por cliente.

Os recursos que ainda são compartilhados no node (banda de rede, I/O de disco, DNS, saída de log, entradas de conntrack) vêm protegidos por throttles configuráveis por padrão, segundo a AWS, para que um agente descontrolado ou um job de build pesado esbarre no próprio limite antes de afetar o pod ao lado. Isso evita o trabalho manual de tuning de ResourceQuota e LimitRange por node que hoje serve de paliativo contra ruído entre tenants.

O custo operacional novo é a dependência de uma política Cedar e, no modo confidencial, de atestação via KMS: quem for adotar o modo confidencial precisa desenhar essa política e o fluxo de chaves antes de levar cargas reguladas (HIPAA, PCI DSS, FedRAMP) para produção, porque é esse par (Cedar + atestação) que substitui o checklist de configuração que auditorias hoje aceitam.

Para cold start em sessões interativas, a AWS recomenda o projeto agent-sandbox do Kubernetes SIG, que mantém VMs pré-aquecidas prontas para uso em cerca de dois segundos; sem esse warm pool, o custo de boot de uma VM por pod é um trade-off a medir caso a caso antes de generalizar o padrão para workloads sensíveis a latência.

Fonte: AWS Containers Blog