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
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.
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.
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.