This chapter covers Azure Regions and Geographies — the physical and organizational structure behind where Azure resources actually run. AZ-900 tests this under objective 2.1, foundational to understanding Azure's overall architecture.
Jump to a section
A simple way to picture Azure Regions and Geographies
A national retailer doesn't ship every order from a single central warehouse — it builds warehouses in multiple cities so orders can be fulfilled from whichever location is closest to the customer, reducing delivery time. Azure Regions work the same way for computing: instead of hosting everything from one physical location worldwide, Azure operates data centers grouped into regions across the globe, so organizations can deploy resources closer to their users, reducing latency, and can choose specific regions to meet data-residency requirements.
What a Region is
An Azure Region is a set of data centers deployed within a defined geographic area, connected through a dedicated regional network. When you create a resource in Azure, you generally choose which region it should run in.
What a Geography is
A Geography is a larger boundary — typically a country or defined area — containing one or more regions, often used to address specific data-residency, sovereignty, or compliance requirements. Keeping data within a specific geography can matter for organizations subject to regulations about where their data is allowed to be stored.
Why region choice matters
Choosing a region affects latency (how close the resource is to its users), data residency (which legal jurisdiction the data falls under), and which specific Azure services are available (not every service is available in every region). Region pairs, covered in a dedicated chapter, add another layer relevant to disaster recovery.
How to choose a region
There's no single "best" region — the right choice depends on where users are located, any regulatory requirements about data location, and which services the workload needs, since availability can vary by region.
Portal and CLI touchpoints
Region is typically selected as a required parameter when creating most resources:
az group create --name myRG --location eastusThe Azure portal similarly requires a region selection during resource creation.
Identify user or data-residency requirements
Before choosing a region, consider where the workload's users are located and whether any regulations require data to remain within a specific geographic boundary.
Check service availability in candidate regions
Not every Azure service is available in every region — confirming the needed services are available in a candidate region is an important step before committing to it.
Consider latency to end users
Choosing a region physically closer to the majority of a workload's users generally reduces latency and improves the experience for those users.
Deploy resources to the chosen region
Once selected, the region is specified as a parameter when creating resources through the portal, CLI, PowerShell, or templates.
A company serving customers primarily in Western Europe deploys its application in a European Azure region, reducing latency for those users compared to hosting everything in a distant region. A separate healthcare organization, subject to regulations requiring patient data to remain within a specific country, carefully selects a region within that country's geography to comply with those requirements.
A common real-world mistake is deploying resources in a region without checking whether all the required services are actually available there, discovering the gap only after the fact — checking service availability per region is a simple step that avoids this problem.
Objective 2.1 expects candidates to understand what a Region is, how it differs from a Geography, and why region selection matters.
A common wrong answer is confusing "Region" and "Availability Zone" — a region is a broad geographic area containing data centers, while an Availability Zone (covered in its own chapter) is a physically separate location *within* a region. Another common trap is assuming every Azure service is available in every region — availability varies.
Stable terms: Region, Geography. Understanding that a Geography can contain multiple Regions, and that region choice affects latency, compliance, and service availability, is the core exam-relevant idea.
Memory trick: Geography = the broad legal/geographic boundary. Region = the specific area with data centers where you actually deploy resources.
An Azure Region is a defined geographic area containing a set of connected data centers, where resources are actually deployed.
A Geography is a larger boundary (often a country) that can contain multiple regions, relevant to data-residency requirements.
Region choice affects latency, data residency and compliance, and which services are available.
Not every Azure service is available in every region — checking availability is an important step in region selection.
These come up on the exam all the time. Here's how to tell them apart.
Region
A specific area with a set of data centers
Where resources are actually deployed
Smaller, more specific boundary
Geography
A larger area (often a country) containing regions
Used to address data-residency requirements
Broader, encompassing boundary
Mistake
Region and Availability Zone mean the same thing.
Correct
A Region is a broad geographic area with data centers; an Availability Zone is a physically separate location *within* a region. They operate at different scales.
Mistake
Every Azure service is available in every region.
Correct
Service availability varies by region — it's important to confirm a needed service is available in a candidate region before committing to it.
Mistake
Region choice only affects performance, not compliance.
Correct
Region choice also affects data residency and regulatory compliance, since data typically stays within the chosen region's jurisdiction, which matters for organizations with location-based data requirements.
It's a defined geographic area containing a set of Azure data centers, connected through a dedicated regional network. When creating most Azure resources, you choose which region they should be deployed in.
A Region is a specific area with data centers where resources are deployed. A Geography is a larger boundary, often a country, that can contain multiple regions — relevant mainly for data-residency and compliance purposes.
No. Service availability varies by region, so it's worth confirming a needed service is available in a candidate region before choosing it, especially for less common or newer services.
You've just covered Azure Regions and Geographies — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?