Criar uma máquina virtual no Azure é rápido. O que costuma consumir tempo depois é descobrir que cada equipe organizou recursos de um jeito, que ninguém sabe quem aprova acessos ou que a rede não foi pensada para as aplicações que virão. Uma landing zone existe para tratar essa base antes que ela cresça sem direção.
Ela não é apenas um conjunto de recursos nem um modelo que precise ser copiado inteiro. É uma arquitetura de referência para organizar plataforma e workloads, adaptada às necessidades da empresa. No Cloud Adoption Framework, as decisões passam por áreas como identidade, organização de recursos, rede, segurança, gerenciamento e governança.
Comece pelas decisões, não pelo portal
Antes de provisionar, responda a perguntas concretas: quem administra a plataforma? Como as assinaturas serão separadas por ambiente ou responsabilidade? Quais serviços precisam de conectividade com o datacenter? Que dados de operação e segurança serão coletados? Quais regras são obrigatórias desde o primeiro dia?
Essas respostas ajudam a desenhar grupos de gerenciamento, assinaturas, grupos de recursos, funções de acesso e políticas. O objetivo não é criar a hierarquia mais elaborada. É criar uma estrutura que as equipes entendam e consigam manter.
Faça um inventário antes de desenhar a landing zone
Um retrato inicial dos recursos ajuda a encontrar nomes inconsistentes, componentes esquecidos e dependências que precisam entrar no desenho. O exemplo abaixo consulta um único grupo de recursos e grava um CSV local; não cria, altera nem remove recursos. Confirme o contexto da sessão e troque o GUID de exemplo pelo identificador aprovado da assinatura antes de executar.
$expectedSubscriptionId = '00000000-0000-0000-0000-000000000000'
$context = Get-AzContext
if (-not $context -or $context.Subscription.Id -ne $expectedSubscriptionId) {
throw 'O contexto atual não corresponde à assinatura esperada.'
}
$resourceGroup = 'rg-app-exemplo'
$outputPath = Join-Path $env:TEMP 'inventario-recursos-azure.csv'
$inventory = Get-AzResource -ResourceGroupName $resourceGroup |
Select-Object Name, ResourceGroupName, ResourceType, Location |
Sort-Object ResourceGroupName, Name
$inventory | Export-Csv -Path $outputPath -NoTypeInformation -Encoding UTF8 -NoClobber
$inventory | Format-Table -AutoSizeO CSV pode revelar nomes internos, serviços usados e a estrutura do ambiente. Mantenha o arquivo em local protegido e substitua dados identificáveis antes de compartilhá-lo. A imagem é apenas uma saída ilustrativa, construída com nomes fictícios.
Uma sequência que reduz retrabalho
- Inventarie aplicações, dependências, requisitos de identidade e necessidades de conectividade.
- Separe responsabilidades da plataforma e das equipes de aplicação.
- Defina uma estrutura inicial de assinaturas e convenções de nomes e tags.
- Implante controles básicos de acesso, rede, logs e segurança.
- Valide a fundação com uma workload piloto antes de padronizar a expansão.
Landing zone também não é projeto encerrado na primeira implantação. Novas aplicações, requisitos e serviços podem exigir revisão. A boa base deixa claro onde uma mudança é necessária e quem deve avaliá-la.
O melhor ponto de partida raramente é a arquitetura mais complexa. É a base que atende às necessidades de agora e permite evoluir sem perder de vista quem opera cada parte.
Organize a plataforma em limites compreensíveis
Uma estrutura útil separa responsabilidades sem criar hierarquia desnecessária. Grupos de gerenciamento podem aplicar regras comuns a assinaturas relacionadas; assinaturas ajudam a separar cobrança, acesso e limites operacionais conforme o desenho da empresa; grupos de recursos reúnem componentes que compartilham ciclo de vida. Defina a finalidade de cada limite antes de multiplicá-los.
Converse sobre conectividade, registro e resposta a incidentes. Quais cargas precisam comunicar-se com o datacenter? Quem monitora logs e atende alertas fora do horário? Onde ficam os registros necessários para investigação? Como o acesso administrativo é solicitado e revogado? Essas decisões influenciam a arquitetura e não devem ser deixadas para depois da primeira aplicação.
Lista de verificação para a primeira workload
- Há um dono de negócio e um responsável técnico identificados?
- A assinatura, o grupo de recursos e as tags deixam claro propósito e custo?
- Identidades e funções administrativas seguem o menor privilégio?
- Rede, DNS e conectividade foram testados a partir dos locais de uso?
- Monitoramento, backup, segurança e suporte têm responsáveis definidos?
- Há limite de orçamento ou alertas e processo para avaliar consumo?
- As exceções de governança têm justificativa e revisão?
Custos não podem ser previstos apenas pela arquitetura desenhada. Meça o uso, identifique ambientes de teste que podem ser desligados e avalie compromissos somente com histórico suficiente e requisitos claros. Não transforme uma estimativa de calculadora em promessa de custo final.
O CSV ilustrado acima usa dados inventados. Antes de compartilhar qualquer inventário real, confira nomes, tipos, regiões, tags e metadados que possam revelar a arquitetura da organização.