Diagrama de Azure Landing Zone: grupos de gerenciamento, assinaturas e rede hub

A maioria dos ambientes Azure começa do mesmo jeito. Alguém cria uma assinatura para um piloto, depois uma para produção, e então cada equipe ganha a sua. Dois anos depois, 40 assinaturas ficam sob o grupo raiz do tenant, três executam seus próprios gateways de VPN, uma VM de banco de dados tem IP público e ninguém sabe quais políticas valem onde.

Uma Azure landing zone é o projeto de referência da Microsoft para evitar isso. Este post cobre cada parte com um diagrama: grupos de gerenciamento, landing zones de plataforma versus de workload, barreiras de política, hub-and-spoke versus Virtual WAN, identidade e implantação.

O que é uma Azure landing zone

O Cloud Adoption Framework (CAF) define uma Azure landing zone como «uma arquitetura comprovada e flexível para governar, proteger e escalar um ambiente Azure com várias assinaturas» (Microsoft Learn). Ela tem duas partes:

• A landing zone de plataforma: a hierarquia de grupos de gerenciamento mais recursos compartilhados, como a rede hub, o registro de logs e as ferramentas de segurança. A Microsoft recomenda uma por tenant do Microsoft Entra, operada por uma equipe de plataforma.
• Landing zones de workload: uma por workload, de propriedade da sua equipe, com todos os ambientes (desenvolvimento, teste, produção) como uma ou mais assinaturas. Materiais mais antigos as chamam de landing zones de aplicação.

A assinatura é o bloco de construção: o CAF a chama de unidade de gerenciamento, cobrança e escala. Em termos de AWS, uma assinatura equivale mais ou menos a uma conta e um grupo de gerenciamento a uma unidade organizacional; o diagrama de landing zone da AWS mostra esse lado.

A hierarquia de grupos de gerenciamento

Uma atribuição de política ou de função em um grupo de gerenciamento vale para tudo abaixo dele, e os proprietários de assinaturas não podem alterá-la. O Azure permite 10.000 grupos de gerenciamento por tenant, seis níveis abaixo da raiz e um pai cada, segundo a documentação de grupos de gerenciamento.

A hierarquia de referência, com notas das atribuições de política do ALZ padrão:

Três regras do guia de grupos de gerenciamento do CAF evitam a maioria dos redesenhos:

1. Mantenha-a plana. Três ou quatro níveis bastam; não crie grupos de gerenciamento para regiões nem para desenvolvimento, teste e produção.
2. Atribua na raiz intermediária, não na raiz do tenant. Novas assinaturas caem por padrão sob a raiz do tenant, e qualquer usuário pode criar grupos de gerenciamento até você exigir permissão. Mude as duas coisas e faça do Sandbox o padrão.
3. Dê às equipes de workload funções no escopo da assinatura. As equipes de plataforma podem ter funções em grupos de gerenciamento, controladas com acesso just-in-time.

Os nomes estão mudando: Security entrou em Platform em 2025, e a visão geral mais recente do CAF usa «Workload landing zones» para Landing zones e «Internal» para Corp.

Landing zones de plataforma versus de workload

No subscription vending, uma solicitação, muitas vezes um pull request, cria a assinatura sob Corp ou Online, atribui funções e um orçamento e, para Corp, adiciona um spoke com peering para o hub. A Microsoft publica módulos de vending para Bicep e Terraform.

Barreiras guiadas por política

O Azure Policy transforma a hierarquia em aplicação de regras: atribua uma regra uma vez em um grupo de gerenciamento, e cada assinatura atual e futura abaixo dele a herda.

Regras de região exigem cuidado: a política integrada Allowed locations ignora grupos de recursos e o local global, então combine-a com Allowed locations for resource groups e comece no modo DoNotEnforce para ver o que ela bloquearia:

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

O tempo importa: uma nova atribuição vale em cerca de cinco minutos, uma assinatura movida para um grupo de gerenciamento é avaliada em cerca de 30 minutos, e uma varredura completa roda a cada 24 horas. Políticas DeployIfNotExists e Modify agem sobre recursos novos e atualizados; os existentes precisam de uma tarefa de correção.

Rede: hub-and-spoke ou Virtual WAN

A assinatura de conectividade é dona da rede compartilhada: Azure Firewall, gateways de VPN e ExpressRoute, Bastion, zonas DNS privadas e o DNS Private Resolver. O guia de topologia de rede do CAF oferece dois desenhos:

O peering não é transitivo, então em uma rede virtual hub cada spoke recebe uma tabela de rotas que envia 0.0.0.0/0 para o IP privado do firewall, o peering do hub permite gateway transit e o peering do spoke usa o gateway remoto; o post sobre a topologia de rede hub-and-spoke cobre o roteamento. O Azure Firewall Basic lida com até 250 Mbps, o Standard com 30 Gbps e o Premium com 100 Gbps. Para o Virtual WAN, escolha o tipo Standard; o Basic só oferece suporte a VPN site a site.

O DNS é onde as equipes mais erram. Zonas DNS privadas como privatelink.blob.core.windows.net ficam na assinatura de conectividade, vinculadas ao hub, onde o DNS Private Resolver encaminha para o Azure DNS em 168.63.129.16; servidores DNS locais encaminham a ele zonas como blob.core.windows.net. Uma política DeployIfNotExists em Corp grava o registro de cada endpoint privado na zona central, então as equipes de workload não precisam de direitos sobre ela.

Identidade

O tenant do Microsoft Entra é o limite de identidade. As regras práticas do CAF:

