Azure Service Groups - Flexible Resource Organization

Key Concepts

Azure Resources, Subscriptions, Resource Groups, Tagging, Azure Service Groups (ASGs), Tenant Level Resource, Root Service Group, Parent-Child Relationship, Hierarchy, Globally Unique Naming, Resource Manager ID, Relationships, Extension Resource, Least Privilege, Scoping, Health Monitoring, Resiliency, Azure Policy.

Azure Service Groups: A Deep Dive

The Need for a New Grouping Construct

The video begins by addressing the existing methods of organizing and managing Azure resources:

• Subscriptions: The ultimate boundary and billing boundary.
• Resource Groups: Focused on lifecycle management (creation, running, decommissioning of resources). Resources within a resource group are typically managed together.
• Tagging: Used for adding metadata to resources for tracking purposes.

Despite these existing constructs, there's a lack of flexibility, especially for application teams that don't own the subscription or resource group hierarchy. Workarounds like naming conventions and tags become complex, especially when a component is used in multiple services or needs to be part of an overriding hierarchy. It's also difficult to use tags as a scope for services.

Introducing Azure Service Groups (ASGs)

Azure Service Groups (ASGs) are introduced as a flexible solution to address the limitations of existing constructs. They allow you to group existing resources (subscriptions, resource groups, resources) into a new structure that matches the modeling of your service or capability. ASGs are designed around the principle of least privilege.

ASG Architecture and Hierarchy

• Tenant Level Resource: ASGs are a tenant-level resource, meaning they belong to an Entra tenant.
• Root Service Group: When the first ASG is created, a root service group is automatically created, belonging to the Entra tenant. The ID of the root service group is the same as the Entra tenant ID.
• Parent-Child Relationship: The first ASG created becomes a child of the root service group. Subsequent ASGs can be created as children of existing ASGs, creating a hierarchy.
• Hierarchy Depth: The hierarchy can be up to 10 levels deep (excluding the root).

The video demonstrates this in the Azure portal, showing the tenant root service group and the created child service groups.

Naming Conventions

• Globally Unique: ASG names must be globally unique per cloud (Azure public cloud, US Gov cloud), not just per tenant.
• Case Insensitive: Naming is case-insensitive.
• Character Limit: Names can be up to 250 characters and can include alphanumeric characters and certain special characters.
• Example: The speaker mentions taking the name "service group" early to prevent others from using it.

Membership and Relationships

• Resource Manager ID: Anything with an Azure Resource Manager ID can be added to an ASG (subscriptions, resource groups, individual resources). Management groups cannot be added.
• Many-to-Many Relationship: Resources, resource groups, and subscriptions can be part of multiple ASGs.
• Extension Resource: Adding a resource to an ASG creates an extension resource (a relationship) on the source resource.
• Permissions: To add a resource to an ASG, you need the ability to create a "service group member" relationship on the resource. This requires the Microsoft.Relationships/serviceGroupMembers/write permission.
• Limits: Within a subscription, there's a limit of 2,000 relationships per subscription. Adding a subscription or resource group counts as one relationship, regardless of the number of resources it contains. There is no limit to the number of members within a service group.

Functionality and Scoping

ASGs are not deployment scopes, and you cannot assign policies or permissions directly to them. Their primary purpose is to act as a scope for other functionality.

• Scoping: The whole goal of the Azure service group is to be a scope for functionality.
• Health Monitoring: A key example is health monitoring. ASGs allow you to group resources from different resource groups and subscriptions to monitor the health of a service or its components.
• Resiliency: The speaker suggests that resiliency could be another useful application, allowing you to map dependencies and identify single points of failure.

Future Enhancements

The video mentions ongoing work to enhance ASGs:

• Azure Policy Integration: Work is being done to facilitate operational management via Azure Policy, such as enforcing naming policies.
• Automated Relationship Assignment: Exploring ways to automatically assign relationships based on tags or other criteria.

Conclusion

Azure Service Groups provide a flexible way to model the grouping and hierarchy of your services, enabling you to take advantage of other functionalities like health monitoring and potentially resiliency management in the future. They are designed to be a foundation for other Azure services and features. The speaker emphasizes the importance of understanding ASGs and modeling workloads using them to prepare for future functionality.