How Azure organizes the planet's worth of hardware underneath it (regions, availability zones) and how you organize your own resources on top of it (resource groups, subscriptions, management groups). Everything in the rest of Domain 2 gets deployed into this structure.
Your company has a Marketing team and an IT team. Each team runs separate dev, test, and production subscriptions — six subscriptions total. Compliance wants one rule — "no VMs outside the US West region" — enforced automatically on every subscription, for every team, without anyone touching each subscription individually. What Azure construct makes that possible in one place? Keep this in mind; the answer falls out naturally once you've seen the whole hierarchy below.
You never interact with an individual Azure datacenter directly — you interact with two organizing layers built on top of them.
A region is a geographic area containing one or more datacenters, networked together with low latency. When you deploy most resources, you pick a region. A handful of global services — Microsoft Entra ID, Azure Traffic Manager, Azure DNS — skip this, since they aren't tied to one region at all.
An availability zone is a physically separate datacenter within a region, with its own independent power, cooling, and networking — an isolation boundary, so if one zone goes down, the others keep running. Zones within a region are linked by high-speed private fiber.
Every availability-zone-enabled region guarantees a minimum of three separate zones. Not every region supports availability zones at all.
Services relate to zones in three ways: zonal (you pin the resource to one specific zone — e.g. a VM), zone-redundant (the platform replicates automatically across zones — e.g. zone-redundant storage), and non-regional (always available Azure-geography-wide, resilient even to a whole region going down).
Most regions are paired with another region in the same geography, at least 300 miles away — far enough to survive a regional disaster, close enough to stay useful. If one region in a pair goes down, Azure prioritizes restoring at least one of the pair quickly, and planned platform updates roll out to paired regions one at a time to limit shared risk. This is a second, coarser layer of resilience sitting above availability zones.
Isolated instances of Azure, separate from the main Azure fabric, used for legal/compliance reasons — e.g. US Gov regions (screened US personnel, extra compliance certifications) and China regions (operated via a Microsoft partnership with 21Vianet, not directly by Microsoft).
This is the hierarchy you build to organize what you deploy. It nests, top to bottom:
| Layer | What it is | Key rule |
|---|---|---|
| Management group | Groups subscriptions for org-wide governance | Nests up to 6 levels; every subscription/group has exactly one parent; all roll up to one Tenant Root Group per Microsoft Entra tenant |
| Subscription | A billing boundary and an access-control boundary | Links to an identity in Microsoft Entra ID; one account can hold several subscriptions (e.g. split by environment or team) |
| Resource group | A logical container for related resources | Every resource belongs to exactly one resource group at a time; groups can't be nested or renamed; deleting the group deletes everything inside it |
| Resource | The actual thing — a VM, a database, a virtual network | The basic building block; anything you provision is a resource |
Policies and access permissions set at a higher layer inherit downward automatically — assign an Azure RBAC role at the management group level, and every subscription, resource group, and resource beneath it inherits it, with no need to repeat the assignment anywhere below.
Back to the calibration scenario: the answer is a management group. Put all six subscriptions under one management group, apply the "US West only" policy once at that level, and it inherits to every subscription — and every resource inside them — automatically. Neither team can override it locally.