• Dê às equipes de workload funções nas suas próprias assinaturas durante o vending, nunca em grupos de gerenciamento.
• Deixe os engenheiros de plataforma ativarem funções como Owner pelo Privileged Identity Management (PIM), com aprovação e limite de tempo.
• Aplique Acesso Condicional a todos que gerenciam o Azure e mantenha contas de acesso de emergência monitoradas.
• Use a assinatura de identidade para controladores de domínio ou Microsoft Entra Domain Services se os workloads ainda precisarem deles.

Implantando

No momento da escrita (novembro de 2026), a Microsoft recomenda o Azure Landing Zones IaC Accelerator: Bicep ou Terraform baseados em Azure Verified Modules (AVM). Seu módulo de PowerShell prepara um repositório do GitHub ou do Azure DevOps, pipelines com aprovações e identidades gerenciadas com credenciais federadas. O Terraform usa módulos separados para a hierarquia e a política (avm-ptn-alz), os recursos de gerenciamento e cada desenho de rede; o Bicep usa deployment stacks, que podem excluir recursos que você remover dos templates.

As opções antigas estão sendo aposentadas: o módulo Terraform caf-enterprise-scale está obsoleto, e o ALZ-Bicep clássico saiu do acelerador em 16 de fevereiro de 2026, com seu repositório a ser arquivado em 16 de fevereiro de 2027. Resta um acelerador de portal, mas sem código ele é difícil de atualizar.

Reserve orçamento. A página de cenários do acelerador estima a infraestrutura fixa em cerca de US$ 5.640 por mês para um hub-and-spoke de região única com Azure Firewall, e US$ 690 para a variante de pequena empresa, que entre outras coisas desativa o plano DDoS Network Protection (preços de varejo de westus de abril de 2026, sem tráfego e logs). Você também precisa de quatro assinaturas de plataforma, ou duas na configuração de pequena empresa.

O diagrama de Azure landing zone

Como ler:

• A árvore à esquerda é a hierarquia; as setas vão do pai para o filho, a direção da herança.
• O nó de política fica na raiz intermediária Contoso, não no grupo raiz do tenant, então alcança toda a landing zone e nada mais.
• As cores mostram a propriedade: azul para plataforma, verde para workloads, âmbar para Sandbox, cinza para a raiz e as assinaturas aposentadas.
• Arestas tracejadas mostram a localização: o hub fica na assinatura de conectividade, e os dois spokes são provisionados em Corp.
• Arestas contínuas levam tráfego: peering com o hub e o link do gateway com o ambiente local; cada spoke roteia 0.0.0.0/0 para o firewall em 10.0.0.4.
• O bloco Markdown lista os limites principais.

Desenhando diagramas de Azure landing zone com clareza

• Desenhe governança e rede como duas visões, ligadas só onde uma assinatura vive.
• Prenda cada política onde ela é atribuída, para que os leitores vejam quais workloads ela restringe.
• Mostre uma ou duas assinaturas de exemplo por grupo, não um inventário.
• Escreva as faixas de endereços no hub e em cada spoke; sobreposições são a primeira coisa que os revisores conferem.
• Evite os erros clássicos: peering desenhado como transitivo, workloads sob a raiz do tenant, e regiões ou ambientes como grupos de gerenciamento.

Veja os diagramas de arquitetura de nuvem para nós de nuvem tipados, e o post sobre o diagrama de arquitetura do Terraform para ambientes gerenciados com Terraform.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione oito nós Recurso de nuvem do pacote Nuvem: Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox e Decommissioned. Coloque cada função na linha do tipo de recurso e organize-os como uma árvore indentada.
3. Conecte pais a filhos com arestas ortogonais e colora os ramos: azul para Platform, verde para Landing zones, âmbar para Sandbox.
4. Adicione um nó Política do pacote Segurança chamado Azure Policy guardrails e conecte-o a Contoso.
5. Adicione um nó VPC do pacote Rede para o hub, com um Roteador para o gateway e um Firewall dentro, e dois nós VPC para os spokes, cada um com uma linha Texto do pacote Básico para sua rota.
6. Desenhe arestas tracejadas de Platform para o hub e de Corp para os spokes, arestas de peering para o hub e uma aresta do gateway para um rótulo Texto do ambiente local.
7. Adicione um bloco Markdown do pacote Básico com os limites.

Se a sua landing zone está em Terraform, a ferramenta Terraform to diagram transforma os arquivos em um primeiro rascunho.

O exemplo usa 15 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O que é uma Azure landing zone? Um ambiente Azure com várias assinaturas construído segundo as recomendações do Cloud Adoption Framework antes de os workloads chegarem: grupos de gerenciamento, barreiras de política, identidade, registro de logs e uma rede compartilhada.

Quais grupos de gerenciamento uma Azure landing zone usa? Uma raiz intermediária sob o grupo raiz do tenant, com Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox e Decommissioned abaixo dela.

Qual é a diferença entre as landing zones Corp e Online? Corp abriga workloads que alcançam a rede corporativa pelo hub, então os padrões negam ali endpoints PaaS públicos e IPs públicos em interfaces de rede. Online abriga workloads que precisam de acesso direto à internet ou de nenhuma rede virtual.

Devo usar hub-and-spoke ou Virtual WAN? Uma rede virtual hub serve para poucas regiões, menos de 30 túneis site a site e controle total do roteamento; o Virtual WAN serve para muitas regiões e filiais, SD-WAN ou trânsito de VPN para ExpressRoute.

O módulo Terraform caf-enterprise-scale ainda tem suporte? Não. Ele está obsoleto e não recebe atualizações. Use os Azure Verified Modules para a landing zone de plataforma, em geral pelo acelerador de IaC; a Microsoft documenta um caminho de migração.

Comece grátis — um assento, sem cartão de crédito.