Resources, Resource Groups, and Subscriptions
Every Azure service you create is a resource. Resources live in resource groups. Resource groups live in subscriptions. Understanding this hierarchy is essential for organising and managing your Azure environment.
Azure’s organisational hierarchy
Think of it like a filing cabinet.
Resources = individual documents (a VM, a database, a storage account).
Resource groups = folders that hold related documents. You might have a “Website” folder and a “Database” folder.
Subscriptions = drawers in the cabinet. Each drawer has its own billing — so the “Production” drawer bills separately from the “Development” drawer.
Management groups = the entire cabinet itself. If you have multiple cabinets (subscriptions), management groups let you apply rules to all of them at once.
The hierarchy visualised
Management Groups
└── Subscriptions
└── Resource Groups
└── ResourcesSummit Construction’s hierarchy:
Root Management Group
├── IT Management Group
│ ├── Production Subscription ($2,000/month)
│ │ ├── RG: project-portal-prod
│ │ │ ├── VM: portal-vm-01
│ │ │ ├── SQL Database: portal-db
│ │ │ └── Storage: portal-files
│ │ └── RG: monitoring-prod
│ │ └── Log Analytics Workspace
│ └── Development Subscription ($400/month)
│ └── RG: project-portal-dev
│ ├── VM: portal-vm-dev
│ └── SQL Database: portal-db-dev
└── Finance Management Group
└── Finance Subscription ($300/month)
└── RG: accounting-app
├── App Service: accounting-web
└── SQL Database: accounting-dbResources — the building blocks
A resource is any Azure service you create:
- A virtual machine
- A storage account
- A SQL database
- A virtual network
- An App Service web app
Key rules:
- Every resource belongs to exactly one resource group
- Resources can be in different regions from their resource group
- Resources can communicate across resource groups and subscriptions
Resource groups — logical containers
A resource group is a container that holds related Azure resources. Think of it as a project folder.
Key rules about resource groups:
| Rule | Detail |
|---|---|
| Every resource needs one | A resource cannot exist outside a resource group |
| One group only | A resource can only be in one resource group at a time |
| Groups can’t be nested | You can’t put a resource group inside another resource group |
| Deleting a group deletes everything | Delete the resource group → all resources inside are deleted |
| Permissions inherit | Apply permissions to the group → all resources inside inherit them |
| Resources can be in different regions | A resource group in “Australia East” can contain resources in “US East” |
Peak Roasters’ resource groups
Peak Roasters organises their Azure resources by application:
| Resource Group | Resources Inside | Purpose |
|---|---|---|
rg-website | App Service, SQL Database, Storage | Online ordering website |
rg-email | (managed by Microsoft 365) | Business email |
rg-backups | Storage account, Recovery vault | Data backups |
Exam tip: Resource group location
A resource group has a location (region), but this is only where the group’s metadata is stored. The resources inside can be in any region.
Example: Resource group in “Australia East” can contain a VM in “US West” and a database in “UK South.”
Why does the group location matter? For compliance — some organisations need metadata stored in specific geographies.
Subscriptions — billing boundaries
A subscription provides:
- Billing boundary — each subscription gets its own invoice
- Access control boundary — you can set different permissions per subscription
- Resource limits — each subscription has quotas (e.g., max VMs per region)
Why multiple subscriptions?
| Reason | Example |
|---|---|
| Separate billing | Production vs development have different budgets |
| Access control | Developers can access dev subscription but not production |
| Compliance | Regulated workloads in a separate subscription with stricter policies |
| Resource limits | Approaching quota limits in one subscription |
Harbour Health uses three subscriptions:
- Production — patient-facing apps, strict access controls
- Development — dev/test environments, more relaxed permissions
- Sandbox — experimentation, auto-delete after 30 days
Management groups — governance at scale
When an organisation has many subscriptions, management groups help manage them:
- Apply Azure Policy to a management group → it applies to ALL subscriptions underneath
- Assign RBAC roles at the management group level → inherited by all subscriptions
- Nest management groups up to 6 levels deep (not counting the root)
Key facts:
- Every Microsoft Entra ID tenant has a single root management group
- All subscriptions belong to the root management group by default
- You can create sub-groups to organise subscriptions by department, environment, or region
Management group hierarchy limits
- 10,000 management groups per directory
- 6 levels of depth (excluding root)
- Each management group or subscription can have only one parent
- Each management group can have many children
This tree structure means policies and access controls flow DOWN from parent to child — a powerful governance mechanism for large organisations.
🎬 Video walkthrough
Flashcards
Knowledge Check
Peak Roasters wants to ensure that when they're done with their test environment, all test resources are cleaned up with a single action. What should they use?
Harbour Health wants production and development environments to have separate billing. What is the BEST way to achieve this?
What is the correct hierarchy from TOP to BOTTOM in Azure's organisational structure?
Next up: Azure Virtual Machines — the most common IaaS service, including Scale Sets, availability sets, and Azure Virtual Desktop.