AWS Nitro Sandboxes isola pods, tasks e VMs em hardware no EKS, ECS e EC2

O que mudou

A AWS anunciou em 9 de novembro de 2026 os AWS Nitro Sandboxes, VMs leves gerenciadas pelo Nitro Hypervisor que agora podem envolver um pod do Amazon EKS, uma task do Amazon ECS ou uma VM independente no EC2, incluindo agentes de IA rodando dentro dela. Cada workload passa a ter a mesma fronteira de isolamento de uma instância Nitro inteira, mas compartilhando os recursos de uma única instância EC2.

Isso ataca um problema concreto de quem desenha ambiente multi-tenant ou roda código não confiável: até aqui, isolar um pod ou uma task no nível de hardware normalmente significava dedicar uma instância inteira a ele, ou aceitar o isolamento mais fraco de namespaces e cgroups do kernel compartilhado. Com Nitro Sandboxes, o isolamento de hardware vira uma opção por pod ou por task, dentro da mesma instância.

O anúncio é explícito sobre o caso de uso que motivou o recurso: executar com segurança código gerado por LLM, rodando múltiplos workloads agênticos na mesma instância EC2 sem que um comprometa o outro. A AWS também incluiu atestação criptográfica: segredos só são liberados para um Nitro Sandbox depois que ele prova sua integridade, o que atende diretamente workloads regulados que precisam demonstrar isolamento auditável.

Onde está disponível

Segundo o What's New, o recurso está disponível hoje na maioria das instâncias EC2 baseadas em Nitro, em todas as regiões comerciais do mundo. Isso inclui a região América do Sul (São Paulo), sa-east-1, já que ela é uma região comercial padrão da AWS. A fonte não lista exceções de instância por região, então vale checar a documentação do EC2 User Guide antes de assumir suporte num tipo específico que você já usa em produção.

Para quem opera no Brasil, isso remove um obstáculo comum: recursos de segurança novos costumam levar meses para chegar a sa-east-1. Aqui o lançamento já nasce global.

Quanto custa

A AWS diz que Nitro Sandboxes está disponível sem custo adicional. Você continua pagando normalmente pela instância EC2 subjacente (sob demanda, Reservada, Savings Plans ou Spot, conforme seu modelo de compra atual); o isolamento extra por pod ou task não soma uma linha nova na fatura.

Na prática, isso muda o cálculo de custo de isolamento: antes, isolar workloads sensíveis em instâncias dedicadas significava pagar por capacidade ociosa. Agora dá para consolidar múltiplos workloads não confiáveis numa instância maior e compartilhada, mantendo o isolamento de hardware sem pagar o prêmio de instâncias subutilizadas.

Como começar

O caminho muda conforme o nível de controle que você quer:

• Em EKS ou ECS: a AWS descreve a ativação como uma mudança de uma linha na especificação do pod ou da task. O restante do ambiente continua nativo: Pod Identity, VPC CNI, armazenamento em EBS, EFS e S3, e CloudWatch funcionam sem adaptação. Os guias oficiais são o EKS User Guide e o ECS User Guide.
• Direto no EC2: para quem quer controle total sobre AMI, orquestração e hypervisor de máquina virtual (VMM), a documentação de Nitro Sandboxes no EC2 User Guide traz os detalhes de implementação. Amazon Linux e Firecracker já são suportados nativamente; patches para outras opções de VMM já estão disponíveis.

A fonte não traz comando de CLI nem nome exato do campo de configuração do pod ou da task, então o passo concreto é consultar o guia do serviço que você usa antes de alterar manifesto em produção.

O que muda para quem já usa

Para quem já desenha ambiente EKS ou ECS multi-tenant, o trade-off histórico era escolher entre isolamento forte (instância dedicada por tenant, cara e com overhead operacional) e isolamento fraco (namespace compartilhado, barato mas vulnerável a escape de container). Nitro Sandboxes tira essa escolha binária: o isolamento de hardware vira um atributo configurável por pod ou task, não uma decisão de topologia de cluster inteiro.

Isso toca direto o pilar de segurança do Well-Architected Framework: times que hoje justificam clusters separados ou node pools dedicados por motivo de compliance ganham uma alternativa que reduz a superfície de nós a gerenciar sem abrir mão da fronteira de isolamento exigida por auditoria. E como a integração com VPC CNI continua nativa, a topologia de rede e as políticas de segurança de grupo que o arquiteto já desenhou não precisam ser refeitas para acomodar o sandbox.

Fica em aberto, pela própria fonte, o desempenho relativo por tipo de instância e o comportamento sob carga em cenários de bin packing agressivo, algo que só a documentação completa do EC2 User Guide, e não o anúncio, deve detalhar.

Fonte: AWS What's New