Azure Governance

Azure Governance is basically about three things:

  • Policies to enforce compliance to corporate and regulatory requirements (Azure Portal: Policies)
  • Role-based Access Control (RBAC, Azure Portal: Access Control)
  • Cost Management (Azure Portal: Budget)

Polices, RBAC and Cost Management can be applied at four different levels:

  • Management Group (also an Azure service).
  • Subscription.
  • Resource Group.
  • Resource.

In short, we will have a resource structure with four different levels. Let’s look at resource groups first. Resource groups are just logical containers for multiple resources. These resources could be of different types, but each resource only belongs to one resource group. Resource groups cannot be nested. It’s really up to you on what basis you group resources into a resource group. The question is: what makes the most sense? One interesting grouping I saw at a client was as follows:

  • Make a resource group per reusable resource type -> Think of functions, storage, servicebus, monitoring (log analytics, application insights), api management instance, api management products, key vault. 
  • Make a resource group per application (could be both source and destination) and environment (T, A, P) -> [application]-t-rg, [application]-a-rg, [application]-p-rg. Think of  logic apps and API connections (storage, servicebus, application insights).
  • Make a separate resource group for API Management and environment (T, A, P). Think of API Management services, named values, linked products.
  • Make separate infrastructure related resource groups. Think of virtual networks, subnets, network security groups and VMs.

For reasons of resource group name brevity, I didn’t mention yet that resource groups are prefixed by a three or four letter acronym of the company or the business unit. Also not that people sometimes say that resourcegroups have resources that share the same lifecycle. I would say, those resources have to be added to the same CI/CD pipeline. It’s just one granularity level deeper. Examples:

  • [application]-[entity]-[in/out]-[cicd], ie:
    • webshop-orders-in-cicd, d365-orders-out-cicd.
  • [resourcetype]-[cicd], ie:
    • [function]-cicd, storage-cicd, monitoring-cicd, security-cicd.


  • The environments are reflected in the different stages of the release pipeline.
  • Note that CI/CD pipelines are always linked to a resource group, so all artifacts within a CI/CD pipeline should be within the same resource group. We can choose whether or not to use orchestrators. Let’s say we have an application specific function. We could deploy the function as part of the application or we could deploy the function separately while using the application’s resource group.

One level up, we arrive at the subscription level.  In Development, Test and Accept we can use a Dev/Test subscription for Teams. This is not just an individual MSDN subscription. In Production we uses one of two subscription types: Customer Agreement (Pay as you Go) or Enterprise Agreement. Pay as you Go literally means you only pay per use. With an Enterprise Agreement you actually have a contract and commit to some base monthly resource consumption. For commitments, you can get discounts. So, it could make sense to use an Enterprise Agreement subscription for Infra related resource groups. In other words, you could have separate subscription for Infrastructure/Platform and Development.

Another distinction we can make is between production and non-production. That’s because Developers have access to non-production. Operators have access to non-production and production. This distinction motivated by security reasons.

Finally, let’s assume now our company operates in two regions: West Europe and North-East US. This regional setup will most likely be the basis for separate subscriptions as well. Or more in general, it’s likely that different business units and/or cost centers have different subscriptions.

The last level we want to talk about is management groups. Management groups can be nested and contain one or more subscriptions. Why would we need management groups? That’s best illustrated by a few examples:

  • Think of a security officer and the RBAC roles the security officer needs. One could argue, a security officer should oversee all subscriptions. Hence, the security officer role is created at the management group level, not at the subscription or resource group level. The same goes for enterprise architects.
  • Next think of subscriptions for different regions. One could argue that naming and tagging policies don’t differ per region. Hence, a number
    of policies can best be created at the management group level.

To sum up from a practical viewpoint. For a company active in the Netherlands only, we could have:

  • One root management group, with two nested management groups for InfraStructure and Development, with two nested management groups for Production and Non-Production: [company/bu]-[infra/dev]-[np/p]-mg
  • Per management group we have two subscriptions: [company/bu]-[infra/dev]-[np/p]-sc, so four subscriptions in total.
  • Within Development we would have resource groups: [company/bu]-[application]-[t/a/p]-rg, [company/bu]-[apim]-[t/a/p]-rg. The Test and Acceptance resource groups are contained in the non-production subscription. The Production resource group is contained in the production subscription.
  • Within InfraStructure we would have resource groups: [company/bu]-[infra]-[t/a/p]-rg, [company/bu]-[platform]-[t/a/p]-rg

Some resources must be uniquely named across entire Azure. There might also be naming limitations when it comes to casing, the use of dashes and allowed length.
It’s a good idea to put a resource group overview on your dashboard.