Most articles on docs.microsoft.com discuss an “Azure Subscription”. But look closely and you’ll find a few where the URL will hint that billing traditionally had a big role within the subscription world. Take for example: https://docs.microsoft.com/en-us/azure/billing/billing-subscription-transfer.
All resources in Azure are linked to precisely one subscription, which is the one where the component eventually gets billed. That makes the financial aspect the first reason why you might want to think about having one subscription vs having multiple. But there are more reasons we can think of, for example:
- Separation of costs between production, staging, test and any other environments your landscape might require.
- Separation of costs between services or applications.
- Separation of costs based on the org diagram (per department for instance).
But… using resource groups and tagging would also allow you to split up your bill. So using separate subscriptions wouldn’t be technically required for these purposes. The one and only exception is payment itself; since your subscription is probably linked to some credit card and using multiple cards would require multiple subscriptions. But having multiple subscriptions might bring you more advantages, which we’ll discuss in this article.
The default way to look at subscriptions is related to billing.
One thing to consider is one of the magic words from the world of IT: governance. In short: being in control. Probably not the best definition, but for this article it’s sufficient. As noted; a subscription is a container for all of it’s resource groups and thereby all of the resources in those groups. There is nothing that spans subscriptions and subscriptions cannot be nested. Critics might note: an Enterprise Agreement (EA) spans subscriptions. It does, but this is really just a billing thing and has little impact on governance.
So how does having subscriptions help your governance?
- A subscription one or multiple owners and allows you to hand out specific permissions. These are specific to the resources in the subscription, so there is no overlap with other subscriptions. So when controlling access to your resources, a subscription might be an option. For instance; consider the scenario where an enterprise has multiple partners which help them with management of different chunks of Azure resources. Giving each one a specific subscription to manage might reduce the risk of incorrect permissions.
- The same applies to companies who work in an agile way and have DevOps teams running the show. You could consider granting every team its own subscription. That helps to keep track of the costs that every team makes, and also gives the team the freedom to do whatever they need to do within that specific subscription, not risking touching the resources of other teams. You might regard this a separation of concerns.
- You might argue: I can perfectly do role based access management within a subscription and create the same separation. This is mostly true. A few things are managed on subscription level, so not everything can be split that way. On the other hand, a role based access control (rbac) scheme is nice, but we all know how difficult it is to really enforce all of the rules you set. This is especially true in the world of agile where you do not want policies to be hindering the effectiveness of your teams. A more ‘physical’ barrier like a subscription sometimes just works more effectively.
- A subscription is linked to an instance of Azure Active Directory. Multiple subscriptions would give you multiple directories which could, for instance, be used to house the service accounts and SPNs required for your application or service. A centralized and centrally managed subscription would house the ‘main’ Azure AD which can then be used as just an identity provider. Again: separation of concerns. This does bring a little bit more costs when it comes to managing all these separate instances of course.
So did you decide yet what you’re going to do? Ok, let’s make it a bit more difficult then :) As I already hinted: pretty much all of the above can also be achieved in other ways. You can create specific resource groups and assign permissions for your DevOps teams to just those groups. Tagging can be also be used to split out the bill and help with governance. But in these cases, you will also need a more strict management of those subscriptions to ensure your policies are being used in the right way.
One last thing to consider, and maybe one of the simplest reasons to use multiple subscriptions: the technical limitations of having one single subscription. Each subscription comes with a set of technical limitations. In most cases you probably won’t run in to those, but there are definitely edge cases where you might. The limitations are covered in the following article: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits. Take those into account when plotting your Azure landscape and the apps / services you want to run in it.
You might have seen this one coming: there is no advise that applies to every situation. As often: “it depends”. But still, we can give this bit of advise: at least have an approach to subscription management before you deep dive into Azure. Rearranging resources is not always an easy task. In some cases you might be forced to recreate things not being able to reuse the names you’ve already used, which can be painful. Making a choice and sticking to it is in this case just as important as the actual choice you make.
From our experience at our customers, we’d love to share the following tips:
- Creating separate subscriptions for lifecycle stages (test, staging, production) brings little benefit. It complicates management and for these cases, roles and tagging are more than sufficient to separate the concerns. When it comes to costs, in the end you probably care most about the total cost of ownership.
- When picking a strategy, take a close look at how your organization is structured. A DevOps team which maintains a number of applications would provide a logical boundary on which to base a subscription, giving them the freedom they need. In more traditional organizations you might consider linking a subscription to a department or specific business domain.
- Map out your governance in advance. Which roles do you have and who needs access to which resources? What reporting needs do you have? Again: everything it an option, but picking the right foundation might give you more things out of the box without the need for tagging or complicated role management.
- Choose wisely and early on. Many times we come across situations where the choice was not made, or made too late. That brings you to a position where your cloud environment already has some “legacy” stuff in it which doesn’t comply with the policies you created later on. Delaying a good approach to subscription management will eventually come back and bite.
- Don’t overdo it. Too much policy and separation will get in the way of effectiveness and getting things done. You’ll want to make sure that at least all resources for a service or application are within the same subscription.
All pathways lead to Rome, so pick a road that suits your organizations lay-out and management style. And if you’re having trouble doing so; get a partner on board which can provide you with some advise and a second opinion. If you want to read more about this topic, check out the following article where Microsoft engineers explain how they themselves are handling their subscription management. Spoiler: they don’t have a single subscription for the entire company ;) https://azure.microsoft.com/blog/organizing-subscriptions-and-resource-groups-within-the-enterprise/.