Overview of Azure Service Groups (public preview)

In an Azure tenant, you use management groups to organize subscriptions. In that hierarchy, you can define access controls and apply policies.

When resources for a single workload are deployed across multiple subscriptions, management becomes more complex. Azure Service Groups help by allowing you to group resources without moving them.

A Service Group is a logical container that groups resources across subscriptions and resource groups while leaving each resource in its original subscription. You can manage that collection from within the management group hierarchy.

An Azure Service Group is a logical container, similar to a resource group, a subscription, or a management group, but completely separate from the last ones. Service Groups organize resources across subscriptions, resource groups, and management groups without moving these resources. It stores metadata used to identify workloads, track state, and manage processes.

Suppose your networking team manages gateways, load balancers, and other network services that are deployed across several subscriptions. With Azure Service Group, you can create a service group for these networking resources, add the network resources you need, and apply permissions to people who will manage these resources.

With Azure Service Groups, you can create a service group for those networking resources, add the relevant resources, and assign permissions to the people who manage them. Users assigned the Service Group Reader role can view the service group and its child resources.

You also get an inventory of resources in the service group, a list of issues affecting those resources, application maps, and availability tests (if Application Insights is linked), and monitoring recommendations and coverage for VMs and AKS.

Each Service Group requires a unique global name (similar to a storage account; up to 250 characters). Service Groups form a hierarchy: you can create a Service Group at the top level (under the Tenant Root Service Group) or as a child of another Service Group.

You can create a Service Group and associate resources using the Azure Portal or the Azure REST API. There is no dedicated PowerShell cmdlet or Azure CLI tool for the moment.

Below is an example that creates a Service Group and associates a resource using Bicep. (Note: you can also use ARM templates or the REST API.)

Creating a Service Group and associating a resource in Azure Bicep.

param serviceGroupId string
param parentServiceGroupId string
param serviceGroupName string 
param storageAccountName string

resource serviceGroup 'Microsoft.Management/serviceGroups@2024-02-01-preview' = {
  scope: tenant()
  name: serviceGroupId
  properties: {
    displayName: serviceGroupName
    parent: {
      resourceId: '/providers/Microsoft.Management/serviceGroups/${parentServiceGroupId}'
    }
  }
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' existing = {
  name: storageAccountName
}

resource rel1 'Microsoft.Relationships/serviceGroupMember@2023-09-01-preview' = {
  scope: storageAccount
  name: 'childResource1'
  properties: {
    targetId: serviceGroup.id
  }
}

In this example, the service group is created using the Microsoft.Management/serviceGroups at the tenant level. The resource has a name (the ID of the service group) and a display name. It has a parent, either the root service group or another service group.

For associating a resource, a storage account, to the new service group, the Microsoft.Relationships/serviceGroupMember is used. You need a reference of the resource in the scope property.

To get this reference, I use the Existing keyword in bicep to access the resource property without deploying it again.

The scope property in the Microsoft.Relationships/serviceGroupMember don’t take a resourceID in Azure Bicep for the scope property. But ARM template allows it on the same scope property.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "storageAccountName":  {                 
            "type": "string"
        }, 
        "storageAccountRG":  {                 
            "type": "string"
        }, 
        "storageAccountSubID":  {                 
            "type": "string"
        }, 
        "targetServiceGroupResourceID":  {                 
            "type": "string"
        }
    },
    "variables": {},
    "resources": [
                 {
                    "type": "Microsoft.Relationships/serviceGroupMember",
                    "apiVersion": "2023-09-01-preview",
                    "name": "[concat('rel-', parameters('storageAccountName'))]",
                    "scope": "[resourceId(parameters('storageAccountSubID'), parameters('storageAccountRG'), 'Microsoft.Storage/storageAccounts/', parameters('storageAccountName'))]",
                    "properties": {
                      "targetId": "[parameters('targetServiceGroupResourceID')]"
                    }
                  }
    ],
    "outputs": {}
}

Service Groups are in public preview, so APIs and tooling may change before general availability. Still, it’s worth evaluating the feature now if you manage medium or large Azure tenants.