O que é uma landing zone (e o que ela não é)
Landing zone é a fundação sobre a qual os workloads são construídos: assinaturas, rede, identidade, governança e automação definidos antes do primeiro recurso de aplicação. Não é um produto, não é um template pronto do CAF e não é um projeto com data de fim. É uma plataforma.
O erro conceitual mais comum é tratá-la como etapa burocrática de migração. Na prática, ela define se cada workload novo nasce padronizado ou nasce sendo consertado.
1. Assinaturas e Management Groups
A hierarquia de Management Groups e a estratégia de assinaturas definem limites de custo, acesso e política desde o topo.
- Separe ambientes (produção, não produção, sandbox) em assinaturas distintas.
- Use Management Groups para aplicar Policy e RBAC em bloco, não recurso a recurso.
- Defina ownership de cada assinatura: quem consome, quem paga, quem responde.
2. Rede
Hub/spoke, conectividade híbrida, DNS e endereçamento pensados para crescer. Endereçamento mal planejado é o erro mais silencioso: uma VNet com /24 parece suficiente até o dia em que o espaço acaba. Reserve espaço maior do que a necessidade atual: endereço é barato, re-endereçar não é.
3. Identidade e acesso
Entra ID como fonte única de identidade, RBAC com menor privilégio e PIM para elevação just-in-time. Nenhuma credencial estática em código, nenhuma conta permanente com Owner. A identidade é o perímetro: quem acessa o quê precisa ser auditável desde o dia 1.
4. Segurança
Defesa em profundidade: Key Vault para segredos, políticas de rede entre camadas, inspeção centralizada no hub. Segurança não é um serviço que se adiciona depois, é uma propriedade do desenho.
5. Governança
Azure Policy, tags, budgets e ownership desde o primeiro recurso. "Governança depois que estabilizar" é a frase que mais antecede incidentes de custo e conformidade. Tag obrigatória, budget com alerta e política de negação para o que não está padronizado.
6. Automação
IaC com Terraform ou Bicep para toda a fundação, sem exceção. Fundação que existe só no portal não é reproduzível, não é auditável e não sobrevive à troca de time. O IaC também é a documentação: o repositório conta como o ambiente foi construído.
7. Operação
Observabilidade, FinOps, backup e DR como parte do desenho, não como remendo. A landing zone só cumpre seu papel quando a operação dela é previsível: monitoramento com resposta definida, custos visíveis por time, recuperação testada, não presumida.
Os 4 erros que mais vejo
- Criar recurso antes da fundação. O projeto precisa entregar, a fundação "atrapalha", e o ambiente nasce sem padrão.
- Rede redesenhada no meio do caminho. O refaze mais caro que existe em Cloud.
- "Governança depois que estabilizar." O dia em que estabiliza nunca chega.
- IaC só para o que é novo. O legado fica fora do controle e vira dívida permanente.
Projeto ou plataforma?
O que acontece:
- escopo fecha na entrega da migração;
- governança entra "depois que estabilizar";
- IaC cobre só o que é novo;
- cada workload novo renegotia a fundação.
O que acontece:
- fundação versionada e evoluindo em IaC;
- Policy, tags e budgets desde o dia 1;
- workload novo herda o padrão sem renegotiar;
- operação previsível: observabilidade, backup e DR no desenho.
Checklist prático
- Hierarquia de Management Groups e separação de assinaturas definidas?
- Endereçamento documentado com espaço para crescimento?
- Identidade com menor privilégio e PIM, sem credenciais estáticas?
- Policy, tags e budgets ativos desde o primeiro recurso?
- Fundação inteira em IaC, versionada e revisável?
- Observabilidade, backup e DR desenhados junto com a plataforma?
Conclusão
Landing zone não é projeto, é plataforma. Os 7 pilares (assinaturas, rede, identidade, segurança, governança, automação e operação) definem se o ambiente Azure nasce pronto para crescer ou nasce sendo consertado. O investimento na fundação é o de menor custo e maior retorno de todo o ciclo de vida da plataforma.