Azure Resource Group Best Practices

Azure Resource Groups are the foundation of resource management in Azure. Therefore, using best practices for designing a resource group strategy is critical to efficiently managing Azure infrastructure. Your organization can streamline, automate, and secure the resource creation and management process with the right Azure Resource Group strategy.

To help you understand this important piece of Azure administration, this article will review how Azure Resource Groups work and detail best practices for implementing Azure Resource Groups. 

How do Azure Resource Groups Work?

Everything that you can purchase or enable in Azure creates an object in your Azure tenant. These objects are called “resources”. An Azure resource could be a virtual machine, a network card, a disk, or any other component from the Azure Marketplace.Azure Resource Groups are containers that hold these resources for an Azure tenant. Organizing resources into Azure Resource Groups makes it possible to manage them more effectively.

These  fundamental rules help explain how Azure Resource Groups work:

• All Azure resources created must be in a resource group.
• All resource groups are created within a single Azure subscription and cannot be moved to another subscription. However, you can move individual resources to another subscription.
• Resources can only belong to one group at a time.
• You can move resources from one resource group to another.
• Resource groups can contain different types of resources (e.g. virtual machines and network cards).
• Resource groups do NOT logically isolate communication between resources. You can have VMs in different groups and still work together with them, or have managed disks attached to a VM that belongs to a different resource group.

As you can see, there are many considerations you need to take into account when you create and manage resource groups. In the next sections, you’ll learn best practices to help you use Azure Resource Groups effectively in production environments.

Azure Resource Groups Best Practices Overview

Here is a brief summary of best practices to design and deploy resource groups in an Azure Tenant. The sections that follow will expand on each of these best practices.

Azure Resource Groups Best Practices
Category	Best Practices
Deployment Models	Pick a strategy that matches your needs. Examples include: By Environment – Manage your resources by environment (Development, Test, Production, Staging, etc.). By Application – Manage resources depending on the application they support. By Business Unit – Manage resources that are part of a business unit
Naming Standards	Include the following parameters in your resource group naming standard: Object Type: (rg) Application or Business Unit: (app1)Environment: dev, test, prod, stgAzure Region: Use Azure region short names for the RG name (scus, euno, apac)Entity consecutive number: 001,002, etc.
Resource Tagging	Use tags for: Metadata and documentation – Set a tagging standard for metadata to be used for documentation purposes.  Automation – Use tags to perform automated tasks on them.Cost and billing – You can set tags to do reporting on the Cost Management + Billing Console. Selecting a tagging standard for cost will allow the cost administrator to differentiate between apps or business units.   In all cases, clear, accessible, and up-to-date documentation is key!  All stakeholders should have access to a central documentation repository to review information about Azure tags.
Managing Access	Create and manage roles and assign them permissions at the following levels: Subscription Level: Use subscription level permissions if you want all resources from a specific subscription to be managed by a particular group. Recommended when you use subscriptions for different environments or different business units.   Resource Group level: Use the resource group level permissions assignment to make sure the users that require access only have access to the resources within that group.   For both cases, create specific roles for users and assign them proper permissions (Reader, Contributor, or Owner) at the resource group or subscription level.

Group Deployment Models

Selecting a deployment model for your resource group strategy is key to managing Azure resources and driving their adoption.Deciding which deployment model is best for each organization depends on the organization itself, as there are many ways to organize resources.

This section will cover the different deployment models for Resource Groups:

• By environment
• By application
• By business unit

In any of the scenarios, once a deployment model is selected, it should be followed for the entire lifetime of the Azure tenant. 

Deployment Model by Environment

In this deployment model, a different subscription is created for each environment, and you create resource groups within each subscription. “By environment” is the most common deployment model. It is used when the entire organization runs as a single business and does not need isolation between resources and management.

Here is an example of the “by environment” structure:

When you select a deployment model based on the environment, the resource group naming should help identify the app name or business unit the resources are part of to help manage and identify costs for each resource in each subscription.

Deployment Model by Business Unit

In the “by business unit” deployment model, subscriptions are created based on the business units. This approach is most common when an organization is clearly divided into different business units, but wants to have a single Azure management plane.

Here is an example of the “by business unit” structure:

