Cloud computing sounds placeless, but it is anything but. Let us see why “where” is one of the first questions to ask.

What is an Azure geography?

An Azure geography is a defined area of the world that contains at least one, and usually two or more, Azure regions. It is designed to keep customer data and applications inside a certain market with a shared set of laws and rules about data. Examples include the United States, Europe, India, Japan, Australia, and the United Kingdom.

A geography is not the same as a country. Some geographies match a single country, such as Japan or India. Others cover many countries, such as Europe. The purpose is to give you a clear boundary that says: “if I choose this geography, my data stays in this area.”

Four reasons location matters

• Law and trust. Many countries have rules about where personal, financial, or health data may be stored. Choosing the wrong place can break the law or a contract.
• Speed. Data travels fast, but not instantly. Placing your app close to your users makes it feel quicker.
• Resilience. Floods, fires, power cuts, and software mistakes happen. Spreading your app across separate locations keeps it alive when one location fails.
• Price and features. Prices differ from one region to another, and new services often arrive in some regions before others.

A short history

Azure launched for the public in 2010 with data centers in a handful of places in the United States, Europe, and Asia. Demand grew fast, and so did the map. Microsoft kept adding regions, partly to be near customers and partly to meet local laws that require data to stay in a country. Today Azure has more than sixty regions, and new ones open every year, so the official map is the place to confirm the latest list.

Azure’s physical world is built like a set of nested boxes. Each box has its own job.

The five levels

flowchart TB
    World["Azure global infrastructure"] --> GeoA["Geography: Europe"]
    World --> GeoB["Geography: United States"]
    World --> GeoC["Geography: India"]
    GeoA --> R1["Region: North Europe"]
    GeoA --> R2["Region: West Europe"]
    R2 --> Z1["Availability Zone 1"]
    R2 --> Z2["Availability Zone 2"]
    R2 --> Z3["Availability Zone 3"]
    Z1 --> DC["One or more datacenters"]

Read the picture from the top. Azure’s world is split into geographies. The Europe geography holds regions such as North Europe and West Europe. West Europe in turn has three availability zones, and each zone is made of one or more data centers. When you create a resource, you point at a region. The zone choice is optional, and the geography is decided for you by the region you pick.

Why so many layers?

Each layer solves a different problem. Geographies solve legal and market problems. Regions solve distance and capacity problems. Zones solve building-level failure problems. Datacenters are simply where the machines live. Thinking in layers lets you ask the right question at the right level: “Which geography satisfies my legal needs? Which region is nearest my users? How many zones should I spread across?”

The geography is the most important decision for anyone who cares about where data is allowed to live.

What a geography promises

Microsoft designs each geography as a data residency boundary. When you store customer data in a region, the data stays inside the geography that region belongs to, with limited exceptions for certain global services. Replication for safety, such as copying a database to a second region, normally stays inside the same geography too. This gives lawyers and auditors a clear sentence they can write in a contract: “Data is stored in the Europe geography.”

Geographies also help with sovereignty, which means a country’s right to control what happens to data inside its borders, and with resiliency, which means the ability to survive failures without leaving the boundary.

Geography groups

Microsoft organizes geographies into larger groups so the map is easier to read. The common groups are the Americas, Europe, Asia Pacific, and the Middle East and Africa.

Treat this table as a sample, not a complete list. Microsoft adds geographies and regions regularly, so always check the official map before you plan.

Geography is not the same as country

Be careful with the word. The Europe geography spans many countries and is served by regions such as North Europe in Ireland and West Europe in the Netherlands. Meanwhile, the India geography is a single country with regions such as Central India in Pune, South India in Chennai, and West India in Mumbai. The Asia Pacific geography, by contrast, includes regions such as Southeast Asia in Singapore and East Asia in Hong Kong. A company that must keep data inside one specific country needs to check whether the geography is one country or many.

Global services are a special case

A few Azure services are not tied to one region. Microsoft Entra ID, which handles sign-in, Azure DNS, and Azure Traffic Manager are examples of services that work across the world. They follow their own data location rules, which we explore in a later chapter. This is why you should read the data location notes for each service you use, instead of assuming a single rule covers everything.

When you create a virtual machine, a database, or a storage account, Azure always asks one question first: which region?

What a region is

An Azure region is a set of data centers placed within a latency-defined area, which means close enough to talk to each other very quickly, joined by a dedicated, high-speed network. A region has a friendly display name such as “West Europe” and a short code used in scripts and templates, such as westeurope. The short code has no spaces and is written in lowercase.

