AWS Nitro Sandboxes isola cargas de trabalho dentro da mesma instância EC2

A AWS atualizou o histórico de documentação do EC2 User Guide em 9 de novembro de 2026 com uma entrada nova: AWS Nitro Sandboxes. É pouca linha de changelog, mas o conceito que ela descreve mexe direto com quem decide como isolar clientes ou times diferentes dentro da mesma frota EC2, ECS ou EKS.

Em uma frase

Nitro Sandboxes são máquinas virtuais leves que rodam dentro de uma instância EC2 já em execução, isolando workloads que compartilham essa instância sem exigir hardware dedicado para cada um.

Como funciona

O ponto de partida é o Nitro System: a arquitetura em que rede, armazenamento e segurança são descarregados para placas dedicadas (as Nitro Cards), deixando o hipervisor enxuto e a CPU da instância quase inteira disponível para a carga do cliente. Um Nitro Sandbox é uma VM aninhada dentro dessa instância pai, com seu próprio kernel, isolada das demais sandboxes que rodam ao lado.

A documentação da fonte detalha dois pontos técnicos específicos. Primeiro, cada sandbox enxerga seu armazenamento como um dispositivo virtio-blk, não como o volume EBS cru: quem está dentro da sandbox não fala diretamente com o volume, fala com uma interface de bloco virtualizada. Segundo, a interface de rede (Elastic Network Adapter) e o próprio volume de EBS são proxyados pela instância pai: é o hardware Nitro da instância que intermedia o tráfego real, e a sandbox recebe uma visão virtualizada desses recursos.

Na prática, isso aproxima o modelo do que já existe com microVMs Firecracker (usadas internamente em Lambda e Fargate), só que agora exposto como primitiva de isolamento dentro do próprio EC2. A diferença para um container é de fundo: container isola por namespace e cgroup no mesmo kernel; sandbox isola com kernel próprio, fronteira de segurança mais parecida com a de uma VM completa.

Exemplo

O caso que mais aparece ao ler essa descrição é o de SaaS multi-tenant rodando em ECS com launch type EC2 ou em um node group do EKS: hoje, para garantir que o workload do cliente A não acesse memória, disco ou rede do cliente B no mesmo worker node, a saída comum é isolamento forte via gVisor ou Kata Containers, ou simplesmente separar node pools por tenant e pagar o preço de instâncias subutilizadas.

Num cenário típico de EKS multi-tenant, o caminho que eu seguiria ao testar essa primitiva seria empacotar o workload de cada tenant numa sandbox dentro do mesmo worker node, em vez de depender só do isolamento de namespace do pod. Isso reduziria o vetor de ataque de "vizinho barulhento" ou de fuga de container, sem exigir um node (ou instância) por cliente. A fonte não traz comandos de aws ec2 nem flags de API: o único apontamento é a página "Isolate workloads with AWS Nitro Sandboxes", que é onde o passo a passo de configuração deve estar documentado.

Vale registrar: até a publicação deste texto, o changelog não lista exemplo de CLI, SDK ou Console. Quem for validar a aplicação prática no ECS ou no EKS depende da página de uso linkada na própria entrada do histórico.

Limites e cotas

A entrada do Document History não traz número de cota: nem quantas sandboxes cabem por instância pai, nem limite de vCPU ou memória por sandbox, nem famílias de instância suportadas. Isso é esperado num anúncio de documentação recém-publicado, mas é uma lacuna real para quem planeja capacidade.

O raciocínio técnico que dá para adiantar, baseado em como o Nitro System aloca recursos: a capacidade total das sandboxes está limitada pelos recursos da instância pai (vCPU, memória, banda da ENA), do mesmo jeito que uma microVM Firecracker em Lambda é limitada pela instância que hospeda os workers. Antes de planejar capacidade em produção, confira a página oficial e o console de Service Quotas do EC2 na sua conta: se existir uma cota nova associada a sandboxes, ela aparece lá, e cotas de EC2 costumam ser ajustáveis via pedido de aumento no mesmo console.

Erros comuns

Três confusões prováveis para quem só leu a manchete:

• Tratar Nitro Sandbox como sinônimo de container mais seguro: a fronteira é outra (kernel próprio), e isso muda o modelo operacional, não é só um "container com mais política de segurança".
• Assumir que o dispositivo virtio-blk visto dentro da sandbox é o volume EBS cru: ele é uma interface de bloco proxyada pela instância pai, então operações como snapshot ou Multi-Attach do EBS continuam sendo mediadas pela instância, não acessadas diretamente de dentro da sandbox.
• Esperar que a performance de rede dentro da sandbox seja idêntica à da instância pai: como a ENA é proxyada, características de throughput e latência tendem a ter uma camada a mais no caminho, e isso precisa ser medido, não presumido.

Na documentação oficial

A entrada de 9 de novembro de 2026 no Document History do Amazon EC2 User Guide aponta para a página "Isolate workloads with AWS Nitro Sandboxes", dentro do próprio guia. É lá que deve estar o passo a passo de configuração, os parâmetros de API e, presumivelmente, os limites que ainda não apareceram no changelog. Para arquitetos avaliando essa primitiva em ambiente multi-tenant no EKS, ECS ou EC2, vale tratar este artigo como o ponto de partida conceitual e ir direto à página oficial antes de desenhar qualquer prova de conceito.

Fonte: Amazon EC2 — User Guide