Azure Governance Part 2: Using Subscriptions and Resource Groups as Building Blocks

This is part two of a four-part series on Enterprise Governance in Microsoft Azure.

Many of my clients have learned the hard way that getting out in front of cloud adoption with a sound governance strategy is a key step that should not be overlooked. Often organizations will dip their toe in the waters of cloud adoption by putting development or test workloads in Azure as a sandbox. But then word spreads about how quick and easy it is to leverage PaaS features or provision IaaS resources in Azure and before they know it the horse has left the barn. It is much harder to apply governance principles to an existing home grown environment than it is to a pristine greenfield environment. This blog post will focus on the guiding principles behind dividing resources into resource groups and/or subscriptions.

In part one, we discussed the four levels of management in the Azure Enterprise Portal: the Enterprise Agreement, departments, accounts, and subscriptions. Once you have modeled your organization’s hierarchy and mapped it to an Azure hierarchy pattern, you can consider where to draw the line between subscriptions and resource groups based on your governance needs.

Subscriptions

There can be multiple Azure subscriptions within an Enterprise Agreement. Subscriptions can be created through either the Enterprise Portal or the Account Portal. Through the Account Portal, the account administrator can rename the subscription or reassign the service administrator to another user. Also at the subscription level, if additional full admin-level users are required for any reason, service administrators can log on to the Classic Portal to add co-administrators, who cannot access the Account Portal but otherwise have full access within the subscription. In Azure, the ability to view resources is segregated at the subscription level. Billing for Azure consumption is also reported at the subscription level.

Resource Groups

Azure Resource Manager introduced the concept of resource groups as a more robust and flexible way to deploy and manage resources in Azure. Resource groups serve as containers for Azure resources within a subscription and are a flexible way to define resource lifecycles, policies, and access control. Resources can be allocated to resource groups using different deployment models, depending on the needs of the organization. Applications are commonly segregated into resource groups because they share a common lifecycle of being provisioned, updated, and decommissioned. The newer Azure Portal also allows role-based access control (RBAC) for more fine-grained access in Azure Resource Manager deployments. RBAC can be applied at the subscription level to be inherited by resource groups, or to individual resource groups for more granular delegation.

When To Use Subscriptions Or Resource Groups

The decision of whether to divide resources into separate subscriptions or resource groups often takes billing and departmental chargebacks into account, as well as the overall management structure of the organization. A common functional hierarchy pattern includes pre-production environments assigned to application development teams within functional groups (e.g., accounting, HR, etc.) and production environments assigned to an IT engineering group. Business unit and geographic patterns may divide subscriptions between account holders within discrete business units, subsidiaries, or regions, with application owners and IT engineering teams assigned granular access within each subscription. Common reasons for dividing between separate subscriptions, rather than resource groups within a single subscription, are department groupings on billing statements, grouping resources into silos, separating access control between environments, and limiting access to services only available in the Classic Portal where RBAC does not apply.

From a cost management perspective, the Enterprise Portal offers significant insight into commitment usage and charges at department, account, and subscription levels. In addition to the reporting directly visible in the portal, you can download detailed usage reports with configurable date ranges, view your organization’s full Azure price sheet for creating plans and projections, and you can also import your consumption usage into Power BI to perform deeper analysis. Power BI allows you to drill down further to identify trends as well as build dashboards and shared reports. With these more advanced capabilities, you can get a better idea of how closely your usage is aligned to your budgeted commitment to make more informed business decisions, such as raising or lowering spending limits applied to various departments. These billing and reporting capabilities should influence planning of whether to place items into separate subscriptions.

Planning Resource Groups

Once you have taken billing and administrative factors into account to devise a subscription strategy, then the next step is to plan an approach to resource groups. When deploying resource groups, there are two primary approaches to their design:

• Resource groups that encompass all resources and core infrastructure components for an application deployment, including storage accounts, virtual networks, subnets, VMs, web apps, load balancers, etc.

• Centralized resource groups for core components such as storage accounts and virtual networks, with application resources such as VMs, web apps, load balancers, etc., set up in their own resource groups.

The centralized approach makes it easier to build and maintain hybrid network connectivity, protect data sovereignty, and enforce compliance requirements within the environment. Both “traditional IT” and “agile IT” workloads can be designed on top of the centralized resource group approach. “Traditional IT” workloads tend to be organized by overall application or system, when those resources share a common lifecycle. “Agile IT” workloads tend to be organized by layer (e.g., web tier, app tier, etc.) to support deployment lifecycles. With the centralized approach, application teams are empowered to develop and implement solutions efficiently while minimizing risk and optimizing the use of shared infrastructure. The alternative approach requires each solution to maintain its own core infrastructure and virtual networks, introducing additional management overhead and greater potential for conflicts.

Bearing these factors in mind, it is important to consider how they will apply to your organization, because ultimately any governance model will need to reflect the company’s strategic, compliance, and budgetary goals and requirements. Starting with sound governance principles to guide separation of resources into subscriptions and resource groups can prevent costly reorganization efforts later. After establishing this critical framework, the next step is to establish guidelines around RBAC, ARM policies, and auditing within your subscriptions. We’ll discuss these topics in part three of our series.

Need Help?

Are you interested in exploring Microsoft Azure but concerned about governance and how to make public cloud fit within your IT model? Credera has extensive experience in cloud infrastructure design and implementation. If you have questions or would like to discuss cloud and infrastructure solutions, contact us at sales@credera.com.

• Microsoft Azure
• Strategy
• Cloud
• Enterprise Governance
• Resource Groups
• Cloud Adoption