Regions are not all the same

It is tempting to think every region offers every service at the same price. That is not true. Regions differ in several important ways.

• Service availability. New services and features often launch in a few regions first. Some services may never be offered in a smaller region.
• Machine sizes. Certain virtual machine families, especially those with powerful graphics or AI chips, exist only in some regions.
• Price. The same resource can cost more in one region than another because of local costs such as power and land.
• Capacity and quota. A region may be short on capacity for a popular machine type at a given moment. Your subscription also has limits, called quotas, that apply per region.
• Zone support. Some regions have availability zones, and some do not.
• Access. A few regions are special-purpose or require you to request access before you can use them.

Recommended and other regions

Microsoft marks some regions as recommended. These usually have availability zones and broad service support, so they are the safest default for new projects. Other regions are still fully supported, but may have fewer services, no zones, or may exist mainly to serve a specific country or to act as a partner for disaster recovery. When in doubt, pick a recommended region within the geography you need.

A common trap: the resource group location

Every resource group has a location too. That location only tells Azure where to store the metadata, which is the information about the group, such as its name and the list of items in it. The resources inside the group can sit in completely different regions. So a resource group labeled “West Europe” can hold a database in Japan. If you have strict data rules, check the location of each resource, not just the group.

Zones protect you from the failure of a single building, without the delay of moving to a faraway region.

What a zone is

An availability zone is a physically separate location inside a region. Each zone has one or more data centers with its own power supply, cooling, and network connections. If one zone loses power or suffers a fire, the other zones in the same region keep running. In regions that support zones, there are at least three of them, so that if one fails, two remain.

The zones in a region are close enough that data can travel between them in a very short time, with round-trip delay under about two milliseconds. That is fast enough for data to be copied between zones at the moment it is written, which is called synchronous replication.

Zonal and zone-redundant

Azure services use zones in two ways.

A surprising detail: zone numbers are personal

The numbers one, two, and three that you see are logical names, not fixed buildings. Azure maps your subscription’s “zone 1” to a physical zone, and another customer’s “zone 1” may be a different physical zone. This spreads load evenly. It also means that if two of your subscriptions need their resources in the same physical zone, you must look up the mapping rather than assume the numbers match.

What zones do not protect against

Zones guard against failures of a building, but not against everything. A large natural disaster across a whole metropolitan area, a regional network problem, or a software bug that hits an entire region could affect all zones at once. For those risks you need a second region, which brings us to region pairs.

Many Azure regions come with a built-in partner, chosen by Microsoft to help you survive big disasters.

What a region pair is

A region pair links two regions inside the same geography that are far apart from each other, usually hundreds of miles, so that a single disaster is unlikely to hit both. For example, East US is commonly paired with West US, North Europe with West Europe, and UK South with UK West. In India, Central India and South India form a pair.

flowchart LR
    subgraph Geo["One geography: United States"]
        A["East US, primary region"]
        B["West US, paired region"]
    end
    App["Your app and data"] --> A
    A -. asynchronous copy .-> B
    A -->|"Region outage"| Fail["Failover decision"]
    Fail --> B

The picture shows the idea. Your application runs in the primary region. Some services quietly copy data to the paired region in the background. If the primary region has a major outage, a decision is made, either by Azure for some platform services or by you for your own apps, to continue from the partner region.

Benefits of pairing

• Staggered updates. Microsoft does not apply planned platform updates to both regions of a pair at the same time. If an update causes trouble in one, the partner is untouched.
• Prioritized recovery. In a widespread outage, Microsoft prioritizes bringing back at least one region from each pair.
• Same geography. Because both regions sit in one geography, replicated data does not cross a legal boundary.
• Built-in features. Some services use the pair automatically, such as geo-redundant storage, which keeps an extra copy of your files in the partner region.

Things to know about pairs

• Not every region has a pair. Newer regions often rely on availability zones for local resilience and may not have a traditional pair.
• Not every pair stays in the geography. A well-known exception is Brazil South, which is paired with South Central US, outside the Brazil geography. Check pair details if your data rules are strict.
• Pairing does not mean automatic failover for everything. Many services copy data to the partner, but you must plan and test how your own application will switch over.
• Copies are usually asynchronous. Because the regions are far apart, data is copied slightly after it is written, so a very small amount of the latest data could be lost in a sudden disaster. This gap is called the recovery point.

Besides the main public Azure, Microsoft runs separate clouds for governments and for China, plus tools for organizations with special rules.

Why separate clouds exist

