> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # Azure Service Groups: Governança Real ou Apenas Pastas Virtuais? - URL: https://www.azurebrasil.cloud/blog/azure-service-groups-governanca-real-ou-apenas-pastas-virtuais/ - Published: 2026-06-04T12:00:13.000Z - Updated: 2026-06-04T12:00:12.000Z - Author: Rafael dos Santos 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: | Aspecto | Management Groups | Service Groups | | --------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | **Propósito** | Governança (policies, RBAC) | Organização (visualização, agrupamento) | | **Herança de Policy** | Sim — policies fluem para subscriptions e recursos | Não — sem enforcement de policies | | **Herança de RBAC** | Sim — roles fluem para recursos descendentes | Apenas para Service Groups filhos, não para membros | | **Estrutura** | Hierarquia única (1 parent por subscription) | Múltiplas hierarquias (recurso pode estar em vários grupos) | | **Profundidade** | 6 níveis | 10 níveis | 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ê? | Necessidade | Ferramenta Recomendada | | ------------------------------------------------------------- | -------------------------------------------- | | Aplicar policies de compliance em todas as subscriptions | **Management Groups** | | Herdar RBAC para múltiplas subscriptions | **Management Groups** | | Agrupar recursos de múltiplas subscriptions para visualização | **Service Groups** | | Criar múltiplas visões organizacionais dos mesmos recursos | **Service Groups** | | Agrupar recursos para análise de custos | **Tags** (com Azure Policy para enforcement) | | Agrupar recursos com mesmo ciclo de vida | **Resource Groups** | | Organização para compliance e auditoria | **Management Groups** \+ **Tags** | ## 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?](https://learn.microsoft.com/en-us/azure/governance/service-groups/overview?ref=azurebrasil.cloud) — Visão geral completa da feature em preview - [What are Azure Management Groups?](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview?ref=azurebrasil.cloud) — 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](https://learn.microsoft.com/en-us/azure/governance/service-groups/create-service-group-rest-api?ref=azurebrasil.cloud) — Como criar seu primeiro Service Group - [How to: Manage Service Groups](https://learn.microsoft.com/en-us/azure/governance/service-groups/manage-service-groups?ref=azurebrasil.cloud) — Gestão do ciclo de vida - [Connect service group members with REST API](https://learn.microsoft.com/en-us/azure/governance/service-groups/create-service-group-member-rest-api?ref=azurebrasil.cloud) — Como adicionar recursos como membros