Simplify Azure Management Group Setup using Bicep Vending

Understanding the Need for Management Group Automation

Managing Azure subscriptions at scale can become challenging. Management groups provide a powerful way to organize and govern resources, but manually configuring them introduces inefficiencies and risks. A common pitfall is hardcoding management group structures into deployment code, which reduces flexibility and can compromise governance. This post introduces Management Group Vending, a reusable Bicep solution inspired by Microsoft’s Subscription Vending . This solution enables you to deploy any management group hierarchy, considering Azure’s limitations while adhering to Cloud Adoption Framework (CAF) principles.

Design for Vending

As of writing this post the maximum depth limit for management groups is 6 levels. This limitation is very helpful it means that out scope is limited to 6 levels. So we can slice any kind of Management Group structure into a maximum of 6 levels or as I like to call them tiers. As an practice example lets use this approach on the management group structure as show in the Azure landing zone conceptual architecture part of the Cloud Adoption Framework (CAF) . The CAF conceptual architecture serves as a solid foundation for designing management group hierarchies, as it reflects industry best practices for organizing Azure resources.

Slicing this management groups structure into tiers would have the following structure:

• Tier 0: Contoso (Corporate Root)
• Tier 1: Platform, Landing Zones, Decommissioned, Sandbox
• Tier 2: Management, Identity, Connectivity, Corp, Online
• Tier 3: Unused
• Tier 4: Unused
• Tier 5: Unused

And visualized as follows:

Now that the tier model is clear lets compose the solution which implements this model. First we have to have a solution bicep file. This is the main execution file which will be executed to deploy the vending solution. This file will contain the logic to deploy the management groups in the correct order and depth. Next we need a bicep resource module. This module will contain the logic to deploy a single management group, hence the resource module. This module is called by the solution bicep file for each management group in a tier. Finally we need a parameter file which provides the collections of management groups to be deployed. On the back of an envelope design would looks something like this:

Build the Management Group Vending Bicep Solution

The solution is composed of three main components:

Resource Module

The resource module is the core building block of the solution. It leverages the Microsoft.Management/managementGroups@2021-04-01 namespace to create individual management groups. The key aspect here is the targetScope = 'managementGroup' property, which allows the deployment of management groups within the correct scope.

This module handles the creation of a single management group, including setting its ID, display name, and parent ID. This modular design ensures reusability and keeps the logic for creating management groups isolated.

Below is an example of a simple resource module:

Solution Bicep File

The solution Bicep file acts as the orchestrator. It consumes the resource module to deploy the management group hierarchy tier by tier. Each tier is represented as a collection of management groups, except for Tier 0, which is the single corporate root management group.

Key highlights of the solution file include:

• Tier Dependencies: Each tier depends on the successful creation of its parent tier. This ensures management groups are deployed in the correct order and hierarchy.
• Default Management Group: Optionally, you can set a default management group for new subscriptions using the IdOfDefaultManagementGroupForNewSubscriptions parameter.
• Permission Settings: The solution allows you to configure whether permissions are required for creating new management groups via the RequireWritePermissionsForNewManagementGroupCreation parameter.

Here is an example of a solution Bicep file:

Parameters File

The parameter file defines the hierarchy of management groups in a JSON format. Each tier is represented as an object containing the management groups within that tier, along with their IDs, display names, and parent IDs.

For example, here is an Azure landing zone conceptual architecture populated parameter file:

Management group naming convention

For anything Infrastructure as Code related a strong naming convention is a crucial cornerstone. Luckily I already have a strong naming convention for management groups, which I have written about in a previous post The ideal Management group naming convention .

Deploy Your Management Group Structure

To deploy the management group structure, you need to perform a tenant-level deployment. This is required because management groups are tenant-level resources. The solution’s Bicep file specifies targetScope = 'tenant' to accommodate this.

Deployment Steps

1. Ensure Permissions: Tenant-level deployments require elevated access. Even the Global Administrator role does not have these permissions by default. You can grant the necessary permissions by following these guides:

   • Required Access
   • Elevate Access for Global Admins

2. Run the Deployment: Use the following PowerShell snippet to initiate the deployment:

Key Considerations

• Deployment Order: Ensure the parameter file is correctly structured to reflect the hierarchy and tier dependencies.
• Validation: Always test the deployment in a canary/sandbox environment before applying it to your production tenant.

Wrapping up

And that’s a wrap, folks! I hope it provided you with a clear and practical approach to automating your Azure management group structures. If you found this post useful, be sure to explore the reference materials that inspired this solution:

• Subscription Vending
• Azure landing zone conceptual architecture
• Cloud Adoption Framework (CAF)
• Tenant deployments with ARM templates
• Elevate access to manage all Azure subscriptions and management groups
• Azure Bicep Module for Management Group Hierarchy
• The ideal Management group naming convention

Thank you so much for taking the time to read this post. If you enjoyed it or learned something new, don’t hesitate to check out my other posts .