How Many Azure Subscriptions is enough? aka.ms/Azure/Subscriptions


How many Subscriptions is enough?

Comparative Anatomy of Forests to Subscriptions

This question come up too often and so it's time to share findings from my experiences and  many of my colleagues' at Microsoft.  While one key point to make is that "there is no magic silver bullet", the discussions here are similar to our first talks about how many Active Directory Forests should you have? In BOTH cases, simpler and fewer of either forests or subscriptions is easier to manage.  While conversely, the more you have of either, the more complexity and difficulty you will have in managing them. However, one important distinction to make with this analogy is with regards to Security:

  • With Active Directory, the security boundary IS the forest
  • With Azure, the security boundary is NOT the subscription, but the Azure Active Directory Tenant.

I tell my customer, let's learn the lessons of many organizations in the past that went crazy with multiple domains and forests ...only ending up later after much pain and administrative suffering, to undo it all and reduce/consolidate domains and forests to a few, if not only 1.  This should be the end-state goal you should start with for determining the number of subscriptions.  Ask your organization, can we start with 1?  And if so, what would be the justifications for adding additional subscriptions?

Criteria for adding subscriptions

The graphic below is like the "Project Management Body of Knowledge" in that this is simply a framework, and not carved in stone.  Feel free to disagree and challenge it, but please just don't tell me you need dozens of subscriptions, unless you can really justify them all.  Let's keep this simple.  CAVEAT EMPTOR: The following decision criteria assume a single organization and does not take into account mergers, acquisitions and divestitures.  That could be a entire separate blog on those possibilities.

Subscription Decision Criteria

Subscription Limits

This is the MOST likely and common clear cut justification for needing another subscription.  If any of the subscription limits will be hit now or in the near future, plan for another subscription now, and ward off the future troubles  having to move resources from one subscription to another.  While it is much easier to do this now, than in those dark days of ASM, prior planning is your friend here.

As a result, the place we don't want to be impacted in, is production. So many companies will just figure the wild west of development and testing could eat up valuable limits needed for production resources. The beginning state for many companies is to start with one subscription for production and then a second subscription for all non-production e.g. Dev, Test, and QA. An augmented version of this safety net is that we hear many customers that have a third "sandbox" environment where any thing goes.

Subscription Security

With Role Based Access Controls (RBAC) we can scope administrative access at

  • any subscription
  • any resource group
  • any Azure resource

However, when we go back to our comparative anatomy analogy above with Active directory, subscriptions have an all powerful equivalent to the old Enterprise Admin of Active Directory.  This is the subscription owner which inherits rights over every azure resource within your subscription.  How much do you trust that person(s)?  That is a lot of power holding the keys of the subscription kingdom! But, there are methods to protect that top level right, such as breaking up the password parts or other factors to be accessible only by different people.

Azure Resource Manager (ARM) was designed for this delegated administration barrier that existing only a few years ago, when our only scope of administration over Azure resources was just the subscription.  We built this new ARM model.  You just have to use it...  AND enforce it. It is a new way to administer and control resources versus traditional on-premises systems, but embrace it and leverage RBAC. And now that we have Azure PIM for RBAC in preview, this will make many security officers very happy.

Limit Resource Providers

Registration of Resource Providers enable features to be available to users in the portal. To register a resource provider, you must have permission to perform the /register/action operation for the resource provider. This operation is included in the Contributor and Owner roles.

In many cases on our projects, we provide a script to simply enable all resource providers so it is done.  This scenario of a different subscription with different resource providers lit up is not a common one. But we'll call it a possibility.  It could be possible to have a subscription with limited services, like production, and then another non-production or sandbox environment with everything turned on.  Not something we see or do often at all, but just wanted to put it on the table.

Delegation of Administration

As I described above, RBAC can really break down and control access to resources to manage least privileges.  Stuart Kwan at Ignite 2017 had a great talk on Identity (Locking Down access to the Azure Cloud...) and made this simple graphic to show how RBAC should be applied.

