Azure Regions and Geographies

An Azure Region is a set of data centers deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. Think of it as a single metropolitan area where Microsoft has built multiple physical data centers. Each region is independent and self-contained, meaning it has its own power, cooling, networking, and compute resources. As of 2025, Azure has over 60 regions worldwide, more than any other cloud provider.

The business problem Azure Regions solve is simple: if you run your application in a single data center, a power outage, network cut, or natural disaster can take your entire business offline. By distributing resources across multiple regions, you achieve high availability, disaster recovery, and low latency for users around the world. For example, a gaming company might deploy its game servers in West Europe for European players and East Asia for Asian players, ensuring each user gets sub-50ms response times.

Each Azure Region is a collection of one or more data centers. The data centers within a region are connected by a high-speed, low-latency fiber network, typically with a latency of less than 2 milliseconds between them. This allows you to deploy services like Azure SQL Database across multiple data centers in the same region for redundancy, yet still maintain synchronous replication.

Behind the scenes, Microsoft manages the physical infrastructure. When you create a resource in a region, Azure automatically allocates it to one of the data centers in that region based on capacity and health. You never choose the specific data center—you only choose the region. For example, if you create a virtual machine in East US, Azure places it in one of the several data centers that make up the East US region.

Region Pairs: Each Azure Region is paired with another region within the same geography (e.g., East US is paired with West US). The pair is at least 300 miles (480 km) apart to ensure geographic separation from natural disasters. In the event of a major disaster, Microsoft will prioritize restoring at least one region in each pair. Region pairs also enable services like Azure Storage geo-redundant storage (GRS), which automatically replicates data to the paired region. The exam expects you to know that region pairs are fixed and cannot be changed.

Geographies: A Geography is a discrete market that contains one or more Azure Regions. Each geography preserves data residency and compliance boundaries. For example, the United States geography includes multiple regions like East US, West US, Central US, etc. Data can be replicated within a geography, but not outside it without explicit customer configuration. Geographies are important for customers with data sovereignty requirements, such as European Union companies that must keep data within the EU.

Availability Zones: Within a region, you can use Availability Zones—physically separate data centers with independent power, cooling, and networking. Each zone is essentially a separate data center within the same region. By deploying resources across multiple zones, you protect against data center failures without needing to replicate to a different region. Not all regions support Availability Zones; the exam tests that you know which regions have three or more zones.

Regions themselves are free to use—you don't pay extra for choosing a particular region. However, data transfer costs vary: moving data between regions incurs egress charges, while data transfer within a region is often free. The SLA for virtual machines deployed across two Availability Zones is 99.99%, compared to 99.95% for a single instance. Region-paired deployments can achieve even higher availability but require more complex architectures.

In an on-premises data center, you own the physical building, power, cooling, and networking. You are limited to a single location, making disaster recovery expensive (you need a second site). With Azure Regions, you get access to dozens of global locations without building anything. You can replicate data to a paired region automatically, and you can deploy globally with a few clicks. The trade-off is that you lose control over the exact data center and must trust Microsoft's physical security and operations.

In the Azure portal, when creating any resource, the first required selection is the region. The portal shows a map with region locations and indicates which regions support Availability Zones. You can also use the Azure CLI to list regions:

az account list-locations --output table

This command returns a table of all regions, their display names, and whether they are paired. When creating a resource, you specify the region with the --location parameter:

az vm create --resource-group myGroup --name myVM --location eastus --image UbuntuLTS

Scenario 1: Global SaaS Provider A company providing project management software serves customers in North America, Europe, and Asia. They deploy their application in three regions: East US, West Europe, and Southeast Asia. They use Azure Front Door to route users to the nearest region, automatically failing over if a region becomes unhealthy. The team configures geo-replication for their Azure SQL Database to ensure each region has a readable copy. Cost considerations include data egress fees between regions—they minimize cross-region data transfer by keeping user data local. When they initially deployed only in East US, users in Asia experienced >300ms latency, causing poor adoption. After adding Southeast Asia, latency dropped to <50ms for Asian users. A common mistake is assuming all regions offer the same services—they discovered that some newer services (e.g., certain GPU VMs) were not available in Southeast Asia, forcing them to use a nearby region like East Asia instead.

Scenario 2: Financial Services Compliance A Canadian bank must keep customer data within Canada due to regulatory requirements. They choose the Canada Central (Toronto) and Canada East (Quebec City) regions, both in the Canada geography. They configure geo-redundant storage between these two regions, which are paired. This ensures data never leaves Canada even during disaster recovery. The team also uses Azure Policy to restrict resource creation to only Canadian regions. A pitfall: they initially considered using the US regions for backup, but that would violate compliance. They also learned that Canada East does not support Availability Zones, so they had to use Canada Central for zone-redundant deployments. The cost of geo-replication is roughly double that of locally redundant storage, but they accept it for compliance.

Scenario 3: E-commerce Disaster Recovery An online retailer runs its main workload in West Europe. For disaster recovery, they replicate to North Europe (the paired region) using Azure Site Recovery. They test failover quarterly by performing a planned failover to North Europe, running the site for a day, then failing back. During one test, they discovered that their custom domain DNS was still pointing to the West Europe IP address, causing users to hit a dead site. They now use Azure Traffic Manager with priority routing: primary endpoint is West Europe, secondary is North Europe. When they failover, they update the priority to make North Europe primary. The cost of running a standby environment in the paired region is significant—they keep a minimal footprint (smaller VMs) and scale up only during a real disaster.