So many subscriptions in your Azure cloud environment; why is that?

Solution-based approach

Subscriptions provide a management boundary for governance: they are the boundaries you assign with Azure policies. This is necessary because solution lifecycle management and authorization can vary. By using subscriptions, you can group solutions together and subscript them with appropriate security configurations.

But the Subscription Democratization design principle does more than just align subscriptions. For example, the principle also raises awareness about cost management. It is possible to group solutions based on costs. For each subscript you then have control over the costs with budgets. Because the standard Microsoft account is also grouped by subscription, complex calculations for more insight and/or charging are unnecessary. Application teams can assess their usage and take proactive action to reduce unnecessary consumption of Azure Services.

Attention!

Tip

Outbound traffic (egress) from a subscript has a cost associated with it. This also applies to traffic between two subscriptions residing in Azure.

Therefore, make sure to balance the amount of subscriptions, also because subscription models are cost-driven in many cases. This is why solutions are often set apart in separate subscriptions. Does a high degree of data exchange take place between subscriptions? Then you can choose to put the applications into one subscript.

Various forms

There are several contractual forms of using subscripts:

• Traditional contract: monthly, automatic payment by credit card from your organization directly to Microsoft.
• Microsoft Customer Agreement (MCA): contract from your organization directly with Microsoft for x number of resources. You don't pay by credit card, but receive a monthly bill.
• Cloud Solution Provider (CSP): a cloud solution provider (such as Centric) completes the subscription for you as the client organization. They then switch with Microsoft for you and send you the bill. This allows additional services to be combined on one invoice.

Often organizations start with the traditional contract form, then move to MCA. With CSP, subscription management is also assigned to the provider. This form is often used when applications are developed by the cloud solution provider. Then that subscription becomes CSP.

Requirements for new subscriptions

The following principles provide guidance in determining the requirements for new subscriptions:

Management boundary

Subscriptions provide a management boundary for RBAC (Role Based Access Control), which allows for clear separation. For example, different environments for development, test and production are often isolated from a management perspective. In a development environment, a broad group of users may make changes, where in a production environment this is more restricted.

Policy boundary

Subscriptions serve as a boundary for governance allocation. For example, secure solutions often require additional policies to meet requirements. Consider requiring encryption in production environments. You can apply these additional policies on a per-subscription basis. For example, development environments may have more lenient policies than production environments because of data guidelines.

Scaling limit

Azure resources are limited on a per-subscription basis. Using subscriptions as a scaling limit prevents running into limits when new applications are brought into Azure.

Subscription Democratization

Tip

In the CAF, Microsoft calls the architecture of separating applications (or solutions, as Microsoft calls them) using subscripts "landing zones"

As you have read, Subscription Democratization is an important topic. There is a reason it is the first design principle from the Cloud Adoption Framework ̵ give it the attention it deserves!