Microsoft Azure resource groups: Introduction and best practices

An Azure resource group is a Microsoft Azure service that requires grouping for all your Azure virtual machines (VMs). In this post, we’ll look into what this group structure actually means, and how you can use it for better governance and to better manage Azure resources for your infrastructure.

First, a brief overview of how you can manage and provision resource groups through the Azure Resource Manager—which you are probably familiar with—as it’s the management layer for your resources. With the Azure Resource Manager, you can manage your infrastructure through declarative templates rather than through scripts, tagging management, deployment templates, dependency mapping, simplified role-based access control and clarified cost management.

You can organize resource groups for securing, managing and tracking the costs related to your workflows and applications.

Azure resource groups are logical collections of VMs, storage accounts, virtual networks, web apps, databases and database servers. You can use them to group related resources for an application and divide them into groups for production and nonproduction, or any other organizational structure you prefer.

The Azure resource groups management model provides four levels, or “scopes” of management (link resides outside of ibm.com), to organize your resources:

• Management groups: These groups are containers to manage access, policy and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group. They are often used for grouping subscriptions by internal department or geographical region.
• Subscriptions: A subscription associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the number of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams or projects. Commonly, a subscription equates to an application. 
• Resource groups: A resource group is a logical container into which Azure resources like web apps, databases and storage accounts are deployed and managed.
• Resources: Resources are instances of services that you create like VMs, storage or SQL databases.

One important factor to keep in mind when managing these scopes is that there’s a difference between an Azure subscription versus a management group. A management group can’t include an Azure resource. It can only include other management groups or subscriptions. Azure management groups provide a level of organization above Azure subscriptions—for example, if a subscription represents an application, an Azure management group might contain all applications managed by that department. Also, there’s no structure for a “nested” resource group in Azure—to “nest” groups for permissions, you’ll need to use a combination of permissions at the different levels listed earlier. Be sure also to differentiate the concept of an Azure resource group from an “Azure availability set.” An availability set in Azure is a logical grouping of VMs to inform Azure how your application is built to protect the availability of your application.

There are several ways to create an Azure resource group:

• The Azure portal
• Azure PowerShell scripts
• The Azure CLI
• An ARM template

Here are some best practices for using Azure resource group:

• Resources in a group should have the same lifecycle. For example, if an application requires different resources that need to be updated together, such as having a SQL database, a web app or a mobile app, then it makes sense to group these resources in the same resource group. However, for DevTest, staging or production, it’s important to use different resource groups or a new resource group as the resources in these groups have different lifecycles. 
• Resources can be added to or deleted from an Azure resource group. However, each of your resources must belong to an Azure resource group, so if you want to move resources from one resource group to another, you must remove them from the original group and then add them to the new one.
• Not all resources can be moved (link resides outside of ibm.com) to different resource groups.
• The resources you include in a resource group can be located in different Azure regions, even in different regions than the group itself. However, sometimes, it’s a best practice to keep all resources in a resource group in the same region to reduce latency or cross-region data transfer. Regardless, the group needs a location to specify where the metadata will be stored, which is necessary for some compliance policies. 
• Grant access with resource groups. You should use resource groups to control access to your resources—more on access control later.
• When a resource group is deleted, all resources in the group are deleted. 
• You can deploy up to 800 instances of a resource type in each resource group —with some exceptions (link resides outside of ibm.com).

Ready to automate Azure resource group optimization?

Azure resource groups are a way to operationalize role-based access control (RBAC). Typically, you’ll want to grant user access at the resource group level —groups make this simpler to manage and provide greater visibility.

One of the top cloud best practices we recommend to CIOs is to give your organization a structure that supports your strategy. The way you organize your Azure resources then follows your organizational structure, making it straightforward to follow the principle of least privilege and only grant access to the minimum permissions needed—which you can do at the resource group level, rather than at the management group or subscription level. For example, a policy relating to encryption key management can be applied at the management group level, while a scheduled suspension policy might be applied at the resource group level.

Effective use of tagging allows you to identify resources for technical, automation, billing, and security purposes. Tags can extend beyond resource groups, which allows you to use tags to associate groups and resources that belong to the same project, application or service. Be sure to apply tagging best practices, such as requiring a standard set of tags to be applied before a resource is deployed, to ensure you’re optimizing your resources.

There are several common ways to organize subscriptions and resource groups. The first, unfortunately common, model is “chaos.” If this word describes your environment, don’t give up. We’ve seen many organizations go through these growing pains and wrangled their environments into working order.

Then, there’s organization by application. For example, a payroll or billing application would align to a single Azure cloud subscription, with resource groups for each environment—development, testing, staging and so on—rolled up underneath that subscription.

We frequently see a by-environment organizational structure in place. In this case, there’s a single subscription for all of production, one for development and one for testing with resource groups aligning to each application underneath it. The most mature way to organize is by business unit or service unit—the model that gives ownership of resources to corporate functions. For example, the finance department would have a subscription and the marketing department another. Underneath those subscriptions would be the resource groups corresponding to each application.

Azure resource groups and other structures native to the cloud providers allow you to organize and govern cloud resources effectively. After you create the foundation and use Azure resource group to provide you with the needed segmentation and alignment to your line of business and the applications they run, the next step is to start to effectively match your resources to application demand. By doing so, you’ll be able to maximize application performance while optimizing your resource costs.

Assuring application performance and optimizing your cloud is beyond human scale—which is why we’ve dedicated our mission at IBM to managing the performance, compliance and cost of any application, on any cloud, at any scale.

The Turbonomic software allows you to visualize the parent and child relationship between subscriptions and resource groups more easily. This ability helps visually map out the framework your organization has implemented, allowing you to view your infrastructure in the application contexts you already built out. The Turbonomic software will automatically discover all the associated Azure subscriptions, their resource groups and the resources within each group, including Azure VMs, Azure managed disks, Azure SQL Servers, as well as any reserved instances (RIs), either shared RIs or scoped to a subscription or a resource group. The Turbonomic software will then analyze the utilization of each resource and start generating optimization actions. The view here shows a breakdown of a single Azure subscription and several Azure resource groups under it, the pending optimization actions per resource group, and potential savings from the actions.

Furthermore, Turbonomic software includes a powerful optimization modeling engine designed to allow clients to model different scenarios against the cloud environment in a safe sandbox mode. For example, simulate the impact of Azure Reserved VM Instance inventory utilization after rightsizing the workloads in a resource group versus without rightsizing the workloads.