Resource Organization

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands and portal steps below were checked against Azure CLI 2.90.0 on 2026-09-26; re-verify against the linked reference pages if you are reading this later.

Every resource in Azure — a storage account, a virtual network, a Container Apps environment — lives inside a strict containment hierarchy, and every action on it, whatever tool issues it, passes through the same control plane. This page covers that hierarchy, the control plane behind it, and the three organizational tools you use day to day: naming conventions, tags and resource locks.

The containment hierarchy

Azure organizes everything into four nested levels:

Management groups

Optional containers above subscriptions, used to apply policy and RBAC across many subscriptions at once (for example, one management group per business unit or environment tier).

Subscriptions

The billing and access-management boundary. Quotas, cost reports and many RBAC assignments are scoped at this level.

Resource groups

A logical container for resources that share the same lifecycle — typically deployed, updated and deleted together. A resource belongs to exactly one resource group.

Resources

The actual services — storage accounts, virtual machines, Container Apps environments, and so on.

The Bookshelf sample application used throughout this section keeps everything in a single resource group, rg-bookshelf, inside whichever subscription the reader is using; production estates typically split environments (dev/test/prod) across separate subscriptions or resource groups instead.

graph TD MG[Management group] --> SUB[Subscription] SUB --> RG["Resource group: rg-bookshelf"] RG --> ST["Storage account: stbookshelf"] RG --> ACA["Container Apps environment: cae-bookshelf"] RG --> VNET["Virtual network: vnet-bookshelf"]

Azure Resource Manager: the control plane

Whichever tool you use — the Azure portal, the Azure CLI, Azure PowerShell, a Bicep or ARM template, or Terraform’s azurerm provider — every one of them ultimately calls the same REST API: Azure Resource Manager (ARM). ARM is what makes Azure management declarative and idempotent: every create-or-update operation is a PUT against a resource’s URL, and sending the same PUT twice produces the same end state rather than a duplicate resource. ARM is also where role-based access control (RBAC) is enforced — a request that reaches ARM without the right role assignment at the relevant scope (management group, subscription or resource group) is rejected before it reaches the underlying service. Identity and RBAC are covered in depth in Identity and Access; infrastructure-as-code tools that target ARM declaratively are covered in Infrastructure as Code.

Creating a resource group

In the Azure portal

  1. Sign in to the Azure portal and open Resource groups.

  2. Select + Create.

  3. Choose the subscription, enter rg-bookshelf as the resource group name, and pick a region — eastus2 is used throughout this section as a placeholder; choose the region closest to you instead.

  4. Select Review + create, then Create.

With the Azure CLI

RG="rg-bookshelf"
LOCATION="eastus2" # placeholder -- pick the region closest to you

az group create --name "$RG" --location "$LOCATION"

Reference: https://learn.microsoft.com/azure/azure-resource-manager/management/manage-resource-groups-cli

Naming conventions

Resource names are visible everywhere — in the portal, in CLI output, in monitoring dashboards — so a consistent scheme pays off quickly. Microsoft publishes a recommended set of abbreviation prefixes per resource type, such as rg- for resource groups, st for storage accounts (which cannot contain hyphens), and vnet- for virtual networks; the Bookshelf examples in this section follow that scheme (rg-bookshelf, stbookshelf, vnet-bookshelf). The full recommended abbreviation table is linked in References.

Tags

Tags are key/value pairs attached to a resource, resource group or subscription, used for cost allocation, ownership tracking and automation filters — for example environment=dev or owner=bookshelf-team. The key point to remember is that tags are not inherited by the resources inside a tagged resource group unless an Azure Policy is used to apply or enforce them; tagging rg-bookshelf with environment=dev does not, by itself, tag the storage account or Container Apps environment inside it.

In the Azure portal

  1. Open the resource group or resource, then select Tags in the left-hand blade.

  2. Enter a name and value (for example, environment / dev), select Apply, then repeat for additional pairs.

With the Azure CLI

# Tag the resource group itself -- "merge" adds/updates these keys and keeps any other existing tags
az tag update --resource-id "$(az group show --name "$RG" --query id -o tsv)" \
  --operation Merge \
  --tags environment=dev owner=bookshelf-team

# Tag a specific resource inside the group; --is-incremental keeps its existing tags
az resource tag --tags environment=dev owner=bookshelf-team \
  --is-incremental \
  --name "stbookshelf" \
  --resource-group "$RG" \
  --resource-type "Microsoft.Storage/storageAccounts"

Several tagging commands replace the target’s entire tag set by default: az tag create --resource-id and az tag update --operation Replace overwrite every existing tag, and az resource tag does the same unless --is-incremental is passed — hence --operation Merge and --is-incremental above.

Reference: https://learn.microsoft.com/cli/azure/tag#az-tag-update and https://learn.microsoft.com/cli/azure/resource#az-resource-tag

Reference: https://learn.microsoft.com/azure/azure-resource-manager/management/tag-resources

Resource locks

A resource lock overrides the permissions granted to any user, including an Owner or Contributor, to prevent accidental changes or deletion. There are two lock levels: CanNotDelete, which allows reads and updates but blocks deletion, and ReadOnly, which blocks any modification or deletion, including operations that only appear read-only to the caller, such as adding a role assignment. Holding Owner or Contributor access on a locked resource does not let you bypass the lock — only an explicit Microsoft.Authorization/locks/* permission does, so removing or changing a lock is itself a separately permissioned action.

In the Azure portal

  1. Open the resource group or resource, then select Locks in the left-hand blade.

  2. Select + Add, enter a lock name, choose Delete (CanNotDelete) or Read-only (ReadOnly), and select OK.

With the Azure CLI

az lock create \
  --name "lock-rg-bookshelf" \
  --resource-group "$RG" \
  --lock-type CanNotDelete

Reference: https://learn.microsoft.com/azure/azure-resource-manager/management/lock-resources

Management groups

Management groups sit above subscriptions and let you apply policy and access assignments across many subscriptions from a single point, without repeating the assignment per subscription. A typical layout groups subscriptions by environment (mg-production, mg-nonproduction) or by business unit.

In the Azure portal

  1. Open Management Groups and select + Create.

  2. Enter a management group ID and, optionally, a display name, then select Save.

  3. Use Add subscription on the management group’s overview page to move a subscription under it.

With the Azure CLI

az account management-group create --name "mg-bookshelf-nonprod"

az account management-group list --output table

Reference: https://learn.microsoft.com/azure/governance/management-groups/overview

Moving resources

Many, but not all, resource types can be moved between resource groups and, with more restrictions, between subscriptions — the target resource group or subscription must support the resource type, and some services (for example, resources with dependencies pinned to a specific region’s internal identifiers) refuse the move outright. A move never changes the resource’s region: the resource keeps running in the same physical location it was created in, only its management scope (resource group or subscription) changes. Before moving anything in your own environment, check the specific resource type’s move support and any prerequisites in the reference below, since support varies per service.

Clean up

The CanNotDelete lock created above blocks deleting rg-bookshelf, so remove it first; then delete the resource group (which removes every resource inside it) and the empty management group created on this page.

# Remove the lock first -- otherwise the group delete below is rejected
az lock delete --name "lock-rg-bookshelf" --resource-group "$RG"

az group delete --name "$RG" --yes --no-wait

# A management group can only be deleted once it has no child subscriptions or management groups
az account management-group delete --name "mg-bookshelf-nonprod"

Reference: https://learn.microsoft.com/cli/azure/lock#az-lock-delete and https://learn.microsoft.com/cli/azure/account/management-group#az-account-management-group-delete

References