Azure Regions, Availability Zones & Resource Hierarchy

Azure's physical infrastructure is a hierarchy of datacenters, grouped into regions, grouped into geographies. A datacenter is a secured facility of servers, storage and networking that Microsoft owns and operates, and it is the smallest physical building block. A region is a set of datacenters in a defined area connected by a low-latency network. A geography is a discrete market, usually one or more countries, typically containing two or more regions (some geographies currently have a single region); geographies exist to meet data-residency, sovereignty and compliance requirements because they keep data within their boundary.

You never manage, or choose, an individual datacenter or rack. The most precise placement you can request is a region, plus an availability zone within it where the region and service offer zones. For example, you can deploy a virtual machine to Zone 1 of West Europe, but you cannot pick which building or server rack Azure uses for it.

An Azure region is a geographical area containing one or more datacenters networked together with low latency, and it is the main choice you make about where a regional resource runs. Azure has dozens of regions worldwide, and they are not identical, so the region you pick matters.

• Proximity: resources close to your users have lower latency, so a business serving Australian customers would choose an Australian region.
• Service and feature availability: not every service, virtual machine size or feature is offered in every region, and newer services often launch in a limited set first.
• Price: the same service can cost a different amount in different regions.
• Compliance and data residency: an organization that must keep data in a country chooses a region in that country's geography.
• Resilience options: some regions have availability zones and some have a paired region; others have neither or only one of these.

Not every service is regional. Some Azure services are global (nonregional): they are not deployed to a region you choose and are designed to stay available even if a region fails. Microsoft's AZ-900 training gives Microsoft Entra ID, Azure Traffic Manager and Azure DNS as examples. When you create one of these, there is no region to pick for the service itself (the portal may still ask for a resource group location, which only stores metadata).

A region pair is an association Microsoft makes between some Azure regions and a second region, almost always in the same geography, used for geo-replication and recovery planning. Pairs are fixed by Microsoft; for example, East US is paired with West US, and Canada Central with Canada East. Pairing gives these benefits:

• Region recovery sequence: in a rare geography-wide outage, one region in every pair is prioritized for recovery.
• Sequential updating: Azure staggers planned platform updates so only one region of a pair is updated at a time, which limits the impact of a faulty update.
• Data residency: almost all pairs stay inside one geography.
• Physical isolation: where possible, the two regions of a pair are far enough apart that a local disaster is unlikely to affect both.

Some services replicate to the pair automatically. Geo-redundant storage (GRS) copies a storage account's data to the primary region's paired region; you do not choose the secondary region, the pairing does. That makes the pairing a compliance question too, because of the exceptions:

• Brazil South is paired with South Central US, outside the Brazil geography, so GRS data from Brazil South is kept in the United States.
• Some pairs are asymmetrical (one direction only): Brazil Southeast pairs with Brazil South, but Brazil South pairs with South Central US; West US 3 pairs with East US, but East US pairs with West US.

Two common misconceptions to avoid:

• Not every region is paired. Many newer regions, such as Italy North, Poland Central, Spain Central and Mexico Central, have no pair and use availability zones as their main redundancy. Surviving a whole-region outage from such a region means you deploy to (or replicate into) a second region yourself, using a service's geo-replication between any chosen regions where it supports that.
• A pair is not automatic high availability. Deploying into a paired region does not make resources resilient and gives no automatic failover; you still design your own high-availability and disaster-recovery plan. Microsoft-managed failover of GRS storage happens only in catastrophic situations.

Sovereign regions are instances of Azure that are physically and logically isolated from the global public cloud, operated to meet strict legal and regulatory requirements. Azure Government serves US government agencies and their partners (its regions include US Gov Virginia and US Gov Arizona), and Azure operated by 21Vianet serves China and is run by a separate operator. A public region located in a country (for example Germany West Central) gives data residency, not sovereignty, and isolated hardware inside the public cloud, such as a dedicated host, is still the public cloud. Remember: pairs are about replication and recovery order; sovereign regions are about isolation and compliance.

An availability zone is one or more physically separate datacenters within a single Azure region, each with independent power, cooling and networking, connected to the other zones by a high-speed private network. Zones protect against the failure of a datacenter: if one zone goes down, resources in another zone of the same region keep running, and your data and resources never leave the region. Regions that support zones have at least three of them, but not every region supports zones, and not every service supports them.

Services use zones in two ways:

