O Azure lançou em public preview uma feature chamada Service Groups. A promessa: criar múltiplas visões organizacionais dos seus recursos, sem alterar a hierarquia existente.

A pergunta que este artigo responde: Isso resolve um problema real ou é apenas uma forma de criar pastas virtuais no Azure?

O Que São Service Groups?

Service Groups são uma hierarquia paralela aos Management Groups. Não substituem, não conflitam — coexistem.

A diferença fundamental está no modelo:

A arquitetura é elegante: enquanto Management Groups organizam containers (subscriptions), Service Groups podem agrupar qualquer coisa — subscriptions, resource groups, ou recursos individuais. E o mesmo recurso pode pertencer a múltiplos Service Groups simultaneamente.

Como Funciona na Prática

Service Groups são criados no nível do tenant, dentro do Resource Provider Microsoft.Management. A estrutura funciona assim:

1. Root Service Group — Criado automaticamente pelo Azure (ID = Tenant ID), similar ao Root Management Group
2. Service Groups filhos — Você cria hierarquias de até 10 níveis sob o root
3. Memberships — Recursos, Resource Groups ou Subscriptions são "conectados" aos Service Groups via relationships

O ponto crucial: a membership é uma referência, não uma movimentação. Seus recursos continuam exatamente onde estão na hierarquia de Management Groups/Subscriptions. O Service Group apenas cria uma visão alternativa.

Modelo de Permissões

Service Groups têm seu próprio modelo RBAC com três roles built-in:

• Service Group Administrator — Gerencia tudo: Service Groups, memberships, e role assignments
• Service Group Contributor — Cria e gerencia Service Groups e memberships, mas não pode atribuir roles
• Service Group Reader — Visualização apenas

Detalhe importante: roles atribuídos no Service Group não fluem para os recursos membros. Se você der Reader no Service Group "Produção" para alguém, essa pessoa pode ver quais recursos pertencem ao grupo, mas precisa de permissões separadas nos recursos em si para acessá-los.

Isso habilita um padrão de least-privilege: equipes podem ter visibilidade de inventário sem acesso aos recursos.

Cenários Onde Service Groups Brilham

Após analisar a documentação e os cenários propostos pela Microsoft, identifico três casos de uso concretos:

1. Inventário Unificado Cross-Subscription

Imagine que você quer uma visão de "todos os bancos de dados da empresa":

• Azure SQL em subscription-apps-produção
• Cosmos DB em subscription-data-platform
• Redis Cache em subscription-shared-services

Sem Service Groups, você precisa de queries KQL, tags (que nem sempre estão consistentes), ou documentação manual.

Com Service Groups, você cria um grupo "Databases-Enterprise" e adiciona todos os bancos como membros. Pronto — uma visão consolidada.

2. Múltiplas Visões Para Diferentes Personas

O mesmo conjunto de recursos pode precisar de organizações diferentes dependendo de quem pergunta:

• Time de Produto: "Mostre tudo do Workload A"
• Time de Compliance: "Mostre tudo em Produção"
• Finance: "Mostre tudo do Departamento de Marketing"

Com Service Groups, o mesmo Azure SQL Database pode pertencer simultaneamente a:

• Service Group "Workload-A"
• Service Group "Produção"
• Service Group "Marketing"

Cada persona tem sua visão sem conflito.

3. Agregação de Métricas Cross-Boundary

Recursos de networking compartilhados (VNets, ExpressRoute, Firewalls) frequentemente servem múltiplas aplicações em subscriptions diferentes. Service Groups permitem agrupá-los para visualização consolidada de métricas e inventário.

Então... É Só Uma Pasta Melhorada?

Não exatamente. A diferença entre Service Groups e "apenas usar tags" ou "manter uma planilha":

1. Hierarquia estruturada — Tags são key-value flat. Service Groups suportam 10 níveis de aninhamento com herança de RBAC entre níveis.

2. RBAC dedicado — Você pode controlar quem vê quais agrupamentos sem dar acesso aos recursos em si.

3. API nativa — Service Groups são recursos ARM de primeira classe, consultáveis via REST API, CLI (quando disponível), e integráveis com automações.

4. Múltiplas memberships — Um recurso pode estar em quantos Service Groups você quiser. Com tags, você tem o valor da tag; com subscriptions, você tem uma hierarquia.

Mas também não é governança. E isso é por design, não limitação.

O Que Service Groups NÃO Fazem

É importante ser claro sobre os limites:

• Sem enforcement de policies — Atribuir um recurso a um Service Group não aplica nenhuma policy nele. Para compliance e governança, continue usando Management Groups.

• Sem integração com Cost Management — Até o momento, Service Groups não aparecem como dimensão de agrupamento no Azure Cost Management. Para análise de custos, tags continuam sendo o caminho.

• Custom roles não suportados no preview — Por enquanto, apenas os três roles built-in funcionam.

• Limite de 2.000 relationships por subscription — Se você tem subscriptions com milhares de recursos, pode atingir esse limite.

• REST API only no preview — Não há UI no portal Azure ainda. Toda gestão é via API.

Quando Usar O Quê?

Como saber se é para você?

Service Groups preenchem uma lacuna real — mas específica.

Se sua organização sofre com:

• Falta de visibilidade cross-subscription
• Necessidade de múltiplas visões organizacionais
• Inventário distribuído que é difícil de consolidar
• Personas diferentes precisando de agrupamentos diferentes

Então Service Groups oferecem valor genuíno.

Se você está buscando:

• Enforcement de policies
• Governança centralizada
• Análise de custos por agrupamento

Continue com Management Groups e Tags. Service Groups não competem nesse espaço — nem tentam.

A melhor forma de pensar em Service Groups: são uma camada de organização que complementa a governança, não a substitui. Pastas virtuais inteligentes com RBAC próprio e múltiplas hierarquias? Talvez. Mas são pastas que resolvem problemas que pastas simples não resolvem.

Lições Aprendidas

1. Service Groups não substituem Management Groups — são complementares. Management Groups para governança, Service Groups para organização.

2. Ausência de herança é feature, não bug — permite visibilidade de inventário sem conceder acesso aos recursos, habilitando least-privilege.

3. Múltiplas memberships são o diferencial — o mesmo recurso em vários grupos resolve o problema da "hierarquia única" que Management Groups impõem.

4. Preview significa limitações — sem portal UI, sem custom roles, limites de relationships. Avalie se faz sentido adotar agora ou esperar GA.

5. Tags continuam relevantes para custos — Service Groups não integram com Cost Management. Para FinOps, tags + Azure Policy ainda são o caminho.

E você, já experimentou Service Groups no seu ambiente? Compartilhe nos comentários quais cenários você está considerando — ou se encontrou alguma limitação que não mencionei aqui.

Referências

Documentação Oficial

• What are Azure Service Groups? — Visão geral completa da feature em preview
• What are Azure Management Groups? — Referência para comparação com a hierarquia tradicional de governança

Gestão de Service Groups

• Quickstart: Create a service group with REST API — Como criar seu primeiro Service Group
• How to: Manage Service Groups — Gestão do ciclo de vida
• Connect service group members with REST API — Como adicionar recursos como membros