Resource groups are the fundamental organizational unit for resources in Azure, but their real power lies in their ability to scope policies and permissions, not just group things visually.
Let’s see this in action. Imagine you’re setting up a new web application. You’ll need a virtual machine, a database, and a storage account.
# Create a resource group for the web app
az group create --name MyWebAppRG --location westus2
# Create the resources within that resource group
az vm create --resource-group MyWebAppRG --name MyWebAppVM --image UbuntuLTS --admin-username azureuser --generate-ssh-keys
az sql db create --resource-group MyWebAppRG --server MyWebAppServer --name MyWebAppDB --edition Basic
az storage account create --resource-group MyWebAppRG --name mywebappstorage --location westus2 --sku Standard_LRS
Now, all these resources are logically grouped. But what if you want to ensure that only certain users can manage these resources, or that all resources within this group must adhere to specific security configurations? That’s where the scoping power comes in.
When you assign an Azure Policy or an Azure Role-Based Access Control (RBAC) role, you specify a scope. This scope can be a subscription, a management group, a resource group, or even a specific resource. Assigning a role at the resource group level means that role’s permissions apply to all resources within that group, and any new resources you add later.
Consider cost management. By grouping related resources, you can easily track and attribute costs. If you have a project with multiple environments (dev, staging, prod), creating separate resource groups for each allows for clear cost allocation and reporting.
The mental model is a hierarchy: Subscription > Management Group > Resource Group > Resource. Policies and permissions flow down. What you define at a higher level is inherited by the lower levels. A policy assigned to a subscription will apply to all resource groups within it, unless explicitly overridden at the resource group level.
The most surprising thing about resource groups is how infrequently people leverage their policy and RBAC scoping capabilities to their full potential, often treating them as mere visual containers. This missed opportunity means duplicated effort in managing permissions and compliance across numerous individual resources. Instead, by defining access and policies at the resource group level, you achieve a much more manageable and scalable infrastructure.
The next concept you’ll run into is managing resources across multiple resource groups with a single operation, often involving Azure Resource Manager (ARM) templates or Bicep.