Some customers cannot use the shared public cloud at all. A government agency may be required to run on infrastructure that is physically separate and staffed only by screened citizens. A company operating in China must follow local laws that require a local partner to run the service. For these cases, Microsoft offers distinct sovereign clouds. A sovereign cloud is a cloud that is built, operated, and governed so that a particular country or authority keeps control.

What is different in a sovereign cloud

• Separate accounts and endpoints. A normal Azure login does not work in Azure Government or Azure China. They have their own portals and sign-in addresses.
• Different service lists. New features usually arrive later, and some services are not offered at all.
• Stricter compliance. Azure Government supports programs such as FedRAMP High and rules used by defense agencies.
• Separate operations. In Azure China, the day-to-day operation belongs to 21Vianet, not Microsoft.

Microsoft once ran a separate cloud for Germany too. It was later retired, and customers moved to the regular German regions, which offer local data residency without a separate operator. This shows that the map keeps changing as laws and customer needs change.

Not every Azure service lives at the same level of the map. Knowing a service’s scope tells you what it can survive and where its data sits.

Four scopes

• Global. The service is not tied to one region and works worldwide. Example: Microsoft Entra ID, Azure DNS, Azure Front Door.
• Regional. The resource lives in one region. If that region fails, the resource may be unavailable unless you built a copy elsewhere. Example: virtual networks, storage accounts, most databases.
• Zonal. The resource sits in one specific availability zone inside a region. Example: a virtual machine pinned to zone two.
• Zone-redundant. The service is spread over all zones in the region and survives the loss of one zone. Example: zone-redundant storage and zone-redundant databases.

Common services and their scope

Behind the map are cables, networks, and buildings. Let us look at the parts that tie geographies, regions, and zones together.

The Microsoft global network

Microsoft operates one of the largest private networks in the world. It links all regions to each other and to hundreds of edge locations through fiber lines on land and under the sea. When data travels from one Azure region to another, it normally rides on this private backbone rather than crossing the open internet. That makes the path faster, more predictable, and easier to protect.

Inside a region

A region contains several parts. There are the data centers in each availability zone. There is a regional network that joins the zones with very fast links. There are regional front-end services that accept your requests, and there are the resource providers that actually create and manage your resources. Behind all of this stand the control systems that handle capacity, health checks, and updates.

Edge locations and private links

• Edge locations are small points of presence near cities. Services such as Azure Front Door and content delivery networks use them to answer users quickly and to cache popular content.
• Private connections let a company link its own office or data center to Azure without using the public internet. ExpressRoute is the best-known example, and it connects at special meeting-point facilities.
• Peering lets two virtual networks, even in different regions, talk to each other privately over Microsoft’s backbone.

A multi-region application

Here is how a well-designed application might use two regions in one geography.

flowchart TB
    Users["Users around the world"] --> FD["Global front door and DNS routing"]
    subgraph PrimaryRegion["Primary region"]
        LB1["Regional load balancer"] --> App1["App servers across 3 zones"]
        App1 --> DB1["Database with zone redundancy"]
    end
    subgraph SecondaryRegion["Secondary region in the same geography"]
        LB2["Regional load balancer"] --> App2["App servers across 3 zones"]
        App2 --> DB2["Database replica"]
    end
    FD --> LB1
    FD --> LB2
    DB1 -. replication .-> DB2

Follow the arrows from the top. Users reach a global entry point, which is not in any single region. The entry point sends each visitor to a healthy region. Inside each region, a regional load balancer spreads work across servers in three zones. The primary database is zone-redundant, and a replica in the second region receives a continuous copy of the data. If the primary region fails, the front door sends everyone to the second region, where the replica can be promoted to take over.

Three ideas explain most of what happens behind the map: physics, copying, and careful rollout.

Physics: distance costs time

Light travels through fiber at roughly two hundred thousand kilometers per second. That sounds incredibly fast, but over long distances it adds up. A rule of thumb is that every hundred kilometers of fiber adds about one millisecond to a round trip, before counting any equipment along the way. Real routes are never perfectly straight, so real delays are higher.

These numbers explain many design choices. Zones can copy data synchronously, because the wait is tiny. Distant regions usually copy asynchronously, because making every write wait for a faraway confirmation would slow the whole application.

Copying data: synchronous and asynchronous

Synchronous replication means a write is not confirmed until at least two copies exist. It loses no data if a copy fails, but it needs close neighbors. Asynchronous replication confirms the write first and sends the copy a moment later. It allows long distances but risks losing the last few moments of data if a disaster strikes suddenly. Two measurements describe this trade-off.

