Para isolar na AWS o código que gera seu agente de IA, agora você pode executar cada pod de EKS, tarefa de ECS ou VM em sua própria máquina virtual leve do Nitro Hypervisor. AWS as chama de Nitro Sandboxes, anunciou em 9 de novembro de 2026 e não cobra nada adicional por elas além das instâncias que você já paga.
Nota sobre regiões (na data de publicação desta nota, 10 de novembro de 2026): o anúncio diz que Nitro Sandboxes está disponível em todas as regiões comerciais da AWS, mas o guia do usuário de EKS indica que pods isolados e confidenciais estão disponíveis „nas regiões comerciais da AWS nos Estados Unidos‟. Se você usa EKS em São Paulo, México ou Madrid, revise o guia de EKS antes de planejar em torno dessa funcionalidade.
AWS é explícita sobre o objetivo: junto a cargas multi-tenant e reguladas, menciona agentes de IA que executam código gerado por um LLM. É o problema com o qual mais cedo ou mais tarde se depara qualquer equipe que conecta um agente a um pipeline de CI, a um bot de code review ou a um fluxo de „conserta este issue‟: o agente produz código, algo tem que executá-lo, e o kernel compartilhado de um contêiner não é uma fronteira em que você queira apostar. Se seu agente roda em sua própria máquina, o caminho é outro: explicamos em Como usar Dev Containers com agentes de IA no VS Code.
O que é um sandbox para agentes de IA em AWS Nitro?
Um Nitro Sandbox é uma VM filha leve, virtualizada por hardware, que roda junto a sua carga de trabalho em uma instância EC2. A instância pai cede vCPU e memória; Nitro isola o sandbox da instância pai, dos demais sandboxes, dos operadores da AWS e, em modo confidencial, até mesmo de seus próprios operadores.
A diferença prática em relação a um contêiner normal: cada sandbox tem seu próprio kernel. Se alguém escapa de um contêiner em um pod, cai dentro de uma VM, não no nó.
Como se diferencia de um contêiner, do Firecracker e do Nitro Enclaves?
Vale a pena situá-lo em relação a três coisas que você provavelmente já conhece:
- Um contêiner (runc): compartilha o kernel do host. Nitro Sandboxes coloca uma fronteira de virtualização por hardware ao redor de cada pod.
- Firecracker: é o VMM (virtual machine monitor) que AWS recomenda para gerenciar Nitro Sandboxes em EC2. Nitro Sandboxes não substitui o Firecracker: em EC2 você executa o Firecracker e Nitro fornece o isolamento e a attestation por baixo. QEMU e outros VMM precisam de compatibilidade adicional antes de poder usar attestation ou modo confidencial.
- Nitro Enclaves: mesmos alicerces, outro escopo. Um enclave se conecta com sua instância pai apenas por um canal vsock e serve para tarefas pequenas e delimitadas. Nitro Sandboxes adiciona dispositivos virtuais de rede e bloco, então pode executar cargas normais do tamanho de um contêiner.
Modo isolado ou confidencial?
Há dois modos. São escolhidos ao criar o sandbox e não mudam enquanto está em execução:
- Modo confidencial (o padrão em EC2): a memória do sandbox sai da instância pai, que não pode mais lê-la, e o sandbox inclui um Nitro Security Module para attestation. Um verificador externo, normalmente AWS KMS mediante uma condição na política da chave, entrega os segredos apenas quando as medições coincidem.
- Modo direto (opcional): a instância pai compartilha a memória do sandbox, o rendimento de I/O é maior e não há attestation. AWS recomenda usá-lo apenas quando a mesma parte confiável opera a instância pai e o sandbox.
Em EKS isso se traduz em duas classes de runtime: isolated-sandbox (o nó pai é de confiança) e confidential-sandbox (o nó pai não é de confiança).
Um aviso da documentação de EKS que vale repetir: sem uma política de chave KMS que verifique os valores PCR, a medição de attestation é registrada mas nunca é verificada. Se você escolher modo confidencial, configure condições kms:RecipientAttestation:PCR<PCR_ID> em cada chave KMS que proteja esses dados; caso contrário, a garantia fica incompleta.
Como ativar no Amazon EKS?
Em EKS Auto Mode é literalmente uma linha na spec do pod. Com seus próprios node groups, primeiro você precisa de uma AMI personalizada.
EKS Auto Mode: a rota que AWS recomenda
Auto Mode inclui suporte para Nitro Sandboxes sem configuração adicional: você não tem que construir nenhuma AMI. O único requisito é a versão do cluster. Nitro Sandboxes precisa de Kubernetes 1.36 ou superior, e eksctl usa por padrão uma versão mais antiga, então passe --version explicitamente:
eksctl create cluster --name sandbox-demo --region us-west-2 --version 1.37 --enable-auto-mode
Depois, defina runtimeClassName no pod:
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
runtimeClassName: isolated-sandbox
containers:
- name: main
image: public.ecr.aws/amazonlinux/amazonlinux:2023
command: ["sleep", "3600"]
resources:
limits:
cpu: "1"
memory: 512Mi
kubectl apply -f manifest.yaml
kubectl get pod my-app
Pods sem runtimeClassName continuam usando o runtime de contêineres padrão, então você pode colocar em sandbox apenas as cargas que executam código do agente e deixar tudo mais como está.
Em Deployments, Jobs, CronJobs e outros controladores, runtimeClassName e todas as anotações sandbox.amazonaws.com/ vão no template do pod (spec.template.spec e spec.template.metadata.annotations). AWS avisa que uma anotação nos metadados do próprio controlador é aceita e depois ignorada sem aviso: um erro fácil de passar despercebido em uma revisão.
E se você usar node groups próprios?
Fora de Auto Mode você precisa:
- Construir uma AMI personalizada que inclua o runtime de Nitro Sandbox (AWS documenta o processo em sua página „Create and update a Nitro Sandbox AMI‟).
- Usar um tipo de instância compatível.
- Habilitar Nitro Enclaves no template de lançamento do node group:
EnclaveOptions.Enabled=true. - Juntar os nós ao cluster e definir
runtimeClassNameno pod.
O passo 3 é aquele que as pessoas pulam. A documentação é direta: escolher um tipo de instância compatível com Nitro Enclaves não é suficiente; sem Nitro Enclaves habilitado, o nó nunca anuncia capacidade para sandboxes.
É possível deixar o sandbox sem rede?
Sim. Uma única anotação inicia o sandbox sem nenhum dispositivo de rede:
metadata:
annotations:
sandbox.amazonaws.com/network-isolated: "true"
A contrapartida: kubectl port-forward deixa de funcionar e as sondas HTTP ou TCP do kubelet não podem ter sucesso, então mude para exec probes. Para um agente que só precisa rodar testes sobre código que já está dentro do pod, é a configuração mais limpa disponível.
Há um exemplo pronto com um agente de código?
Sim. AWS publica um conjunto de blueprints executáveis em aws-samples/sample-eks-nitro-sandbox, com licença MIT-0. O mais relevante para este público executa Claude Code dentro de um sandbox que lê um issue do GitHub, o corrige e abre um pull request, usando modelos Claude através do Amazon Bedrock. Inclui um egress-policy.yaml junto ao manifesto do job, e faz parte do blueprint „Hello sandbox‟, que por si só já é suficiente para ver a fronteira de isolamento.
O que você precisa, segundo a página do blueprint: uma conta da AWS com AWS CLI configurado, eksctl, kubectl, Docker, Git (com user.name e user.email definidos), GitHub CLI com sessão iniciada e acesso a um modelo Claude no Bedrock em sua região. Os manifestos usam us-west-2 por padrão; para outra região, mude-a em fix-issue.yaml e em egress-policy.yaml.
O resto do catálogo é um bom mapa de onde AWS espera que isso seja usado: warm pools de sandboxes pré-iniciados, runners de GitHub Actions e GitLab CI, builds do Docker, políticas de rede de saída, limites de DNS e conexões por sandbox, sandboxes autoalojados para os managed agents de Claude e OpenAI, e blueprints confidenciais onde KMS entrega chaves apenas a sandboxes com attestation válida.
Funciona com ECS ou diretamente em EC2?
ECS: sim, como „isolated and confidential tasks‟, mas apenas em Amazon ECS Managed Instances. Cada tarefa roda em sua própria VM leve, e AWS a apresenta como um isolamento semelhante ao do Fargate, mantendo a escolha do tipo de instância, o bin-packing de várias tarefas por instância e as Capacity Reservations. No momento de publicar esta nota, a página de ECS não mostra a sintaxe da task definition; revise o ECS Developer Guide antes de ativá-lo.
EC2 diretamente: para ter controle total, você lança uma instância com enclaves habilitados e gerencia o sandbox com Firecracker. Segundo o guia do usuário de EC2:
aws ec2 run-instances \
--image-id ami-id \
--instance-type instance-type \
--enclave-options Enabled=true
{
"boot-source": { "kernel_image_path": "sandbox-image" },
"machine-config": { "vcpu_count": 2, "mem_size_mib": 2048 },
"drives": [{
"drive_id": "rootfs", "path_on_host": "rootfs.ext4",
"is_root_device": true, "is_read_only": false
}],
"network-interfaces": [{ "iface_id": "eth0", "host_dev_name": "tap0" }],
"enclave": {}
}
firecracker --config-file sandbox.json
Um objeto "enclave": {} vazio seleciona modo confidencial; "enclave": { "direct_mode": true } seleciona modo direto. Nesta rota você se torna responsável por tudo que EKS e ECS resolvem para você: imagens guest, backends de dispositivos, contabilidade de recursos, limpeza de memória, desligamento e relay de attestation.
Que limites tem?
- Tipos de instância: Nitro Sandboxes roda apenas em tipos de instância compatíveis com Nitro Enclaves. A maioria das famílias atuais M, C, R, X, D e I se qualificam, com exceções por tamanho (frequentemente
.largee.metal) que aparecem no guia do usuário de EC2. Revise o tamanho exato, não apenas a família. - Sem GPU passthrough para o sandbox, no momento de publicar esta nota.
- Orçamento de vCPU: o total de vCPU de todos os sandboxes de uma instância não pode exceder 5 vezes as vCPU da instância. Em uma instância de 4 vCPU são 20 vCPU de sandbox, por exemplo 20 sandboxes de 1 vCPU.
- Memória não é sobreasignada: a instância pai cede a quantidade completa ao iniciar o sandbox e só a recupera ao terminá-lo. Nem vCPU nem memória podem ser alteradas enquanto o sandbox está em execução.
- Em EKS, isolamento não é reserva de rendimento: a documentação de EKS diz que vCPU são compartilhadas no tempo entre os sandboxes de um nó e que a alocação total pode sobreassinalar o nó.
- Recursos de rede compartilhados: um único sandbox pode esgotar os orçamentos de conntrack e DNS da instância pai. Limite cada sandbox; os blueprints incluem um exemplo.
- Nunca monte o mesmo volume EBS em dois sandboxes ao mesmo tempo: corrompe o sistema de arquivos.
O anúncio diz que Pod Identity, VPC CNI, armazenamento EBS, EFS e S3 e CloudWatch funcionam sem modificações em EKS e ECS. AWS não publica cifras de overhead nem benchmarks além de descrever um rendimento próximo ao nativo de EC2: considere como uma afirmação da AWS até que você meça sua própria carga.
AWS Nitro Sandboxes, GKE Agent Sandbox ou E2B?
Se você está procurando uma alternativa ao E2B ou comparando opções de agent sandbox, a diferença fundamental é quem opera a infraestrutura e que tipo de fronteira de isolamento você obtém.
| AWS Nitro Sandboxes | GKE Agent Sandbox | E2B | |
|---|---|---|---|
| Isolamento | VM leve por pod ou tarefa sobre o Nitro Hypervisor, com kernel próprio | gVisor (kernel em espaço de usuário) | Serviço gerenciado de sandboxes |
| Onde roda | Seu EKS, ECS Managed Instances ou EC2 | Seu cluster de GKE | Infraestrutura de E2B (BYOC em Enterprise) |
| Custo adicional | Nenhum; você paga as instâncias | Nenhum; aplica-se o preço de GKE | Cobrado por segundo de sandbox em execução |
| Attestation | Sim, em modo confidencial | — | — |
| Versão de Kubernetes | 1.36+ | GKE 1.35.2-gke.1210000+ | Não se aplica |
Preços e condições segundo as páginas de cada provedor em 10 de novembro de 2026.
A divisão honesta: GKE Agent Sandbox e Nitro Sandboxes são „traga seu próprio cluster‟: o isolamento não custa extra e a operação é sua. E2B é a troca oposta: nada para operar, e você paga por segundo em troca. Entre os dois primeiros, a diferença arquitetônica é a fronteira em si: gVisor intercepta chamadas de sistema em um kernel em espaço de usuário; Nitro coloca uma VM virtualizada por hardware ao redor de cada pod.
AWS Nitro Sandboxes é grátis? A visão de Grego
A frase que vai se repetir é „sem custo adicional‟. É precisa e incompleta. Você continua pagando a capacidade de EC2 onde vivem os sandboxes, e a memória de cada sandbox é dedicada, não sobreasignada, então a densidade é limitada por RAM antes que por vCPU.
O que realmente muda é a forma da fatura. Um serviço gerenciado como E2B coloca preço no sandbox em si: em seu plano Pro, 150 dólares por mês mais o uso por segundo, e com as tarifas publicadas o sandbox padrão de 2 vCPU e 4 GiB sai por cerca de 0,17 dólares por hora. Com Nitro Sandboxes, executar código de agentes passa a ser mais uma carga sobre capacidade que você já planeja, reserva e negocia. Para uma equipe que já roda EKS com Savings Plans ou Capacity Reservations, essa é a oferta real: isolamento por hardware incluído em um compromisso que já existe, em vez de um novo provedor no orçamento.
Onde E2B continua ganhando é no tempo até o primeiro sandbox e na operação zero. Se você ainda não roda Kubernetes na AWS, levantar um cluster 1.36 com Auto Mode é muita plataforma só para executar código de um agente. Escolha segundo onde já vive seu cálculo.
E você? Onde sua equipe executa hoje o código que seus agentes de IA geram?
- Contêineres normais no meu próprio cluster
- Um serviço gerenciado (E2B ou outro)
- Dev Containers ou um sandbox local
- Prefiro outra opção (nos conte qual)
Comente abaixo ou, se este artigo chegou até você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Os agentes de código precisam de sandboxing — não apenas bons prompts