• Zonal: the resource is pinned to one zone that you select, such as a virtual machine in Zone 1. It is exposed if that zone fails; to survive, you deploy more copies in other zones yourself.
• Zone-redundant: the platform replicates the resource across zones automatically, so losing one zone does not take it offline and you do not manage the copies. Zone-redundant storage and a zone-redundant public IP address are examples.

Do not confuse zones with availability sets. An availability set spreads virtual machines across fault domains (separate racks, power and network switches) and update domains inside a datacenter; it protects against rack failures and maintenance, not the loss of a whole datacenter. Availability sets are covered in the compute lesson.

Zones guard against local failures; only a second region guards against a whole region going down.

A resource is a single manageable item you create in Azure, such as a virtual machine, storage account, virtual network or database. A resource group is a logical container for resources that share a lifecycle, so you can deploy, manage, secure and delete them together. A resource group runs nothing itself; it is an organizing and management boundary.

Grouping resources by lifecycle pays off in management. You can delete a whole solution in one action by deleting its resource group, assign access once at the group level, and view costs for the group. For example, a team running a three-week trial puts the virtual machine, its disk and its network interface in one resource group, then deletes the group when the trial ends.

The rules to know:

• Every resource is in exactly one resource group; a resource that several projects use still belongs to one group (other teams can be given access to it).
• Resource groups cannot be nested.
• Resources in a group can be in different regions from each other and from the group.
• Resources can be moved between resource groups (and subscriptions), for most resource types.
• Deleting a resource group deletes every resource in it.

A resource group also has its own location, and that location matters: it is where Azure stores the metadata about the group's resources. If compliance requires metadata to stay in a country, the group must be created in a region there. The location is set when the group is created and cannot be changed afterwards, so the fix for a group in the wrong region is to create a new group in the right region and move the resources into it.

A subscription is a unit of management, billing and scale that holds resource groups, and it acts as both a billing boundary and an access control boundary. Every resource belongs to one subscription, and each subscription is billed separately.

• Billing boundary: each subscription produces its own bill, so separate invoices for production and development means separate subscriptions. Resource groups and tags help you report costs within one bill, but they do not split the invoice.
• Access control boundary: permissions and policies can be assigned at the subscription and apply to everything in it.
• Limits: Azure applies some limits and quotas per subscription, so very large deployments may be split across subscriptions.

A subscription is not tied to a region: one subscription can hold resources deployed in many regions. Each subscription trusts one Microsoft Entra tenant for identities, while a tenant can trust many subscriptions.

Organizations create additional subscriptions to separate environments (development, test, production), organizational structures (one per department, with its own access and costs) or billing (separate invoices or budgets). If all you need is grouping or cost reporting inside one bill, resource groups and tags are enough.

A management group is a container above subscriptions that lets you apply access (Azure role assignments) and governance (Azure Policy) once to many subscriptions. Every subscription under a management group inherits its settings, including subscriptions you add to the group later, so one assignment keeps covering the group as it grows.

The structure rules:

• Every Microsoft Entra directory has a single root management group at the top; all management groups and subscriptions sit beneath it, so an assignment at the root reaches everything.
• Management groups can be nested up to six levels deep, not counting the root level or the subscription level.
• Each management group and each subscription has exactly one parent. A subscription cannot sit under two management groups at once; to give it another group's settings you move it, and it then stops inheriting from the old parent.

Inheritance follows the whole ancestor chain. A subscription receives assignments from its parent management group, that group's parents, and the root. When a subscription moves from one management group to another, assignments that come from the root (and any ancestor the two groups share) still apply, the old group's assignments stop applying, and the new group's start applying. The general principle for choosing a scope: assign at the lowest single level whose descendants are exactly the subscriptions you want to cover. If no such level exists, create a management group for that set of subscriptions and assign there, so subscriptions added to it later are covered automatically. Assignments repeated on individual subscriptions have to be maintained one by one, and an assignment made too high reaches subscriptions it was never meant for. To target one subscription only, assign at that subscription.

Together this is the Azure logical hierarchy, four levels from top to bottom:

Settings flow downward: an assignment at a level applies to that level and everything beneath it. Choose the highest level that covers exactly what you need and nothing more.

Azure Resource Manager (ARM) is Azure's deployment and management service, the layer that receives every create, update and delete request for the resources, resource groups and subscriptions described in this lesson. It belongs to a different AZ-900 skill (describing Azure Resource Manager and ARM templates), so it is covered in the lesson on Azure management and deployment tools rather than here. For this topic, the link to remember is the one above: ARM is the service that stores each resource group's metadata in the group's location.