An Azure Resource Group is a required grouping for all your Azure VMs. In this post, we’ll look into what this group structure actually means—and how you can use it for better governance and resource management for your infrastructure.
The Azure Resource Manager
First, a brief overview of how you can manage resource groups through the “Azure Resource Manager”, which you are probably familiar with as this is 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 your resource groups for securing, managing, and tracking the costs related to your workflows and applications.
What are Azure Resource Groups?
Azure Resource Groups are logical collections of virtual machines, storage accounts, virtual networks, web apps, databases, and/or database servers. You can use them to group related resources for an application and divide them into groups for production and non-production, or any other organizational structure you prefer.
The Azure resource group management model provides four levels, or “scopes” of management to organize your resources:
- Management groups: These 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. These 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 virtual machines, storage, or SQL databases.
One important factor to keep in mind when managing these scopes is that there is a difference between an Azure Subscription vs management group. A management group cannot 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 is no structure for a “nested” resource group in Azure – to “nest” groups for permissions, you will need to use a combination of permissions at the different levels listed above.
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 in order to protect the availability of your application.
Ways to Create an Azure Resource Group
There are several ways to create an Azure Resource Group:
- The Azure Portal
- Azure PowerShell scripts
- The Azure CLI
- An ARM template
Azure Resource Group Best Practices
Here are some best practices for using Azure resource groups:
- Resources in a group should have the same life-cycle. 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 dev/test, staging, or production, it is important to use different resource groups 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 remove the resources from one Resource Group, you must add it to another one.
- Not all resources can be moved 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 is 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 this below.
- When a resource group is deleted, all resources in the group are deleted
- Group limits: you can deploy up to 800 instances of a resource type in each resource group – with some exceptions.
Ready to automate Azure Resource Group optimization? Get started by trying the IBM Turbonomic Sandbox or Request your IBM Turbonomic demo today!
How to Use Azure Resource Groups Effectively for Governance
Azure resource groups are a way to operationalize role-based access control (RBAC). Typically, you will 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.
How to Structure Resource Groups
There are several common ways to organize subscriptions and resource groups. The first, unfortunately common, model is “chaos”. If this 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 is organization by application. For example, a Payroll or Billing application would align to a single Azure subscription, with resource groups for each environment (development, testing, staging, etc.) rolled up underneath that subscription.
We frequently see a “by environment” organizational structure in place. In this case, there is a single subscription for all of production, one for development, and one for testing, with resource groups aligning to each application underneath that.
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.
Manage Your Resources at the Next Level
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 leverage 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 will 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 here at Turbonomic to managing the performance, compliance, and cost of any application, on any cloud, at any scale.
Turbonomic allows you to visualize the parent/child relationship between subscriptions and resource groups more easily. This can help visually map out the framework your organization has implemented, allowing you to view your infrastructure in the application contexts you built out already. Turbonomic will automatically discover all the associated Azure subscriptions, their resources groups, and the resources within each group, including Azure VMs, Azure Managed Disks, Azure SQL Servers as well as any Reserved Instances, either shared RIs or scoped to a subscription or a resource group. Turbonomic will then analyze the utilization of each resource and start generating optimization actions. The below view 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 includes a powerful optimization modeling engine designed to allow customers 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.
Ready to learn more? Get started by trying the IBM Turbonomic Sandbox or Request your IBM Turbonomic demo today!
Adapted from an original post authored by Katy Stalcup