Share via

Azure Subscription Governance - Resource Group and Naming Convention Strategies

  • Article

Greetings Readers!

I am just getting started in the blog business and would love to hear your feedback in the comments section. Today, I will talk about different strategies and things to consider when getting started with your Azure Subscriptions.

I have interacted with many customers that are going through the early stages of onboarding workloads into Microsoft Azure, in most cases, once they have an Azure subscription ready, they do not know where to start. There are many design decisions that need to be made at the beginning of this journey that will have long lasting impact, some of those things simply cannot be changed down the road or may be changed with a tremendous amount of effort, therefore, it is important to take the time to design this properly from the get go. In this blog post, I will cover the most important considerations and will give examples of strategies that large customers are using.

1 - How many subscriptions should I create?

There are mainly three aspects to consider here: Billing, Access Control and Subscription limits, each one of them will play a role in the decision-making process, but should not be the only single factor weighing in that decision. Customers should aim to have as fewer subscriptions as possible to keep it simple.

Billing

Billing reports can be generated by subscriptions, if you have multiple internal departments and need to do chargeback, a possible scenario is to create subscriptions by department/project. Billing can also be achieved through other methods such as EA Departments and the billing API, therefore, there is flexibility here.

Access Control

A subscription is a deployment boundary for Azure resources in the same way a domain is a deployment boundary for Active Directory objects, every subscription is associated with an Azure AD tenant that provides administrators the ability to set up role-based access control (RBAC). When designing a subscription model, one should consider the deployment boundary factor, some customers have separate subscriptions for Development and Production, each one is completely isolated from each other from a resource perspective and managed using RBAC.

More Info: Azure RBAC

Subscription Limits

Subscriptions are bound to some hard limitations. For example, the maximum number of Express Route circuits per subscription is 10. Those limits should be considered during the design phase, if there is a need to go over those limits in particular scenarios, then additional subscriptions may be needed. If you hit a hard limit, there is no flexibility here.

More Info: Azure Subscription Limits

If your Azure subscription is part of an Enterprise Agreement, please check out the following document to find out more about subscription/cost management considerations: EA Onboarding Guide

I have seen a mix of those approaches out there, but most large customers I have interacted with, primarily create subscriptions for the different environments (Dev/UAT/Prod) and then control access using resource groups and RBAC. I have also seen some customers creating different subscriptions to host resources that belong to a particular project which are isolated from the Dev/Prod environment, this way, they can control access and track costs for that particular project.

2 - What is the best strategy for creating resource groups?

There are mainly three things to consider here: Resource groups (RGs) can be used for RBAC, Automated Deployments, and Billing/Monitoring purposes.

RBAC

From an RBAC perspective, RGs are like OUs in Active Directory, they are a container for resources and can be a scope of RBAC for delegation purposes. Here is an analogy between AD and Azure:

[caption id="attachment_186" align="aligncenter" width="379"] AD/Azure Analogy[/caption]

 

One possible scenario is to group resources that are managed by a common team together. Example: Some customers create RGs for infrastructure resources like domain controllers, virtual networks, file servers, storage accounts etc., then delegate access to the infrastructure team to manage that RG. Note that RBAC can also be scoped at the resource level, therefore, there is flexibility here.

Automated Deployments

RGs are also deployment boundaries from an automation perspective. Consider a multi-tier application with Web, App, and DB tiers, when deploying all those tiers in a resource group, it is possible to automate the entire deployment of that application by generating an ARM template from the resource group. The entire solution could then be redeployed later in an automated fashion, this is probably the most important factor to consider since one of the major benefits of the cloud is agility/scalability with automation playing a key role here.

More Info: Export an Azure Resource Manager template from existing resources

Billing and Monitoring

Although there are more efficient methods for billing and monitoring i.e.: Billing API / OMS, RGs can also be used to display resource costs and for monitoring purposes by setting up metrics and alerts.

3 – Do I need a naming convention strategy?

Absolutely! - I find that this one is often overlooked. Let me tell you that defining a naming convention strategy is as important as the other topics discussed above. Once the number of workloads in an Azure subscription grows, a lot of the management tasks will be performed via command line interfaces like CLI and PowerShell, in addition, deployment using automation becomes key to unlock the agility/scalability benefits that Azure offers. Automation is made a whole lot easier with a naming convention strategy in place, some customers even use naming convention to pull billing reports based on a number of criteria.

More Info: Azure Naming Conventions

Summary

This should get you started and pointed in the right direction, it is important to note that there is not a one size fits all strategy or strict best practices, large customers I that have interacted with, use a combination of the strategies outlined above. In a future post, I will talk about how to take control of your Azure resources with things like tags, resource groups, and resource policies.

Comments

  • Anonymous
    November 12, 2017
    Great article! Thnx
    • Anonymous
      November 15, 2017
      Thank you, John.
  • Anonymous
    November 13, 2017
    IMHO now that we have Resource Groups and Tagging the only reasons for multiple subscriptions are: 1) Exceeding a subscription limit or 2) Having to include MDSDN subscriptions for a development environment and Production environments in the architecture.
    • Anonymous
      November 15, 2017
      For the most part yes, one should try to minimize the number of subscriptions whenever possible, however, Very large customers with complex billing and segregation of duties requirements will sometimes create different subscriptions to meet those requirements.