DeepDive: Azure Subscription Model

Before we dive into the ideal structure, let’s start with what a subscription exactly is and what it means. An Azure subscription is an administrative entity in Azure that Microsoft introduced to allow for more segmented billing as part of a single Microsoft tenant (Enterprise Agreement, Cloud Solution Provider, Pay-as-You-Go). Besides the billing, and therefore cost management, a subscription is also a natural boundary for many other more technical components. First, every Azure subscription has its specific Identity and Access Management configuration, allowing different permissions per subscription. Second, most resources cannot be stretched over subscriptions. Last, Microsoft applies limitations on many resources at a subscription level, limiting, for example, the number of cores that can be deployed. Before Microsoft introduced Management Groups, subscriptions were also the highest administrative units on which resources could be segmented. Now that everyone is on the same page, let’s focus on creating a proper subscription structure for you.

Through working with Azure for several years, I have seen different subscription models applied and many Azure environments growing out of control. In many cases, when a single or only a limited number of subscriptions were used, the governance over these environments was challenging. Architects, IT Managers, and CIOs expressed that they did not get a grip on the Azure environments. Cost control was a major point of concern. Especially when subscriptions contained thousands of Azure resources, managed by different internal and sometimes external teams, all control was lost.

So, what is my vision for a good subscription model in Azure? I believe in a high level of segmentation, granted that this does not have a negative influence on the application environment itself. By using Azure subscriptions, you can create a natural boundary on costs, IAM, security, and the components used for an application. Because you can create unlimited subscriptions inside an Azure tenant, there is limited to no negative implication of having multiple subscriptions. Every workload that is managed by the same application team and under the same cost center should therefore be deployed in its own subscription, with additional segmentation for the different environments of DTAP (Development, Test, Acceptance, Production). Aligned with the Microsoft Cloud Adoption Framework, these should also be isolated in different subscriptions.

In short, adopting this subscription strategy ensures the following advantages for onboarding any application to your cloud environment:

• Segmented costs increase the cost management capabilities of an application.

• Opportunity to apply IAM on an application basis, with the possibility to make this more specific using permissions at the resource group level.

• Possibility to split different functions of the application using resource groups, avoiding the use of resource-intensive tags.

• Ability to determine the security score for a specific application due to the security score on the subscription.

• Reducing the number of components in each subscription allows for easier management.

• Reduced chance of hitting the limits set by Microsoft on the subscription (cores, API calls, tags).

When this approach is chosen, the following limitations or challenges have to be considered:

• Due to the hard limits on cross-subscription components, every subscription requires a set of basic components and configurations before it can be used by application environments (network, key vault, backup vault, etc.). This does add some minor overhead to a new subscription.
• When resources are not in the same subscription, the physical distance could be greater due to deployment in different datacenters across a region, adding latency.
• Cross-subscription cost management for CSP contracts is not available as of now, which could require a third-party tool for proper cost management and FinOps.
• Network traffic across subscriptions is charged by Microsoft, which is something to consider when large data volumes are transferred over subscriptions.

Isolating resources in different subscriptions should not be a goal on its own. However, it does offer the possibility to create a foundation for governance. When we work with a customer, we typically use the decision tree, as shown below, to determine when a new subscription should be deployed for an application.