Olá pessoALL,

Você já se deparou com algo no Azure e pensou: "Espera, isso não é exatamente o que eu já faço hoje?" Pois é. Foi exatamente essa a minha reação quando estudei o Azure Sandbox pela primeira vez. Olhei a documentação, vi os componentes e pensei: "Isso é um Terraform com módulos pré-prontos dentro de uma subscription dedicada. Próximo!"

Gastei um tempo considerável lendo a documentação oficial, os artigos da comunidade e comparando com o que já faço no dia a dia antes de formar uma opinião mais honesta. E a conclusão? Não foi tão simples quanto eu imaginava.

Não é um case real de cliente. É uma análise de quem trabalha com infraestrutura Azure no dia a dia e quis entender: o Azure Sandbox tem um fit real? Ou é só mais uma forma de separar recursos que eu já consigo fazer com Infrastructure as Code e uma subscription segregada?

O Que É o Azure Sandbox, Afinal?

Primeiro, o básico. Muita gente confunde isso: o Azure Sandbox não é um serviço do Azure. Não é um produto novo, não tem SKU e não aparece no portal como um recurso que você cria com um clique.

O Azure Sandbox é um projeto open-source no GitHub, mantido pela Microsoft, que usa Terraform para provisionar um ambiente pré-configurado com componentes de infraestrutura comuns. Ele faz parte do Azure Architecture Center como um guia de referência.

Na prática, quando você faz o deploy do Sandbox, ele cria:

• Active Directory Domain Services (AD DS) em uma VM Windows Server
• Duas Virtual Networks (uma para serviços compartilhados, outra para aplicações) com peering entre elas
• Azure Bastion para acesso seguro sem IP público
• Azure Firewall com threat intelligence
• Jump boxes Windows e Linux (com Azure CLI, PowerShell, Terraform pré-instalados)
• Azure SQL Database e MySQL Flexible Server via Private Endpoints
• Azure Files para storage compartilhado
• Virtual WAN com VPN point-to-site
• Key Vault, Log Analytics e automação

Parece bastante coisa, né? E é! O ponto é que tudo isso vem pré-configurado com boas práticas de segurança: MFA, Conditional Access, least privilege via RBAC, Private Endpoints, Firewall rules, criptografia. Um ambiente pronto pra experimentar.

A própria Microsoft alerta na documentação:

"Azure Sandbox isn't intended for production use. The deployment uses some best practices, but other best practices intentionally aren't used in favor of simplicity and cost."

Ou seja, é um ambiente de aprendizado e experimentação. Não é para rodar sua aplicação de produção.

Aí vem a dúvida.

"Isso Eu Já Faço com Terraform"

Confesso: foi exatamente isso que pensei. E se você trabalha com IaC no dia a dia, provavelmente pensou a mesma coisa.

Subscription dedicada? Já faço. Módulos Terraform para VNet, Bastion, Firewall, RBAC? Já tenho. Azure Policy pra governança? Já aplico. Budget alerts? Configurados. Tudo versionado no Git, tudo passando por pipeline de CI/CD.

E o mais importante: tudo isso construído ao longo de meses, ajustado pra realidade dos meus clientes. Naming conventions que fazem sentido, tags que o financeiro entende, policies que refletem as regras de compliance da organização. Infraestrutura moldada pelo contexto real, não um template genérico.

Quando olhei o Azure Sandbox, minha primeira reação foi: "Isso é o que eu já construí — só que com os módulos de outra pessoa."

E tem outro ponto que reforça essa sensação: o custo é exatamente o mesmo. Não existe um "pricing de Sandbox". Você paga pelos recursos do Azure que o Terraform provisiona, igualzinho ao que pagaria provisionando por conta própria. Se o Sandbox cria uma VM, você paga pela VM. Se cria um Azure Firewall, paga pelo Firewall. Não tem desconto, não tem tier especial. Zero diferença no billing.

Então qual é a vantagem?

