Moving to the cloud is pretty exciting. When you open the door to your dev teams it can go crazy fast and next thing you know you have a big mess of Azure resources all over the place. Putting in place a good set of governance guidelines will help you keep everything under control.

The first thing to think about is your Azure Subscriptions structure. This is the very first step that will drive many of your following decisions in order to achieve a good Azure governance.


  1. Security
  2. Cost Management
  3. Scalability
  4. Simplicity

Let's compare some models

1 Subscription per Organization


  • Simple


  • Complex security management
  • No easy way to split the cost
  • Doesn't scale well
  • Azure Limits per sub

This model is often problematic when is comes to managing security and cost. It's very difficult to determine how much each product/project cost per month as everything appear on the same bill. If you have many Azure resources it's a not so nice puzzle to solve. Also, from a security point of view, achieving a good access segregation will be hard. You'll not be able to leverage the permission inheritance from the subscription level. You'll have to give explicit permissions on every resource or resource group which can become a large overhead to maintain over time. Not to mention that if you only give permissions at the resource group level, nobody will be able to create new resource groups. Another aspect to account for is the Azure Limits per subscription. They can be easily reached if you put everything in a single subscription.

1 Subscription per Team


  • Great granularity for cost and security
  • Optimal use of Azure Limits
  • Flexible


  • Complex

This model is a great choice as it will overcome many of the issues of the first model by its granularity. However, it also come with its challenges. If team members tend to change often, your IT people may find it annoying to always set new permissions on impacted subscriptions.

Another point to consider

how will you model shared resources between teams?

There's no great answer to that. Most of the time, it adds some complexity to the model.

If you have too many subscriptions it can become unpleasant to use some tooling like the Azure CLI or Azure PowerShell modules, to name only a few. You'll most likely switch from subscription id to subscription id between every command to be able accomplish your work properly. When this happen, mistakes are very likely to happen (ask me how I know).

1 Subscription per Product/Project


  • Security control
  • Scale well
  • Cost management


  • Overkill for small teams

Having one subscription per Product/Project is a good balance between the two previous model. The only downside to it is that it can be overkill for small teams working on a lot of different projects.

Enforcing this kind of subscription model will give you a nice uniformity overall. This is a very simple an efficient model that will last, even if you Azure needs scale a lot. Having such a nice uniformity will help people to get their way around quickly in Azure.

Side note

I also recommend creating a dev and a prod subscription. Using a separate subscriptions for your dev and prod can save you a lot of money as Azure offer a nice discount on dev/test subscriptions. You can then apply tighter security controls over your production workloads and let the developers explore and test more freely in the dev subscriptions.

i.e. User Access by Role

RoleAccess in dev SubAccess in prod Sub
Operationno accesscontributor

Key takeaways

In the end, the most important is to pick something that will work in your organization. Try to find a model where you are comfortable with the downsides and adapt it overtime.