Resumo
Em ambientes pequenos, organizar recursos no Azure costuma ser simples: uma subscription, alguns resource groups, tags e permissões.
Mas em ambientes enterprise, a realidade muda.
Um workload pode depender de recursos em vários resource groups. Um time de plataforma pode operar componentes compartilhados. Um time de segurança pode precisar revisar recursos críticos sem mover nada de lugar. E o CoE pode precisar enxergar o ambiente por domínio, criticidade ou responsabilidade operacional.
É nesse contexto que o Azure Service Groups se torna interessante.
Ele não substitui Management Groups, Subscriptions, Resource Groups ou Tags. A proposta é criar uma camada lógica para organizar recursos de forma transversal, facilitando inventário, operação e governança.
Importante: no momento da publicação deste artigo, Azure Service Groups está em public preview. Use primeiro em laboratório ou piloto controlado.
O problema que ele resolve
A hierarquia tradicional da Azure é:
Management Groups
└── Subscriptions
└── Resource Groups
└── Resources
Essa estrutura continua sendo essencial para Azure Policy, RBAC, landing zones e governança em escala.
O desafio é que a operação nem sempre segue essa mesma lógica.
Exemplo:
rg-lab-networking
- vnet-hub-lab
- route-table-shared
rg-lab-workload
- vnet-app-lab
- nsg-app-lab
rg-lab-security
- nsg-shared-lab
Esses recursos estão separados por ciclo de vida, mas podem fazer parte de visões diferentes:
Visão de plataforma:
- vnet-hub-lab
- route-table-shared
Visão de workload:
- vnet-app-lab
- nsg-app-lab
- route-table-shared
Visão de segurança:
- nsg-app-lab
- nsg-shared-lab
- route-table-shared
O mesmo recurso pode interessar a mais de uma área. Service Groups ajuda justamente a criar essas visões sem mover recursos, alterar subscriptions ou redesenhar a hierarquia.
Onde Service Groups se encaixa?
| Recurso | Melhor uso |
|---|---|
| Management Groups | Governança em escala, Azure Policy e RBAC |
| Subscriptions | Separação por ambiente, billing ou responsabilidade |
| Resource Groups | Ciclo de vida dos recursos |
| Tags | Metadados como owner, ambiente e centro de custo |
| Service Groups | Visões transversais por plataforma, workload, segurança ou operação |
Em resumo:
Resource Groups organizam recursos por ciclo de vida.
Tags descrevem os recursos.
Management Groups sustentam a governança.
Service Groups criam visões operacionais.
Service Groups cria visões paralelas sem alterar a organização base dos recursos.
Casos de uso práticos
1. Visão de plataforma
Um time de plataforma pode usar Service Groups para agrupar recursos de rede, segurança ou observabilidade.
Exemplo:
sg-platform-networking
- VNets
- NSGs
- Route Tables
- Private DNS Zones
Isso ajuda o time a ter uma visão operacional mesmo quando os recursos estão distribuídos.
2. Visão de workload crítico
Um workload pode depender de rede, segurança, storage, identidade e observabilidade.
Exemplo:
sg-workload-critical-app
- VNet da aplicação
- NSG da aplicação
- Key Vault
- Storage Account
- Log Analytics Workspace
Essa visão ajuda em inventário, análise de impacto e documentação técnica.
3. Visão de segurança
O time de segurança pode criar uma visão com recursos que precisam de revisão.
Exemplo:
sg-security-review
- NSGs sensíveis
- Route Tables críticas
- Recursos expostos
- Recursos com exceção temporária
O objetivo não é mudar a estrutura do ambiente, mas facilitar análise e governança.
Laboratório prático usando uma única subscription
Este laboratório foi pensado para uma subscription de estudo, como uma subscription MCT, sem necessidade de criar várias subscriptions.
A ideia é simular um cenário enterprise com três visões:
sg-platform-networking
sg-workload-critical-app
sg-security-review
Desenho do laboratório
Crie três resource groups:
rg-lab-networking
rg-lab-workload
rg-lab-security
Crie recursos simples:
rg-lab-networking
- vnet-hub-lab
- route-table-shared
rg-lab-workload
- vnet-app-lab
- nsg-app-lab
rg-lab-security
- nsg-shared-lab
Não é necessário criar Azure Firewall, VMs ou recursos caros. O foco é demonstrar organização lógica.
Recursos simples usados para simular plataforma, workload e segurança em uma única subscription.
Criando os Service Groups
No portal Azure, pesquise por:
Service Groups
Crie o primeiro grupo:
Service Group ID: sg-platform-networking
Display name: Platform Networking
Adicione:
rg-lab-networking
vnet-hub-lab
route-table-shared
Crie o segundo grupo:
Service Group ID: sg-workload-critical-app
Display name: Workload Critical App
Adicione:
vnet-app-lab
nsg-app-lab
route-table-shared
Crie o terceiro grupo:
Service Group ID: sg-security-review
Display name: Security Review
Adicione:
nsg-app-lab
nsg-shared-lab
route-table-shared
O que o laboratório demonstra
Ao final, teremos três visões diferentes sobre recursos da mesma subscription:
sg-platform-networking
- rg-lab-networking
- vnet-hub-lab
- route-table-shared
sg-workload-critical-app
- vnet-app-lab
- nsg-app-lab
- route-table-shared
sg-security-review
- nsg-app-lab
- nsg-shared-lab
- route-table-shared
O ponto principal é que o recurso não foi movido. Ele continua no mesmo resource group, mas passa a aparecer em diferentes visões operacionais.
Isso é útil porque, em ambientes reais, a mesma VNet, NSG, route table ou workspace pode ser relevante para plataforma, segurança, operação, FinOps e workload.
Resultado final do laboratório com visões separadas para plataforma, workload e segurança.
Boas práticas para adoção
Antes de usar Service Groups em escala, recomendo definir algumas regras simples:
- criar padrão de nomenclatura;
- definir owner para cada Service Group;
- manter tags obrigatórias;
- evitar grupos sem finalidade clara;
- revisar membros periodicamente;
- documentar quando usar Service Groups e quando usar Management Groups;
- usar primeiro em laboratório ou piloto enquanto o recurso estiver em preview.
Sugestão de nomenclatura:
sg-platform-[dominio]
sg-workload-[nome]-[ambiente]
sg-security-[finalidade]
sg-coe-[finalidade]
Exemplos:
sg-platform-networking
sg-platform-observability
sg-workload-critical-app-prod
sg-security-review
sg-coe-prod-critical
Quando usar
Eu usaria Azure Service Groups para:
- organizar recursos por plataforma;
- criar visão por workload;
- apoiar inventário;
- agrupar recursos críticos;
- facilitar revisão de segurança;
- organizar evidências de governança;
- criar visões para CoE, plataforma, segurança, FinOps e operação.
Quando não usar
Eu não usaria Azure Service Groups para:
- substituir Management Groups;
- substituir Azure Policy;
- substituir tags;
- conceder acesso direto aos recursos membros;
- corrigir falta de governança;
- criar agrupamentos sem owner;
- sustentar controles críticos enquanto o recurso estiver em preview.
Conclusão
Azure Service Groups é uma camada complementar para organizar recursos no Azure.
Ele não muda a hierarquia, não substitui tags e não elimina a necessidade de Management Groups. O valor está em criar visões operacionais que representam melhor a forma como os times trabalham.
Mesmo com uma única subscription de laboratório, é possível demonstrar um cenário próximo da realidade enterprise: plataforma, workload e segurança olhando para recursos compartilhados sob perspectivas diferentes.
Minha recomendação é começar simples:
sg-platform-networking
sg-workload-critical-app
sg-security-review
Depois, avalie se essas visões ajudam na operação, no inventário e na governança.
A maturidade em cloud governance não está apenas em organizar recursos tecnicamente. Está em tornar o ambiente compreensível, operável e governável para quem precisa tomar decisão.
