Choosing the Correct Azure Subscription Model
In this article on Microsoft Azure subscriptions, I will explore the different subscription models available in Azure and provide insights on subscription design considerations from my experience working with different organizations on Azure migrations.
There is no one-size-fits-all approach to Azure subscription design and Microsoft has created a flexible deployment model with Management Groups to account for this. Management Groups provide a way to effectively group subscriptions into logical hierarchies and apply consistent policies to them. Polices are inherited down through the subscriptions under the Management Group. When implementing Management Groups, it is best to consider both technical controls and organizational structure to benefit from it. For example, if certain apps and data require strict security controls or access controls, then group those resources into separate subscriptions under a management group defined for that purpose. Other systems and apps can therefore be placed under a different Management Group structure with different Azure policies applied. This is one example, but in my experience, it has proven to be effective and manageable.
Let’s explore the factors in more detail that can influence subscription design. In my experience, it is best to divide them into two categories: technical and organizational.
Technical factors can include the following:
· compliance / regulatory requirements
· access control
· data protection
· mission critical apps / large apps that can consume many resources
Organizational factors can include the following:
· Functional (sales, IT, Finance)
· Business Unit (division, profit centers)
· Geographic (multi-regional orgs)
· IT department organization
Technical requirements can influence subscription design mainly to separate apps and data from other resources. For example, if your organization is subject to Payment Card Industry (PCI) data requirements, then the resources that are used in PCI systems can be separated into different subscriptions to isolate them from non-PCI systems. This allows the organization to apply special Azure policies or other controls to that subscription to comply with PCI mandates. Similarly, if resources require special access control, they can be separated into different subscriptions to ease the RBAC controls over them. Sure, one could argue that this can be implemented with resource groups, but this can become difficult to manage if there are many resource groups. It’s somewhat easier and cleaner to just put these resources into their own subscription and then allow access at that level. As I said, this can be argued, but I have seen both models and would stand on the side of using a separate subscription in these cases. It is also a common best practice to separate subscriptions to account for different environments such as development, pre-production, and production. It would be foolish from a management and compliance standpoint to have any non-production resources alongside production resources! Finally, some systems in enterprise scale organizations may be so large that they bump into the various subscription limits and quotas that Azure imposes on resources. Yes, these limits can be increased in most cases with a simple request to Microsoft, but it is something to consider.
Organizational requirements or structure can also influence Azure subscription design. It is common to see subscriptions delineated for functional areas of the organization, such as sales, IT, and finance. This structure makes it easy to define the subscription model as it directly follows the organizational structure, but technical requirements should also be considered as well. If the organization spans the globe, then consider implementing subscriptions in the different geographic regions where the organization operates. This is especially important when organizations need to comply with specific regulatory requirements such as GDPR.
Lastly, let us not overlook IT department structure when implementing subscriptions. In my work, I have seen organizations that only have a few people in the IT department and those people support and manage all the IT assets. In this case, it makes sense to consider having a small number of subscriptions (perhaps non-prod and prod) for apps and data because it is the same group of people managing it. As stated before, regulatory requirements may change that, but it will be a burden for a smaller organization to implement many subscriptions in my opinion.
The approach to subscription design for a larger organization is usually more involved, so the multi-subscription model can be implemented where apps, data and access controls dictate the subscription and management group design. For example, I have seen multiple management group structures across dev, non-prod, and prod subscriptions and geographic regions. I have also seen an enterprise customer deploy one subscription per application. This is crazy you say! In this case, using one subscription per application worked because each application was managed by an individual team. (In fairness, there were a few applications managed by the same group, but the apps were still placed into separate subscriptions.) This example highlights how flexible management groups and subscriptions can be in Azure, but it also highlights the necessity of careful thought and planning before implementation. This goes without saying though. The picture below from Microsoft shows one example of subscription implementation. I hope it makes more sense now.
I hope you found these points useful as you think about your company’s cloud journey. Until next time, please stay safe, and have a great week!