• Recovery point objective (RPO): how much recent data you can afford to lose, measured in time. Zero means none.
• Recovery time objective (RTO): how long you can afford to be down while you recover.

Careful rollout of changes

Microsoft updates the software that runs Azure all the time. To avoid breaking everyone at once, it uses a practice known as safe deployment: a change goes first to a very small set of servers, then to a larger group, then to a whole region, and only later to other regions. This is also why paired regions are not updated together. If a problem shows up, it is caught while the blast radius is small.

Control plane and data plane

Azure separates the work of managing resources from the work of using them. The control plane is how you create, change, and delete resources, usually through Azure Resource Manager. The data plane is how your application reads and writes the actual data, such as reading a file from a storage account. These two planes can have different failure behavior. A region problem might stop you from creating new resources while existing applications keep serving traffic, or the other way around. Good designs avoid needing the control plane during an emergency, because that is the very moment it may be busy.

Let us follow one visitor’s request through a multi-region app, then watch how a workload lives, moves, and retires.

One request, step by step

sequenceDiagram
    participant U as User
    participant F as Global Front Door
    participant A as App in Primary Region
    participant D as Primary Database
    participant S as Secondary Region
    U->>F: Request page
    F->>A: Route to nearest healthy region
    A->>D: Read and write data
    D-->>A: Result
    A-->>F: Response
    F-->>U: Page delivered
    D->>S: Copy changes asynchronously

The visitor never knows which region answered. The global entry point chooses the nearest healthy one. The application reads and writes its data in the primary region. In the background, changes flow to the secondary region so a recent copy always waits there. If the primary fails, the entry point stops sending people to it, and the secondary takes over from the latest copy.

What happens during a failover

The lifecycle of a workload’s location

Moving between regions

Many people hope they can drag a resource from one region to another. Unfortunately it is rarely that simple. Azure offers a tool called Resource Mover for certain resource types, and some services support a built-in move. For most, the real method is to create a new resource in the new region, copy the data across, update the connections, and delete the old one. Copying data between regions also costs money for the outbound transfer, so plan for it.

Geographies exist mainly so that you can answer a hard question with confidence: where exactly is my data, and who is allowed to touch it?

Three words that sound alike

Choosing a geography helps most with residency. Sovereignty and protection need additional steps, such as strong encryption, careful access rules, and, for some customers, sovereign clouds.

What Microsoft commits to, and what you must do

Microsoft’s public commitment is that customer data stored in a chosen region stays inside the geography, with some documented exceptions, and that copies made for resilience stay in the same geography. For customers in Europe, Microsoft also describes its EU Data Boundary effort, which aims to keep storing and processing customer data for its core cloud services inside the European Union and the neighboring European free-trade countries.

But the responsibility is shared. You choose the region, choose the replication settings, and decide which services to use. A single wrong click can place a copy in a different geography, and Microsoft will not stop you if your account has permission to do it.

Places where data may live elsewhere

• Global services. Some services, such as sign-in and DNS, keep certain information in more than one place. Microsoft Entra ID asks for a country or region when a tenant is created, and that choice determines where the directory data is stored.
• Operational and support data. Information such as service health signals or support tickets may be handled differently from the content of your databases. Read the privacy and data location pages for each service.
• Your own settings. If you turn on cross-region replication, copy backups to another region, or export logs to a workspace elsewhere, you have changed where the data lives.

Tools that enforce your choice

• Azure Policy with allowed locations. A rule that forbids creating resources outside approved regions, even by an administrator.
• Management groups. A way to apply that rule to many subscriptions at once.
• Encryption and key control. Data is encrypted at rest by default, and you can keep your own keys in Azure Key Vault in a chosen region. Microsoft also protects traffic that moves between its data centers.
• Private connectivity. Private endpoints and private links keep traffic off the public internet.
• Compliance programs. Azure publishes reports and certifications such as ISO 27001 and SOC reports, and supports customers with rules such as the European GDPR and the US health privacy law HIPAA.

A multi-region system needs eyes in every region, and a clear idea of what “healthy” means.

Know about Azure’s own problems

• Azure status. A public page showing broad incidents across regions.
• Service Health. A personalized view that shows only the incidents, maintenance, and advisories that affect the services and regions you actually use, with the option to send alerts.
• Resource Health. Tells you whether a specific resource, such as one virtual machine, is healthy, and whether a problem is on Azure’s side.

Watch your own application

