A Microsoft recentemente implementou ajustes estruturais significativos no Azure landing zone (ALZ) e no Sovereign landing zone (SLZ). Para equipes de engenharia, arquitetos de cloud e gestores de TI, estas mudanças não são apenas operacionais; elas representam uma evolução na forma como lidamos com a governança em cenários de nuvem híbrida e exigências de soberania de dados.
O Novo ‘Local’ Management Group
A principal alteração na arquitetura conceitual é a adição de um Management Group dedicado (“Local”) sob o grupo de Landing Zones. Ele se posiciona ao lado dos já conhecidos Corp e Online. Para empresas com operações em solo brasileiro, essa mudança é estratégica, especialmente para quem explora o Azure Local (anteriormente Azure Stack HCI) como forma de manter cargas de trabalho em infraestrutura local, mas com a governança centralizada do Azure.
Arquitetura de Management Group
Arquitetura de hierarquia de Management Groups do ALZ.
O impacto na prática: Esse novo grupo facilita a aplicação de guardrails específicos para clusters locais. Além disso, a Microsoft introduziu uma Azure Policy de preview que permite tanto o modo Audit quanto Deny. Isso é um divisor de águas para times de Platform Engineering que precisam garantir a portabilidade de aplicações. Ao aplicar o modo Deny, você garante que nenhum desenvolvedor provisione recursos na nuvem pública que não tenham suporte ou "saída" (exit strategy) garantida para uma operação desconectada (disconnected operations).
Precisa otimizar sua governança em nuvem ou garantir conformidade com políticas rigorosas? Fale com a equipe da Nuvem Online.
Políticas Soberanas (SLZ): Alinhamento L1, L2 e L3
No Sovereign landing zone (SLZ), a mudança é mais profunda. As políticas de Sovereignty Baseline foram substituídas por iniciativas built-in que seguem o modelo de controle L1, L2 e L3. Saímos de baselines genéricos para controles granulares:
- Nível 1 (Data Residency): Foco estrito em restrições regionais para evitar réplicas cross-region.
- Nível 2 (Encryption-at-Rest/in-Transit): Foco em Customer Managed Keys (CMK) via Azure Key Vault Premium ou Managed HSM e imposição de TLS 1.3.
- Nível 3 (Encryption in use): Foco em Confidential Computing (ACC).
Arquitetura do Sovereign landing zone
Hierarquia do SLZ com controles aplicados.
Esta mudança reduz drasticamente o overhead de gestão, pois as políticas agora são mantidas pelo próprio time de produto da Microsoft, eliminando a necessidade de sua empresa realizar o mapeamento manual dessas regulações. Para empresas no Brasil sujeitas à LGPD ou setores altamente regulados (como financeiro ou telecom), isso simplifica o processo de auditoria, uma vez que o compliance pode ser evidenciado diretamente via Microsoft Defender for Cloud.
Vale a pena atualizar?
As mudanças já estão refletidas nas versões 2026.04.2 dos módulos do Azure Landing Zones. Se sua infraestrutura já utiliza a abordagem de landing zones (via Terraform ou Bicep), estas atualizações são essenciais para evitar o débito técnico de tentar manter políticas customizadas de soberania, que agora se tornaram nativas e mais eficientes.
Recomendamos fortemente a migração para essas novas iniciativas built-in conforme o seu ciclo de deployment e testes em ambiente de staging.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
