Microsoft cloud
Resource group
Azure resource group
An Azure resource group is a logical container within an Azure subscription that holds related resources, virtual machines, storage accounts, virtual networks, disks, and so on, for a solution.
Why Resource group matters in a Microsoft estate
Resource group matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
How Resource group shows up in practice
This lets them be managed, monitored, secured, and billed as a coherent unit, rather than as a flat, undifferentiated list of every resource in a subscription. Every Azure resource must belong to exactly one resource group at all times, and resource groups themselves belong to a subscription. A resource group has a defined region for its own metadata, but the resources inside it can span multiple regions. This is a common point of confusion for anyone assuming a resource group implies geographic co-location of everything within it. The practical value of resource groups shows up in three places.
The first is access control: Azure role-based access control (RBAC) role assignments made at the resource group level automatically apply to every resource inside it, letting an administrator grant a team contributor access to an entire application's infrastructure with one assignment rather than one per resource. The second is lifecycle management: deleting a resource group deletes every resource inside it in one operation, which is both a powerful cleanup tool for tearing down an entire test environment in seconds and a genuinely dangerous one if a resource group is deleted without a clear understanding of everything it actually contains.
The third is cost visibility: Azure Cost Management can filter and report spend by resource group, making it the natural unit for attributing Azure cost to a specific project, department, application, or environment, provided resources were organised into groups deliberately rather than dumped into one another for convenience. Common resource group design patterns include grouping by application (all resources for one workload together, deleted together when the workload is retired), by environment (separate groups per environment, such as one holding production Azure Virtual Desktop session hosts and one holding the development or pilot session hosts), or by lifecycle (grouping resources that share the same deployment and update cadence).
The choice matters, because a poorly designed grouping strategy, most commonly one enormous shared resource group holding every resource an organisation has ever created, actively defeats the access control, cleanup, and cost attribution benefits resource groups exist to provide. That forces administrators back to manually tagging and filtering individual resources to get the clarity a well-structured resource group layout would have given for free. Naming conventions and mandatory tagging policies, often enforced automatically through Azure Policy at the subscription or management group level, are the standard mechanism organisations use to keep resource group structure consistent as the number of teams creating resources grows.