Mas será que todo time na sua organização tem essa maturidade? Pensa no desenvolvedor que acabou de entrar na empresa e precisa de um ambiente de testes. Ele sabe escrever módulos Terraform com Private Endpoints, Firewall e RBAC? Na maioria das vezes, não. E sabe o que acontece? Ele sobe os recursos pelo portal, sem policy, sem budget, sem isolamento de rede. E ninguém percebe até a fatura chegar.

Separar recursos é fácil. Governar a separação é o desafio.

E foi nesse ponto que minha opinião começou a mudar.

Onde o Azure Sandbox Faz Sentido

Depois de estudar o projeto com mais calma, comecei a ver onde o Sandbox entrega valor real. O ponto não é que ele faça algo tecnicamente impossível sem ele. O ponto é reduzir o tempo e o risco de montar um ambiente governado do zero.

1. Onboarding de Novos Times e Desenvolvedores

Imagine um cenário comum em empresas grandes: um time novo de desenvolvimento precisa de um ambiente Azure para começar a trabalhar. Sem Sandbox, o que acontece? Alguém abre um ticket para o time de infra. O time de infra prioriza. Semanas depois, o ambiente fica pronto. Talvez. E provavelmente sem metade dos guardrails necessários.

Com o Azure Sandbox, em questão de horas você tem um ambiente completo, com rede segmentada, acesso via Bastion, Firewall, banco de dados via Private Endpoint e jump boxes com ferramentas pré-instaladas. O desenvolvedor chega e trabalha. Sem esperar.

E aqui tem um detalhe que gente técnica costuma ignorar: o custo de um desenvolvedor parado esperando ambiente é real. Uma semana de espera de um time de 4 devs custa infinitamente mais do que qualquer recurso Azure que o Sandbox provisiona.

2. Organizações com Múltiplos Times em Diferentes Níveis de Maturidade

Esse talvez seja o cenário mais forte. Em organizações com dezenas de equipes, a realidade é que nem todo mundo está no mesmo nível de IaC. O time A tem Terraform maduro com módulos testados. O time B ainda faz deploy manual pelo portal. O time C acabou de chegar, veio de AWS, e nem sabe o que é Resource Group. Já vi isso acontecer em pelo menos 4 clientes diferentes nos últimos anos.

O Sandbox é um ponto de partida padronizado. Todo mundo começa com os mesmos guardrails: rede segmentada, acesso via Bastion, Firewall, Private Endpoints, budgets. As variações vêm depois, conforme cada time amadurece.

Em vez de cada time inventar sua própria forma de "separar recursos", você tem um baseline. E baseline, em governança, vale ouro.

3. Provas de Conceito Rápidas

Você precisa validar uma ideia em Azure, mas não quer esperar a pipeline de IaC do time de plataforma aprovar, revisar e provisionar o ambiente. O Sandbox te dá uma base governada em minutos. Testa sua ideia, valida, descarta. Pronto! Sem burocracia, sem risco de deixar recursos órfãos sem governança.

4. Treinamento e Capacitação

Hackathons, workshops, sessões de treinamento. Qualquer cenário de aprendizado onde você precisa de um ambiente Azure real, mas com controle de custos e isolamento de produção. A documentação oficial lista explicitamente: self-learning, hackathons, testing, tabletop exercises, red team/blue team simulations, incident response drills.

E diferente de uma subscription vazia onde o participante precisa configurar tudo do zero, o Sandbox já entrega a infraestrutura base pronta. O foco vai pra aprendizado, não pra setup. Isso faz toda a diferença em um workshop de 4 horas onde cada minuto conta!

Agora, se você está pensando "tudo isso eu consigo fazer com meus próprios módulos Terraform", está certo. Consegue. Mas qual é o custo operacional de construir e manter esses guardrails por conta própria? De documentar? De atualizar quando o Azure muda uma API? De treinar cada novo membro do time de plataforma?

Às vezes o valor não está na capacidade técnica. Está no tempo que você economiza ao não reinventar a roda. E tempo, na nossa área, é o recurso mais escasso que existe.

Onde Ele NÃO Faz Sentido

Para sermos justos, o Sandbox não é resposta para tudo. Existem cenários onde ele é claramente redundante ou limitante.

1. Times com IaC Maduro