flowchart LR
    Svc["Resources in many regions"] --> Mon["Azure Monitor"]
    Mon --> LAW["Log Analytics workspace in a chosen region"]
    Svc --> Health["Resource Health and Service Health"]
    LAW --> Alerts["Alert rules"]
    Health --> Alerts
    Alerts --> Team["Operations team"]
    LAW --> Dash["Dashboards"]

Azure Monitor collects metrics and logs from your resources and stores logs in a Log Analytics workspace. The workspace itself lives in a region, so the choice of region matters both for compliance and for cost. For the best view, many teams keep one workspace per geography to avoid sending logs across borders.

Measure what users feel

• Availability tests from many places. Application Insights can probe your website from several geographic locations, telling you whether users in one part of the world see a problem that others do not.
• Latency between regions. Network Watcher can measure delay and loss between your resources in different regions, so you notice when replication falls behind or a link becomes slow.
• Replication lag. Many databases expose how far behind a replica is. This number is your real-time estimate of how much data you could lose.

Cost by location

Money is a metric too. Cost Management lets you break spending down by region, which shows how much each location costs and where transfer charges are piling up. Data moving into Azure is generally free, but data moving out, including between regions, is billed. A forgotten replication job between two regions can quietly become a large bill.

Practice failure on purpose

The best monitoring is the kind you have tested. Azure Chaos Studio lets teams inject controlled faults, such as simulating the loss of a zone, to see whether alerts fire and failover works. Running such drills on a schedule turns a plan on paper into a plan you can trust.

Spreading your system across more places makes it safer, but also costlier and harder. The art is picking the right level.

The ladder of resilience

You can think of four common levels, each protecting against bigger failures than the one before.

Multiple regions: the good and the bad

Staying in one geography: the good and the bad

Other trade-offs

• Residency versus speed. A strict rule might force data into a faraway geography, making the app feel slower for users elsewhere. Solutions include serving cached content from edge locations or deploying a separate copy in each market.
• Cost versus placement. The cheapest region may be far from users or lack the services you need. A small saving per hour can disappear in transfer charges.
• Newest features versus safest choice. The region that gets new services first may be less mature than the recommended, zone-enabled one.

Teams that use Azure’s map well tend to follow the same few recipes, and teams that struggle tend to repeat the same few mistakes.

Patterns that work

Anti-patterns to avoid

These habits keep location decisions calm and cheap.

Habits worth building

Common mistakes

• Confusing the resource group location with the resource location. Remember that the group’s location holds only metadata.
• Believing “geography” and “country” are the same. Europe is not one country, so a country-specific law needs a country-specific geography.
• Ignoring data transfer charges. Copying large data sets between regions is billed as outbound traffic.
• Assuming every service is in every region. Check before you design around a feature.
• Forgetting that zone numbers are logical. Zone one for you may not be zone one for another subscription.
• Building the backup region once and never touching it again. Over time it drifts, and the failover fails when it matters most.
• Putting the monitoring in the same region as the app. If that region fails, you lose the tools that tell you what happened.

These public examples show how the geography idea turns into real products and promises.

Everyday scenarios

The following are typical, illustrative situations, not reports about specific companies.

• The two-market retailer. An online shop serving Europe and North America deploys one full stamp in a European region and another in a United States region. European customers’ data never leaves Europe, and each stamp grows on its own.
• The cautious bank. A bank keeps its main system in one region of its home geography with zone redundancy, and a warm standby in the paired region. Twice a year it runs a drill, switches to the standby, and measures how long it takes.
• The growing start-up. A start-up begins in a single region near its first customers. As users grow in another continent, it adds a second region with a global entry point so those users get a faster experience.
• The media site. A news site serves pictures and articles through edge locations around the world, while its main database stays in one region. Readers get speed, and the data stays in one place.

A simple order of questions turns a confusing map into a clear choice.

flowchart TD
    Start["Where should this workload live?"] --> Q1{"Do laws or contracts fix where the data may be?"}
    Q1 -- Yes --> G["Pick the geography that satisfies the rule"]
    Q1 -- No --> Q2{"Where are most of your users?"}
    Q2 --> G2["Pick a geography close to them"]
    G --> R["Pick a region inside it that offers your services and quota"]
    G2 --> R
    R --> Q3{"Must it survive a full region outage?"}
    Q3 -- Yes --> M["Add a second region in the same geography, plus zones"]
    Q3 -- No --> Z["Use availability zones in one region"]

A short checklist before you commit

Quick answers to the questions people ask most.

The whole guide in a few lines.