Azure governance
Azure governance is a combination of different Azure services and capabilities, allowing for the management of all your Azure resources at scale and following control guidelines. Azure governance works across multiple subscriptions and across resource groups, and is based on a combination of Azure identity, Role-Based Access Control (RBAC), Azure policies, and management groups. You could extend the concept with Azure Resource Graph as well. Some customers also consider cost control as part of governance processes and best practices. If your organization has a Security Operations Center (SOC), this department will most probably take ownership of this process, or at least (should) be hugely involved in this.
Let me describe each of the different Azure services, allowing for governance.
Management groups
For a long time, an Azure subscription was considered the boundary of management and control. This allowed organizations to use multiple Azure subscriptions to "separate" resources from each other. Some organizations subscribed on a geographical level, some others used a dedicated subscription for a specific application workload, and others still separated based on dev/test and production.
This model changed recently, with the introduction of management groups (Figure 5). Where Azure Policy and Initiative were (and still are!) really great sources of governance control, they were linked to a single Azure subscription, which was hard to manage in larger Azure environments where admins wanted to replicate policy settings across multiple subscriptions. That's exactly what Azure management groups provide: a cross-subscription assignment of Azure Policy and Initiative.
Figure 5: Azure management groups
Identity and role-based access control
Again, identity is key in a public cloud platform like Azure. The examples we saw earlier should already make it clear, but there is yet another example I can share: Azure itself heavily relies on RBAC to identify who can do what in the platform.
This "who" can be a user or group from your Azure Active Directory, a user from another Azure Active Directory tenant, or a registered application or service principal.
RBAC in Azure offers more than 75 different roles to choose from, and if you cannot find the specific role mapping for the particular need of your organization, you can create your own custom roles from Azure PowerShell as well.
Azure Policy
Another source of control is available through Azure Policy. This is a true governance management and control mechanism in Azure. As an organization, you define Azure policies: JSON files in which you specify what Azure resource requirements you want to enforce before the deployment of Azure resources can succeed. For example, there is forcing the usage of certain Azure regions because of compliance regulations, or allowing only certain Azure virtual machine sizes in your subscription to keep costs in control, or perhaps you might have certain naming standards you want to enforce for Azure resources, optimizing your asset management and CMDB regulations. One last example of something that a lot of companies find useful is enforcing the use of tags. A tag is like a label that can be attached to a Resource Group or individual resources, for example, a cost center or business unit. It is mainly thanks to these tags that an Azure billing administrator can get a clear view of what an Azure resource is used for, or at least to which business unit or cost center this resource belongs.
Azure policies can be grouped together into so-called Azure policy initiatives. This helps in enforcing several policies at once. After the Azure policies and policy initiatives are defined, they need to be assigned to a scope. This scope can be an Azure subscription, an Azure resource group, or individual Azure resources.
Azure Blueprints
Another mechanism available in Azure today for helping in governance control is Blueprints. Azure Blueprints (Figure 6) allows cloud architects and IT teams to define a structure of reusable, repeatable instructions for deployment and configuration, in compliance with company standards, regulations, and requirements.
Relying on a combination of roles, controls, and infrastructure as code, Azure Blueprints orchestrates the full deployment life cycle of Azure resources.
Figure 6: Azure Blueprints
Blueprints are based on artifacts, which are a collection of settings, parameters, Azure infrastructure as code deployment templates, and policy templates.
Naming standards
Another critical aspect of your migration strategy to a public cloud such as Azure is having a good understanding of the naming standards. Everything in Azure is based on Azure resources. Several of these use dynamic names that you cannot change. Other services are deployed in a fixed namespace domain (azurecri.io for Azure Container Registry, blob.core.windows.net for Azure Storage Account blobs, azurefd.net for Azure Front Door, and so on).
Next, several Azure resources have requirements (and limitations) around the usage of certain characters, capitals, and/or numeric values and complex characters.
There is good documentation available on this exact subject:
Resource groups
Another item I want to touch on as part of the pre-migration information is resource groups. While it's not that hard to understand what they do—they are groups of Azure resources—there is a lot of confusion around them, specifically regarding how to organize them, or how to organize your resources into them.
As a starting point, it is really up to your organization. Microsoft is not enforcing what resources should go where and how you want to organize your resource groups (with some exceptions). Some organizations have a resource group per workload; others define Resource Groups based on resource types (a Network Resource Group, a Storage Resource Group, and so on). An example of this approach can be seen in the diagram in Figure 7. This could help in allocating RBAC, keeping the same layered structure as their on-premises datacenter. Other organizations use geographical datacenter locations as a guideline (West-EuropeRG, East-USRG, and so on).
And touching on the topic of Resource Groups and Azure resource locations, specifying the location is a hard requirement for any Azure resource, as most resources on the platform are region-specific. Complexity arises when you have a Resource Group in one location containing resources in a different location. While technically fine, this might cause interruptions when the Azure region that the Resource Group is in is not reachable anymore. The resources would remain (for instance, a virtual machine would still be running), but you wouldn't be able to make any changes to the virtual machine (as the information metadata cannot be written to the Resource Group).
Figure 7: Azure Resource Groups
It should be clear now that identity and control are important topics to tackle before starting the actual migration (or deployment) of your business workloads on Azure.
By aligning the cloud architects with business needs, granting the correct roles and permissions, optimizing cloud security by using Azure identity features such as Multi-Factor Authentication (MFA), conditional access, privileged identity management, and Azure identity protection, you can dramatically optimize your security in the cloud. In most situations, that immediately means that you will also optimize the security of your on-premises datacenters, so this is a true hybrid-cloud benefit.
Azure Resource Graph
While not specifically built as a governance service, Azure Resource Graph can definitely help in getting a better view of the Azure resources an organization has deployed. Resource Graph is a service in Azure designed to provide a fast and easy-to-manage way to explore all resources within a single subscription, or even across multiple subscriptions.
Azure Resource Graph allows you to run filtering queries, narrowing the results of what you are looking for.
While Azure Resource Manager also allows you to gather filtered Azure resources, this is starting from the resource providers individually. If you want to get a view of Azure virtual networks, you would "call" the Network Resource Provider. Then, you would connect to the Virtual Machine Resource Provider to get information about your virtual machines.
Azure Resource Graph does this differently, and in a way that allows you to gather information across all those resources, without touching on each and every resource provider individually.
Figure 8: Azure Resource Graph
A result of this by using the Azure portal is shown in Figure 8. Besides the Azure portal, Resource Graph can also be used from Azure PowerShell and the Azure CLI, using the powerful and fast KUSTO query language.
Cost control and Cost Management
One last item that perfectly fits into the topic of Azure governance is Cost Management. Microsoft recently acquired Cloudyn, a multi-cloud cost reporting tool. The Cloudyn service enables any organization to pull up detailed dashboards, exposing cost consumption for any Azure resource or group of resources, based on resource type, region, or tags attached to the Azure resources itself.
Microsoft has now completely integrated the Cloudyn experience into the Azure portal, under a specific service called Cost Management, providing you with reporting dashboards (see Figure 9); there are several options for you to choose from.
Figure 9: Azure Cost Management – cost analysis
Another recently released Cost Management feature is Cost Budgets. This is a soft setting, allowing you to define a ceiling of cost consumption for a certain Azure resource or resource group. Once the budget amount (or any percentage, such as 80%) is reached, Azure administrators can view a dashboard report of the results (see Figure 10) or receive an alert notification by email, for example.
Keep in mind that the budget feature is not stopping Azure consumption as such, and nor will the Azure resource be deleted, but it is at least a useful aid in cost governance.
Figure 10: Cost Budget
Section summary
In this section, we guided you through several Azure governance services and capabilities you can deploy in your Azure subscriptions. Starting from Management Groups, allowing you to scope policies to multiple subscriptions at once, you learned about Azure policies and Azure Blueprints. We also talked about Azure identity as a governance mechanism, providing RBAC. In the last part, we covered the new service, Cost Management, as another governance instrument.
You now have a good understanding of the foundational layers of your cloud migration. Let's take a look at some of the migration tools and processes Microsoft has available today to help smooth this operation.
