Azure Regions, Availability Zones & Resource Hierarchy

Azure is a global cloud built from physical hardware that Microsoft owns and operates. The smallest physical building block is the datacenter — a secured facility full of servers, storage, and networking. You never manage a datacenter directly; instead you choose a region, and Azure places your resources on hardware inside it. A region is a set of datacenters deployed close together within a defined area and connected by a low-latency network. Regions are grouped into larger geographies, such as the United States or Europe, which help meet data-residency and compliance needs because data usually stays within its geography.

Think of it as three layers: many datacenters make up a region, and many regions make up a geography. For example, when you create a virtual machine and pick the region West Europe, Azure runs that machine in one of the datacenters that make up that region. Understanding this footprint matters because where you deploy affects latency for your users, which features are available, and the price you pay — not every service or price is identical in every region.

An Azure region is a geographical area that contains one or more datacenters networked together, and it is the main choice you make about where your resources live. Azure has more than 60 regions worldwide, giving you options close to almost any set of users. Choosing a region well comes down to a few factors.

• Proximity: putting resources near your users lowers latency, so a business serving customers in Australia would choose an Australian region rather than one in North America.
• Feature availability: newer services sometimes launch in a limited set of regions before rolling out everywhere, so the region you pick can determine what you can deploy.
• Price: the cost of the same service can differ from one region to another.
• Compliance: some organizations must keep data inside a specific country or area.

A region is also the scope for many services — when you deploy a resource, you deploy it into a region, and that region is where it physically runs. Some special regions exist too, which the next sections cover.

Most Azure regions are joined with a second region in the same geography to form a region pair. The two regions in a pair sit at least 300 miles apart where possible, which means a single large event — a flood, storm, or power outage — is unlikely to affect both at once. Region pairs support disaster recovery: some Azure services automatically replicate data to the paired region, and during a broad outage Microsoft prioritizes recovering one region in each pair first. Planned platform updates are also rolled out to only one region in a pair at a time to reduce risk. A common example is East US paired with West US.

Sovereign regions are separate, isolated instances of Azure that are physically and logically kept apart from the main global cloud. Azure Government serves US government agencies and their partners, and Azure operated by 21Vianet serves customers in China. These sovereign clouds exist to meet strict regulatory, legal, and data-handling requirements that the standard public regions cannot. For AZ-900, remember that region pairs are about resilience and replication, while 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. Zones exist to protect your applications from the failure of a single datacenter: if one zone goes down, resources running in another zone in the same region keep working. Regions that support zones have at least three of them.

There are two ways to use zones. A zonal deployment pins a resource to one specific zone — useful when you want components close together, but that resource is exposed if its zone fails. A zone-redundant deployment spreads a service automatically across multiple zones, so the loss of one zone does not take the service offline. For example, you might run a zone-redundant database so it survives a datacenter outage, while a virtual machine placed in Zone 1 is zonal. It helps to see how zones compare to region pairs:

Zones guard against local failures; region pairs guard against a whole region going down.

A resource is a single manageable item you create in Azure — a virtual machine, a storage account, a database, or a virtual network are all resources. A resource group is a logical container that holds related resources for a solution. Every resource must live in exactly one resource group, and a resource group is simply an organizing boundary — it does not run anything itself.

Grouping resources together brings real benefits. You can deploy, update, and delete everything in a group as a single unit, so tearing down a finished project is one action rather than many. You can apply access permissions and view combined costs at the group level. For example, a company building a web application might place the app's virtual machine, its database, and its storage account in one resource group called shopfront-prod, then delete the whole group when the project ends.

A few practical rules: resources in a group can span different regions, a resource can be moved to another group, and deleting a resource group deletes everything inside it — so name and organize groups thoughtfully. Resource groups are the level where day-to-day resource management usually happens.

A subscription is a billing and access boundary that holds resource groups and the resources inside them. Every resource you create ultimately belongs to a subscription, and the subscription is what receives the bill for that usage. Subscriptions serve two main purposes.

• Billing: you can use separate subscriptions to split costs cleanly — for example, one subscription for production and another for development and testing, so each shows up as its own invoice.
• Access and limits: a subscription is a boundary for assigning permissions, and Azure enforces certain limits and quotas at the subscription level, such as how many of a given resource you can create.

An organization can have many subscriptions under a single account, which helps large teams keep environments, departments, or projects financially and administratively separate. For example, a business might give each department its own subscription so every department sees only its own resources and its own costs. When you sign up for Azure, you start with one subscription, and you can add more as your needs grow. Remember the trigger phrase for the exam: a subscription is the billing boundary.

When an organization has many subscriptions, managing each one separately becomes hard. A management group is a container that sits above subscriptions and lets you organize and manage several subscriptions together. You can apply settings — such as access assignments and, later in your Azure journey, governance policies — to a management group, and every subscription beneath it inherits them. Management groups can also be nested, so you can build a structure that mirrors your company, for example a top-level group with child groups for each region or business unit.

This gives you the full Azure logical hierarchy, four levels from top to bottom:

Read it top to bottom: a management group contains subscriptions, a subscription contains resource groups, and a resource group contains resources. Settings applied higher up flow downward. The exam loves to ask you to place these four levels in the correct order, so memorize the chain: management group, then subscription, then resource group, then resource.

Azure Resource Manager, usually shortened to ARM, is the deployment and management layer of Azure. Whenever you create, update, or delete anything — whether you use the Azure portal, the command line, or automated templates — your request goes to Azure Resource Manager, which authenticates it, checks your permissions, and carries it out. In other words, ARM is the single front door that every management tool talks to, which is why the experience is consistent no matter how you work.

ARM is what makes resource groups, tags, and access control work across all services in the same way. It also lets you deploy a whole set of resources together and repeatedly by describing them in a template file, so the same environment can be recreated reliably. For example, if you deploy a virtual machine from the portal and a teammate deploys one with a command-line script, both requests are handled by the same Azure Resource Manager, applying the same permission checks.

For AZ-900 you do not need to write templates; you just need to recognize that Azure Resource Manager is the consistent management layer that sits between your tools and your resources.