With all of Stuart Kwan's ultimate words of wisdom, there will be some who want further delegation like we did with nested organizational units in AD.  But I ask you "was that really easier and simpler than a more simple flat hierarchy"?  I've seen that model go more crazy than the numbers of forests gone mad, so I am not a fan of making additional subscriptions just for another administrative container to fake nesting of administration.

The best possible argument I think goes back up to the subscription owner and who do you trust. Remember our other security tenant above is that the Azure AD tenant and NOT the subscription, is the security boundary.

Conclusion

Again, there is no magic bullet.  But now you have some criteria to review and decide. And these criteria can be used also to reduce or condense the number of subscriptions you have.  So what if you do have a half a dozen or more subscriptions...what do you do?  I would say review the criteria above.  If possible without a lot of pain, consolidate and eliminate those subscriptions that are not necessary.  Apart from the first few criteria above, we typically see or recommend 1 subscription for production and 1 for non-production and or a sandbox environment.  There are exceptions, but these are guidelines and not cast in stone.

Recommended Reading

Comments (4)

  1. Adam Caulkett says:

    Great considerations… it’s all relative though, you cannot operate a enterprise on a handful of or Subscriptions. Most models will result in a high number which then requires some sort of process which ‘enables’ (governance) new Subscriptions in your estate, as they are created.

    1. mzbowe says:

      Since I have posted this, I have had many conversations with consultants and Architects delivering many large enterprise Azure deployments. We are seeing a fairly common pattern. 1. Prod Subscription 2. All Non-Prod subscription e.g. including dev, test, qa, etc and very optionally 3. Sandbox anything goes….which could be users’ MSDN subscriptions. The N+1 model is still valid in even large enterprises. One of the largest retailers in the world uses this approach. To the rationalization of #2 above, this is a safety net to protect the cowboys/girls from hitting some limit erroneously from some crazy test, that may impact production. And for this, within the EA portal, there is a special “Dev/Test” switch to check which will let you make that subscription and save lots of money!

      At the end of the day, I won’t lose sleep over a couple or even a handful of subscriptions. But when a company says they want one for every application, I must ask…..Really? Are you sure? So, I went to my mothership, MSIT and asked “what are you doing? Interesting approach. Because of the size and nature of Microsoft having many product groups and divisions all wanting to play in the cloud, here was the answer. We often use “Umbrella” subscriptions. This is similar to the “Non-Prod” subscriptions. Just a grouping of things. For example (only a made up one) let’s say the Office 365 team wants their own subscription to test their apps, so they make an O365 Umbrella subscription. Or in your world, maybe their a similar groups of complex applications that we want to group together, make an umbrella.

      My most recent very large scale enterprise designs have actually made this pattern for compliance reasons (Defense Contractors): 4 Total subscriptions – 1 Prod + 1 All Non-Prod each in Azure Commercial. Then repeat in Azure Government to meet FedRAMP High requirements.

      The conversation I have with many is …at the end of the day, what really separates such environments? In an on-premises world how is production different from a non-production environment? I see it as two fundamental things: Identity and Networking. If I had only 1 subscription with RBAC I can absolutely segment rights to who does what and where in Azure with RBAC. Likewise, even within one subscription, I can logically separate out networks that cannot talk to each other with Virtual Networks. And if they do need to talk or we need to control traffic I can do that as well. Two Virtual Networks within one Subscription works the same from a networking perspective, as 2 subscriptions each with a virtual network. The difference being in the latter, you have more subscriptions.

      In summary of this novella response, I would say that for the majority of most small and medium sized organizations, that 1 subscription is likely enough. For large Fortune 100-ish companies, 2 will usually do well, with the N+1 considerations noted in this blog. And even with limits, in some cases by the time all of your resources are deployed, the limits may go up! Because if you and other customers are hitting them often, we are hearing about it. And we want to help full-fill your demand. So check the limits often. aka.ms/Azure/Limits

  2. Hey mzbowe, Great article! congrats!
    Can we consider the control of billing as a possibilities to create another subscription? I know there are tags, but could be a possibilite.
    Thanks,

    1. mzbowe says:

      Using a subscription just for another billing possibility does exist. But with tags, really not necessary. And now with CLoudyn, it can do that slice and dicing much better using the tags!

Skip to main content