Azure Container Apps Sandboxes: infraestrutura segura para cargas agentic
TL;DR: A Microsoft anunciou o preview público do Azure Container Apps Sandboxes: ambientes de computação efêmeros com isolamento por microVM, inicialização em milissegundos e suspensão/retomada com snapshots de memória e disco. Ideal para agentes de IA executarem código não confiável, CI/CD multi-tenant e plataformas SaaS. Faturamento por segundo, scale-to-zero e políticas de egress por sandbox. Empresas brasileiras podem reduzir custos e riscos operacionais ao substituir infraestrutura customizada por um primitivo gerenciado da Azure.
O que muda com o Azure Container Apps Sandboxes?
A Microsoft disponibilizou em preview público o Azure Container Apps Sandboxes — um novo tipo de recurso que entrega ambientes de computação rápidos, seguros e efêmeros com suporte nativo a suspend e resume. Essa é a mesma infraestrutura que alimenta produtos como Cloud sandboxes do GitHub Copilot, Foundry Hosted Agents e o Azure Container Apps Express. Agora, qualquer desenvolvedor ou ISV pode construir sobre essa base.
Do ponto de vista estratégico, o Sandboxes abre duas frentes: para platform developers e ISVs, oferece o mesmo tecido de computação isolada que sustenta dezenas de produtos Microsoft — os blocos para criar uma plataforma multi-tenant pronta para escala. Para agentes de IA, transforma-se em uma ferramenta auto-configurável: o agente pode criar um sandbox em milissegundos para executar código não confiável, compilar fontes, testar requisições HTTP contra uma aplicação real, lançar uma sessão de navegador ou qualquer workload que precise de infraestrutura rápida e escalável.
O que são Container Apps Sandboxes?
Container Apps Sandboxes são ambientes de computação isolados que inicializam em subsegundo, escalam para milhares de instâncias e não geram custo quando ociosos. Cada sandbox roda em sua própria microVM com isolamento de hardware — completamente separada do host, da plataforma e de qualquer outro sandbox. Você traz sua própria imagem OCI (Open Container Initiative) e a plataforma cuida do resto: provisionamento a partir de pools preaquecidos, isolamento multi-tenant forte e suspensão/retomada baseada em snapshots que preservam estado completo de memória e disco entre sessões.
Alguns exemplos de uso imediato:
- Sistemas próprios de build e teste — conecte um sandbox ao pipeline CI/CD para executar compilações sem sobrecarregar a máquina local.
- Agentes que executam qualquer coisa com segurança — o agente cria um sandbox, executa o trabalho e retorna o output sem precisar de privilégios no host do agente.
- Swarm de agentes — decomponha uma questão de pesquisa, dispare N workers em paralelo (cada um com sua imagem e política de egress) e sintetize o resultado.
Clientes em early access já colhem benefícios. A Sitecore usa Sandboxes para permitir que seus agentes de IA executem ações reais (código, workflows, sistemas corporativos) com isolamento multi-tenant e automação total. A Cognite (Atlas AI) integrou o protótipo em horas e agora cada agente ganha um workspace seguro com filesystem, terminal e execução de código sobre dados reais de clientes — algo que antes exigia dias de análise manual.
Modelo de recursos: Sandbox Groups e Sandboxes
O recurso ARM de topo é Microsoft.App/SandboxGroups. Um Sandbox Group é o limite de gerenciamento para um conjunto de sandboxes que compartilham configuração — equivalente ao Container Apps Environment, mas construído especificamente para sandboxes.
Ao criar um Sandbox Group, você define:
- Subscription, Resource Group e Region
- Defaults opcionais: CPU, memória, disco, número máximo de sandboxes e idle timeout padrão
- Networking: opção de deploy em uma VNet customizada com subnet dedicada
- Identity: identidade Entra (system-assigned ou user-assigned)
Sandboxes individuais são criadas dentro do grupo. Cada sandbox possui sua própria fonte (disk image ou snapshot), tier de recursos, política de ciclo de vida, política de egress, variáveis de ambiente, portas, volumes e conexões.
Ciclo de vida do sandbox
Os sandboxes seguem um ciclo de vida bem definido com os seguintes estados:
| Estado | Descrição |
|---|---|
| Creating | Provisionamento a partir de uma disk image ou snapshot |
| Running | Executando ativamente – sustentado por uma microVM |
| Idle | Suspenso pelo sistema após inatividade; pode auto-retomar na próxima requisição |
| Suspended | Estado completo (memória + disco) preservado como snapshot; sem custos de computação |
| Resuming | Restaurando a partir de estado suspenso ou idle – subsegundo para a maioria dos workloads |
| Stopped | Parada iniciada pelo usuário; pode ser retomado |
| Stopping | Desligamento gracioso em andamento |
| Deleting | Remoção em andamento |
O destaque aqui é a diferença entre Idle e Suspended. Quando um sandbox fica ocioso por um timeout configurado, o sistema pode automaticamente suspendê-lo e capturar um snapshot. Ao chegar uma nova requisição, o sandbox retoma de forma transparente. Isso dá scale-to-zero com computação stateful — algo que antes exigia engenharia customizada significativa.
Disk Images: traga seu próprio container
Sandboxes inicializam a partir de Disk Images — imagens OCI convertidas em um formato otimizado de filesystem raiz. Você aponta para qualquer imagem OCI (registry público ou privado) e a plataforma constrói uma disk image bootável.
Você pode começar com imagens públicas pré-construídas mantidas pela plataforma (ex.: Ubuntu base) ou trazer suas imagens privadas. Para registries privados, é possível autenticar com username/token ou usar uma user-assigned managed identity para o Azure Container Registry (ACR).
Snapshots: persistência de estado completo
Snapshots capturam o estado completo de um sandbox em execução — memória, disco e todos os processos. Ao retomar de um snapshot, cada processo, handle de arquivo aberto e estrutura de dados em memória é restaurado exatamente como estava.
Duas formas de criar snapshots: automático ao suspender ou manual sob demanda. Três usos principais:
- Checkpointing durante uma tarefa longa para que o agente retome exatamente de onde parou
- Clonagem de um ambiente já preparado (dependências instaladas, caches populados, serviços rodando)
- Distribuição de um estado "pronto para uso" que retoma em subsegundo em vez de cold boot
Snapshots são gratuitos durante o preview. Depois, serão armazenados como Azure Blob Storage a taxas padrão. Cada snapshot registra o sandbox de origem, alocação de recursos (CPU, memória, disco) e metadados do container.
Tiers de recursos
Cada sandbox recebe um tier que define CPU, memória e disco:
| Tier | CPU | Memória | Disco |
|---|---|---|---|
| XS | 0,25 vCPU | 0,5 GB | 5 GB |
| S | 0,5 vCPU | 1 GB | 10 GB |
| M (default) | 1 vCPU | 2 GB | 20 GB |
| L | 2 vCPU | 4 GB | 40 GB |
| XL | 4 vCPU | 8 GB | 80 GB |
Ao criar um sandbox a partir de um snapshot, o tier é herdado do snapshot e não pode ser alterado — garantindo que o ambiente restaurado tenha exatamente os recursos com que estava rodando.
Políticas de ciclo de vida: auto-suspend e auto-delete
Cada sandbox pode ser configurado com políticas que automatizam transições de estado e limpeza:
-
Auto-Suspend
- Idle timeout: tempo de inatividade antes da suspensão (1m, 2m, 5m, 10m, 30m, 60m)
- Modos de suspensão:
- Disk + Memory (padrão): snapshot completo com estado de memória – retoma exatamente onde parou
- Disk apenas: preserva só o disco; a VM reinicia do zero na retomada. Útil quando só é necessária persistência de arquivos
-
Auto-Delete
- Deleta sandboxes automaticamente após um número configurável de dias de inatividade
- Evita acúmulo de sandboxes abandonados que consomem armazenamento de snapshots
Essas políticas tornam os Sandboxes economicamente viáveis em escala. Uma plataforma com milhares de tenants pode configurar timeouts agressivos (ex.: 60 segundos) com modo Memory, e o sandbox de cada tenant desaparece da fatura quase imediatamente — mas retorna em subsegundo quando o usuário volta.
Política de egress de rede
Para cenários com código não confiável — agentes de IA executando scripts gerados por LLMs, SaaS multi-tenant com workloads submetidos por usuários — controlar o tráfego de saída é crítico. Sandboxes oferecem uma Network Egress Policy por sandbox:
- Ação padrão: Allow ou Deny todo tráfego de saída
- Host rules: regras por padrão de domínio (ex.: *.github.com → Allow)
- Custom CIDR rules: regras por faixa de IP (ex.: 10.0.0.0/8 → Deny)
- Skip egress proxy: opção de bypassar o proxy de egress quando o roteamento da VNet customizada já trata a política
Isso significa rodar o sandbox em postura deny-by-default e permitir apenas os endpoints específicos que ele precisa (seu API server, um registry de pacotes etc.) — sem configurar NSGs ou firewalls.
Volumes gerenciados: armazenamento persistente e compartilhado
Sandboxes suportam dois tipos de volumes montáveis, ambos gerenciados pela Microsoft:
| Tipo de Volume | Backend | Melhor para |
|---|---|---|
| Managed Azure Blob | Azure Blob Storage | Dados compartilhados entre sandboxes, upload/download de arquivos, artefatos persistentes |
| Managed Data Disk | Azure Disk Storage | Armazenamento de alta performance para bancos de dados, caches de build, grandes conjuntos de trabalho – exclusivo por sandbox |
Volumes Blob vêm com um explorador de arquivos integrado no portal (navegar, upload, download, criar pastas, drag-and-drop). Volumes Data Disk oferecem block storage dedicado com tamanhos configuráveis.
Secrets e Identity
Secrets: Sandbox Groups suportam chave-valor scoped ao grupo. Secrets podem ser usados em políticas de egress para modificar requisições com regras de transform ou header-injection, sem expor os secrets ao código dentro do sandbox.
Managed Identity: Sandbox Groups suportam identidades system-assigned e user-assigned, com gerenciamento completo de RBAC. Os sandboxes podem autenticar-se em serviços Azure (Key Vault, Storage, Cosmos DB etc.) sem gerenciar credenciais — o mesmo modelo de identidade usado em todo o ecossistema Azure.
Conectores MCP e Triggers
ACA Sandboxes agora suportam conectores gerenciados via Model Context Protocol (MCP), dando acesso a APIs externas — Microsoft 365, Salesforce, ServiceNow, GitHub e mais de 1.400 sistemas — sem gerenciar credenciais diretamente. Anexe um Connector Gateway ao sandbox group, e cada sandbox do grupo pode chamar APIs externas por uma interface MCP padronizada em runtime.
Combine conectores com triggers para construir automação orientada a eventos: roteie um e-mail do Outlook para um sandbox que o tria com um agente de IA, ou reaja a um upload de arquivo no SharePoint extraindo e processando o documento — tudo sem código glue. Triggers podem disparar um comando shell dentro do sandbox ou invocar um endpoint HTTP exposto pelo sandbox.
A integração usa o novo serviço Connector Namespace (az connector-namespace), o mesmo runtime dos conectores do Logic Apps e Power Platform, agora disponível como camada programável para sandboxes.
Experiência no portal
O Azure Container Apps Sandboxes está disponível no novo portal do Azure Container Apps (https://sandboxes.azure.com/), que oferece uma experiência rica, tipo IDE.
Criação de Sandbox: três caminhos:
- Standard Sandbox — controle total sobre source, recursos, ciclo de vida, rede e volumes
- GitHub Copilot Sandbox — pré-configurado com Copilot CLI, credenciais GitHub podem ser injetadas via Access Token antes da criação
- Claude Sandbox — Claude CLI pré-instalado, pronto para coding agentic
Uso com Coding Agents: instale o skill azure-sandbox uma vez e seu agente (Copilot CLI ou Claude Code) aprende os comandos naturalmente:
# GitHub Copilot CLI
/plugin marketplace add microsoft/azure-container-apps
/plugin install sandboxes@Azure-Container-Apps
# Claude Code
claude plugin add microsoft/azure-container-apps
O skill executa verificações de pré-requisitos silenciosamente (az --version, az account show, node --version, aca --version) e mapeia perguntas em linguagem natural para os comandos aca corretos.
Página de detalhes do Sandbox: uma vez rodando, oferece acesso imediato ao terminal, além de:
- Network Audit – log em tempo real de tráfego de egress (allow/deny)
- Monitor – gráficos ao vivo de CPU, memória, disco e rede
- Connectors – conexões anexadas com ação "Add"
- Volumes – volumes montados com ação "Add"
- Log Stream – logs contínuos do container
- Processes – lista de processos em execução
- Files – explorador de arquivos para navegar no filesystem
Ações na toolbar: Resume, Stop, e no menu (⁝) ações para gerenciar Egress Policy, ingress (Add port), tirar Snapshot, Commit (salvar estado de disco como nova imagem), definir Lifecycle Policy ou Delete.
Primeiros passos com CLI e Python SDK
Todas as operações de sandbox e sandbox-group usam o comando aca (não az containerapp sandbox). O az é usado apenas para az login, az account show e gerenciamento de resource group.
Instalação (CLI)
# Mac, Linux
curl -fsSL https://aka.ms/aca-cli-install | sh
# Windows
irm https://aka.ms/aca-cli-install-ps | iex
Execute aca --help para começar.
Instalação (Python SDK)
pip install azure-containerapps-sandbox
Mais detalhes, quick starts e exemplos em https://sandboxes.azure.com
Evolução a partir do Dynamic Sessions
Se você usou o Azure Container Apps Dynamic Sessions, os Sandboxes são a evolução natural. Tudo que Sessions fazia, Sandboxes faz — e significativamente mais:
| Capacidade | Dynamic Sessions | Sandboxes |
|---|---|---|
| Inicialização subsegundo | ✓ | ✓ |
| Isolamento forte | ✓ | ✓ |
| Imagens de container customizadas | ✓ | ✓ |
| Integração com VNet customizada | ✓ (Parcial) | ✓ |
| Suspend/Resume com snapshots (memória + disco) | - | ✓ |
| Políticas de ciclo de vida (auto-suspend, auto-delete) | - | ✓ |
| Política de egress por sandbox | - | ✓ |
| Volumes gerenciados persistentes (Blob, Data Disk) | - | ✓ |
| Managed Identity (system + user-assigned) | - | ✓ |
| Gerenciamento de secrets | - | ✓ |
| Tiers de recursos configuráveis | - | ✓ |
| Acesso direto ao sandbox no portal | - | ✓ |
A Microsoft continuará suportando Dynamic Sessions, mas todo novo investimento está em Sandboxes. Se você está construindo novos workloads em computação efêmera isolada, comece com Sandboxes.
Como tudo se encaixa
ACA Sandboxes é um primitivo de plataforma. É a fundação sobre a qual vários produtos Microsoft já são construídos — ACA Express, Cloud sandboxes do GitHub Copilot e Foundry Hosted Agents. Quando você constrói sobre Sandboxes, está usando a mesma infraestrutura que alimenta o portfólio da Microsoft.
Isso é a evolução do que foi compartilhado como Project Legion em 2024. Legion descrevia a infraestrutura interna; Sandboxes a expõe como um primitivo voltado ao cliente.
O que vem por aí
- Integrações mais profundas com Azure — conectividade de primeira classe com networking, identity, storage e serviços de IA
- SDK e CLI aprimorados – experiências programáticas mais ricas para gerenciar sandboxes em escala
- Mais serviços Microsoft construídos sobre Sandboxes – isso é só o começo
Comece hoje
- Portal: https://sandboxes.azure.com/
- Documentação: Azure Container Apps Sandboxes
- Preços: Azure Container Apps Pricing (faturamento por segundo de vCPU/memória, scale-to-zero, snapshots a taxas de Blob Storage)
Feedback pode ser enviado via Azure Container Apps GitHub (prefixar com [Sandbox] para issues específicas).
Perguntas Frequentes
-
Como as Sandboxes se diferenciam das Dynamic Sessions?
Sandboxes são a evolução das Dynamic Sessions — oferecem tudo que as Sessions já faziam, mais recursos como snapshots de memória+disco, políticas de ciclo de vida (auto-suspend e auto-delete), controle de egress por sandbox, volumes gerenciados (Blob e Data Disk), identidades gerenciadas e tiers de recursos configuráveis. A Microsoft continuará suportando Sessions, mas todo novo investimento será em Sandboxes. -
Quais os principais casos de uso para Sandboxes no Brasil?
Os cenários incluem: execução segura de código gerado por LLMs (agentes de IA), CI/CD efêmero com ambientes isolados por build, plataformas multi-tenant onde cada tenant recebe um sandbox com políticas de egress dedicadas, e agent swarms que paralelizam tarefas com snapshots para checkpointing. Empresas brasileiras de SaaS, fintechs e indústrias com workloads agentic se beneficiam diretamente. -
Como funciona o controle de tráfego de saída (egress) em um sandbox?
Cada sandbox possui uma política de egress independente: ação padrão (Allow ou Deny), regras de domínio (ex.: *.github.com → Allow), regras CIDR (ex.: 10.0.0.0/8 → Deny) e opção de bypass do proxy de egress ao usar VNet customizada. Permite postura deny-by-default sem necessidade de NSGs ou firewalls dedicados. -
É possível persistir dados entre sessões do sandbox?
Sim, através de snapshots que capturam estado completo (memória + disco) e de volumes gerenciados: Managed Azure Blob (compartilhado entre sandboxes) e Managed Data Disk (alto desempenho, exclusivo por sandbox). Snapshots podem ser automáticos (ao suspender) ou manuais, e são armazenados como Azure Blob Storage a taxas padrão após o preview. -
Como funciona a cobrança? Há custo quando o sandbox está suspenso?
O faturamento é por segundo de vCPU e memória, com scale-to-zero: quando um sandbox entra em estado Suspended (via auto-suspend), não há custo de computação — apenas armazenamento dos snapshots (cobrado como Azure Blob Storage). Isso permite economia drástica em ambientes multi-tenant com picos de uso.
Artigo originalmente publicado por (autor não identificado) em Azure Updates - Latest from Azure Charts.
