Azure Global Infrastructure: Regions, Geographies, and Sovereign Clouds

What an Azure region is

An Azure region is a geographic area that contains one or more physical data centers, connected to each other with a high-speed network. When you deploy a virtual machine, a database, or any other resource, you choose a region, and Azure places that resource in the data centers that make up that region.

Examples of Azure regions:

• East US — Northern Virginia, USA
• West Europe — Netherlands
• Southeast Asia — Singapore
• Australia East — New South Wales
• Brazil South — São Paulo state
• Japan East — Tokyo, Saitama
• UK South — London

Regions are separate from each other at the network level. Data stored in West Europe does not automatically replicate to East US — you have to explicitly configure cross-region replication if you want it.

Geographies and data residency

Azure groups regions into geographies — typically defined by country or continent. A geography is primarily a data residency and compliance construct. When you choose geo-redundant storage (GRS) or global services that replicate across regions, the replication stays within the geography by default.

Examples of geographies and their regions:

The geography boundary matters for GDPR compliance. If your organization processes personal data from EU residents under GDPR, that data must not leave the EU geography. Azure’s EU data boundary commitment covers the European geography, meaning data stored in West Europe or North Europe (Ireland) stays within the EU for core services.

Region pairs

Every commercial Azure region is paired with another region in the same geography. Region pairs serve a specific purpose: high availability for services that use geo-replication.

Selected region pairs:

Microsoft guarantees that planned maintenance updates are not applied to both paired regions simultaneously. If East US is being patched, West US will not be patched at the same time. This reduces the risk of region-wide issues during maintenance windows affecting your primary and DR region at once.

Services that support geo-redundant replication — like Azure Blob Storage with GRS, Azure SQL Database with active geo-replication, or Azure Cosmos DB with multi-region writes — replicate to the paired region by default.

Availability zones within a region

Many Azure regions offer availability zones — physically separate data centers within the same region, each with independent power, cooling, and networking. Availability zones are how you build applications that survive a single data center failure without failing over to a different region.

Not every region has availability zones. Before committing to a region for a high-availability workload, verify that the region offers availability zones. You can check this in the Azure portal under Subscriptions → [your subscription] → Usage + quotas, or in the Azure documentation’s region and AZ availability tables.

For the full mechanics of how availability zones work in Azure — including zonal vs. zone-redundant service deployment, what fails when a single zone goes down, and a worked architecture example — see Azure regions and availability zones.

Sovereign clouds

In addition to the commercial Azure cloud, Microsoft operates physically isolated cloud environments for specific regulatory and jurisdictional requirements. These are called sovereign clouds.

Azure Government

Azure Government is a physically separate cloud for US government agencies, defense contractors, and other entities that must comply with US federal regulations (FedRAMP High, DoD IL2/IL4/IL5, ITAR). It runs in US-only data centers staffed by screened US persons. The service catalog mirrors commercial Azure but lags slightly behind on new service availability. Access requires a government entity or sponsorship — you can’t sign up with a personal account.

Azure China (operated by 21Vianet)

Chinese law requires that cloud services operating in mainland China be operated by a licensed Chinese entity. Azure China is physically separate from global Azure and operated by 21Vianet. Features and services sometimes differ from global Azure. If you are deploying an application for mainland Chinese users, you need to apply for an Azure China account separately — your global Azure subscription does not extend to China regions.

Azure Germany (legacy)

The original Azure Germany was a data trustee model operated by T-Systems to comply with German data sovereignty requirements. It is largely replaced by the standard Azure Germany West Central and Germany North regions in commercial Azure, which now satisfy most German and EU compliance requirements. New deployments should use commercial Azure Germany regions unless there is a specific requirement for the legacy model.

How to choose an Azure region

Choosing a region is rarely a single-factor decision. Here is a structured way to work through it.

Step 1: Data residency requirements

Start with compliance. Does your workload handle data that has legal or contractual restrictions on where it can be stored? Common examples:

• GDPR: personal data of EU residents must stay in the EU → use West Europe, North Europe, or another EU region
• US government data: regulated workloads may require Azure Government
• Australian health data: some regulations require data to stay in Australia → use Australia East or Australia Southeast

If compliance is a hard constraint, it eliminates most regions immediately and simplifies the decision.

Step 2: Latency to your users

If your users are in Germany and your app is deployed in East US, they’ll experience 100–150ms of network latency for every request. For a web application, this is noticeable. Deploy in the region closest to the largest concentration of your users.

Azure provides a latency test tool at azurespeed.com — you can measure your actual latency from your location to each Azure region before committing.

Step 3: Service availability

Not every Azure service is available in every region. Newer services often launch in East US or West Europe first and roll out to other regions over months. If your application requires a specific service (like Azure OpenAI, a particular VM SKU, or Azure Confidential Computing), check that the service is available in your target region before designing around it.

# List all Azure regions
az account list-locations --output table

# Check which VM SKUs are available in a specific region
az vm list-skus \
  --location "westeurope" \
  --size "Standard_D" \
  --output table

Step 4: Pricing

Azure pricing varies by region. East US tends to be the cheapest region. West Europe, Australia, and South America are typically 10–30% more expensive for equivalent resources. For cost-sensitive workloads (batch processing, dev environments), choose a cheaper region if latency and compliance allow. Use the Azure Pricing Calculator with your target region selected to compare costs.

Step 5: Paired region for disaster recovery

If you’re building for high availability, choose a primary region that has a paired region you’re also willing to use as your DR target. Check that the paired region also meets your latency, compliance, and service availability requirements.

The EU data residency case study

A fintech startup based in Berlin is building a payment processing application. Their legal team has confirmed that all customer transaction data must remain within the EU to comply with GDPR and their banking license conditions.

Here is how they evaluate regions:

1. Compliance filter: Only EU geography regions qualify: West Europe (Netherlands), North Europe (Ireland), France Central, Germany West Central, Sweden Central, Poland Central, Italy North.
2. Latency: Most users are in Germany and Austria. Germany West Central (Frankfurt) is the lowest-latency option. West Europe (Netherlands) is also fast.
3. Availability zones: Both Germany West Central and West Europe support availability zones — required for their uptime SLA.
4. Service availability: They need Azure OpenAI and Azure Payment HSM. Azure OpenAI is available in West Europe. Germany West Central has more limited coverage for some AI services.
5. Pair for DR: West Europe pairs with North Europe (Ireland). Germany West Central pairs with Germany North.
6. Decision: Primary region: West Europe (Netherlands). DR region: North Europe (Ireland). Both are in the EU, have availability zones, and cover their required services.

This walkthrough applies to most region selection decisions — start with hard constraints, then optimize for the remaining factors.