Se o seu time já tem módulos Terraform ou Bicep customizados, testados, versionados e passando por pipeline, você já tem algo melhor que o Sandbox. São módulos ajustados à sua realidade, com as policies da organização, as naming conventions do time, os tags que o financeiro exige. O Sandbox é genérico por definição. Seu IaC é específico pro seu contexto. Nesse cenário, o Sandbox não vai te trazer nenhum benefício prático. Só mais uma camada de abstração desnecessária.

2. Landing Zone Bem Implementada

Se a sua organização já implementou o Azure Landing Zone do Cloud Adoption Framework (Management Groups, Policy Sets, Connectivity Hub, Identity subscription), o Sandbox se torna redundante. A Landing Zone já prevê um Management Group chamado "Sandboxes" onde você pode colocar subscriptions de experimentação com todas as policies herdadas. Você já tem o mecanismo. O projeto de GitHub não adiciona nada que a sua Landing Zone já não ofereça.

3. Ambientes que Precisam de Customização Pesada

O Sandbox vem com escolhas opinativas: AD DS (não Entra ID nativo), VPN via Virtual WAN, Azure Firewall como padrão. Se a sua organização tem outros requisitos, como zero trust sem AD DS legado, NVA no lugar do Azure Firewall ou hub-spoke personalizado, você vai gastar mais tempo adaptando o Sandbox do que construindo do zero. E adaptar template de outra pessoa é frequentemente mais frustrante do que começar do zero com seus próprios padrões.

Mas mesmo reconhecendo essas limitações, seria injusto dizer que o Sandbox não tem valor. O que ele oferece é acessibilidade, não sofisticação técnica. E em muitas organizações, acessibilidade é exatamente o que falta.

Minha Conclusão — Preciso ou Não?

Voltando à pergunta que abriu esse artigo: o Azure Sandbox tem um fit real, ou é só mais uma forma de separar recursos?

Minha resposta: depende da maturidade do seu time.

Se você trabalha em uma organização com IaC maduro, Landing Zone implementada e um time de plataforma que mantém módulos atualizados, não, você não precisa do Azure Sandbox. Ele não vai te oferecer nada que você já não tenha, e o custo dos recursos é idêntico.

Agora, se você está em uma organização onde:

• Nem todo time sabe provisionar infraestrutura com segurança
• O onboarding de novos ambientes demora semanas
• Não existe um padrão de governança para ambientes de experimentação
• Você precisa de ambientes temporários com guardrails prontos

Aí sim o Sandbox entrega valor real. Porque é imediatamente utilizável.

Separar recursos é fácil. Governar a separação é o desafio. O Azure Sandbox resolve o segundo problema para quem ainda não tem as ferramentas para resolver sozinho.

Lição aprendida: a ferramenta certa depende da maturidade do time, não da sofisticação da tecnologia.

E se você chegou até aqui, fica a reflexão: antes de descartar algo como "redundante", vale perguntar — redundante para quem? Para você, que já domina Terraform e tem pipeline rodando? Ou para o time ao lado, que ainda está descobrindo o que é um Resource Group?

A resposta muda bastante dependendo de qual perspectiva você adota. E talvez, só talvez, a melhor coisa que o Azure Sandbox pode fazer pela sua organização não seja servir como solução permanente, mas como ponto de partida até que o time ganhe maturidade pra construir seus próprios guardrails.

Links Úteis

Documentação Oficial

• Azure Sandbox — Azure Architecture Center — Guia completo de arquitetura, componentes, segurança e deploy
• Azure-Samples/azuresandbox (GitHub) — Repositório com os módulos Terraform do projeto
• Landing Zone Sandbox Environments — Como integrar sandboxes ao Cloud Adoption Framework

Referências da Comunidade

• The Azure Sandbox — Cloud Tips — Análise da comunidade sobre o projeto
• Demystifying Azure Sandbox Pricing — Detalhamento sobre custos e precificação dos componentes

Espero que essa análise tenha te ajudado a formar sua própria opinião! Se você já usa o Azure Sandbox, ou decidiu que não precisa dele, deixa nos comentários como foi a sua experiência.

[]s e até a próxima