In this case, the resource group naming should help identify the app name and the environment if the organization supports different infrastructure environments.

Deployment Model by Application

The “by application” deployment model is best when you want to manage each application in a different subscription and use resource groups to manage environments only. This deployment model is recommended for startups or technology companies that are organized by apps rather than business units. It helps organize resource groups by the application they support.

Here is an example of this structure:

Naming Standards

For naming resource groups, it is essential to first have a naming standard for all resources in an Azure tenant. To determine a good naming standard, follow Microsoft recommendations for Azure resource naming.

Once you have a standard for Azure resource naming, you can move to Azure Resource Group naming. For resource group naming, follow these best practices:

• Use “rg” as the first 2 letters to identify the resource group.
• Include the business unit name. Use “general” or another name if no business unit is used. This will help you add it later if the organization wants to change the strategy on resource groups.
• Include the app name. Examples: app1, db1, app20, etc.
• Include the environment name. Examples: dev, test, prod, stg, etc.
• Include the Azure region as a short name. For example, scus (South Central US), use2 (US East 2), or euno (North Europe). To get a list of the Azure regions, go to the Azure Portal at https://portal.azure.com and run the following PowerShell command:
   az account list-locations -o table
• Include a consecutive entity number, for example, 001
• Always use – or _ to separate each component on the name

Here is an example of a resource group name:

rg-general-app1-prod-use2-001

Ensure all possible options to name a resource group are well-defined and published in a repository for all stakeholders. If possible, create resource groups using a pipeline or form to make sure the resources and resource groups are created using the naming standards approved by the organization. The Azure Portal cannot force the administrator to create resource groups out of a standard, so make sure all engineers understand the standard and the importance of maintaining it.

Resource Tagging

Tags are values that you attach to Azure resources or resource groups to logically identify and organize them regardless in which resource group they are located. They also allow identifying a resource or resource group in different contexts, such as cost management.

Tags are defined using two related fields: name and value. You can set a tag, for example, to identify SLA and put values like bronze, silver, and gold.

You can use resource tagging for the following:

• Operations – You can set operational tags for documentation purposes. The SLA tag is an example of one of them.
• Security – You can set tags to identify sensitive resources that are protected. For example, resources may be subject to protections based on a security standard like PCI or HIPAA. You can use tags to identify which resources are protected or non-protected.
• Workload automation – You can set tags to enable or disable automated workflows in Azure. For example, you can set a tag to automate power management and create a script that detects that tag to power on or power off the resource at specific times.
• Organization – You can also use tags for organization. If you need additional tags to identify resources, you can add them for documentation purposes.

For naming standards, ensure tags and values are well documented and published for the Azure engineers to review. However, for tagging, you can set policies to make sure all resources created have their tags set when they are created. For more information about tagging policies, review Policy definitions for tagging resources – Azure Resource Manager | Microsoft Docs

Access Management

Identity and Access Management (IAM) is used to secure and grant access to each resource group within Azure.

Each resource group has an Access Control List (ACL) for entities that have access. Resource access is based on roles assigned to each person or group.

The default roles created are:

• Reader – To provide read-only access to the resources
• Contributor – To grant permissions to create and manage resources within the resource group
• Owner – To grant full control permissions over the subscription or resource group.

Here is an example of how these roles grant permissions:

Each role can have more than one person or group assigned to the group. To add a person to any role, the user must be part of the Azure Active Directory tenant where Azure is located. If the user is external, it should be invited as a guest to access Azure and the resource groups assigned.

As a best practice, role assignment should be granted by using Azure AD Groups instead of individual user accounts. This approach keeps access management organized, and access can be granted using the Azure AD console without granting owner access to other administrators.

While you can create custom roles, it is a best practice to use the default roles. You should only create custom roles when there is a well-defined business or technical reason you cannot use default roles.

When you are designing your security solution, make sure you work with the security department to make sure access rules are followed.

Conclusion

Azure Resource Groups is one of the most critical components of Azure administration. Proper resource group design enables administrators to provide better service and response times to users by quickly identifying resources, deploying new resources, and automating workflows to streamline operations. While no two use cases are exactly the same, the best practices you learned in this article will help you get started designing an Azure implementation that meets your needs.