Business Challenge
A team stands up its first Azure environment in the region the tutorial used. Eighteen months later two things arrive in the same week. Legal asks, for a customer contract, exactly which country the data sits in and what guarantees that. And an architect asks why a service the roadmap depends on cannot be provisioned in that region.
Both questions have the same root. The region was chosen as a preference — the nearest one, or the default, or the one in the screenshot — and it is not a preference. It fixes a data residency boundary, it determines which resiliency options are even available, and it decides which services exist at all.
There is also a worse version of this story, and it is the one worth reading the rest of the post for. Some organisations discover that their compliance obligations require a sovereign cloud. That is not a region they can move into. It is a different deployment of Azure, and there is no migration path from the one they are in.
Region is a set of datacenters. Geography is a data residency boundary containing one or more regions. Sovereign cloud is a separate Azure with its own endpoints, its own portal and its own directory. Conflating the first two produces a compliance answer that is nearly right; conflating the second two produces a migration plan that cannot be executed.
Architecture
Azure provides over 70 regions globally, arranged inside geographies.
A region is buildings and fibre
A region consists of one or more datacenters connected by a high-capacity, fault-tolerant, low-latency network, typically located within a single large metropolitan area. That last detail is the one that matters for resilience thinking: a region is a place, close enough together to share a metropolitan area, and therefore close enough together to share a flood plain or a power grid.
That is what availability zones exist to address inside a region, and what multi-region designs exist to address between them. Both are later posts — #7 and #47 — but the reason for both is contained in that one sentence about metropolitan areas.
A geography is a promise, not a place
Every region sits inside exactly one geography, and a geography is a fixed data residency boundary — the United States, Europe, India. If you have data residency requirements, the geography is the thing you are actually selecting; the region is how you pick a spot inside it.
One useful guarantee comes with it: each geography has at least one region equipped with availability zones. So "we must stay in this geography" never forces you out of zonal resilience entirely, though it may narrow which region provides it.
Region pairs, and why newer regions have none
Microsoft pairs some regions with one other region. You cannot choose the pair — it is assigned — and some Azure services use pairing for geo-replication and geo-redundancy.
The part that surprises people building today: many newer regions are not paired at all, and instead use availability zones as their primary means of redundancy. A design that assumes every region has a partner will be wrong in exactly the regions most likely to be opened next. #8 takes this apart properly, including what pairing does and does not promise.
The services that are nowhere
Not everything is deployed to a region. Microsoft deploys nonregional services across two or more regions, so that a regional failure leaves a healthy instance serving requests. Some of them still let you constrain data: Entra ID, for instance, lets you select the geographic area its data is held in.
This matters for a business continuity plan, because these services do not appear in a regional failure analysis and yet everything depends on them.
Why This Architecture Holds Up
Sovereign cloud regions "work the same way as other regions" in the sense that the concepts transfer — you still have resource groups, still deploy templates, still assign roles. What does not transfer is everything around them.
Different endpoints, everywhere
The portal is portal.azure.us, not portal.azure.com. Resource Manager is management.usgovcloudapi.net, not management.azure.com. Sign-in is login.microsoftonline.us. Storage, Key Vault and the rest all follow. Every hardcoded hostname in your tooling is wrong until it is changed.
Fewer services, and different features
Services available in specific regions of global Azure might not exist there at all, and feature configurations can differ where the service does exist. Sample code and configuration written against global Azure needs reviewing rather than copying.
No path between them
Data cannot be moved from global Azure to Azure Government. A Log Analytics workspace cannot be migrated across. The portals are separate and share no information. Azure Lighthouse cannot delegate subscriptions across the boundary — nor between two national clouds.
What you get for it
Both clouds are assessed at FedRAMP High. Azure Government adds contractual commitments: customer data stored in the United States, and access to systems processing it limited to screened US persons. Those commitments, not the technology, are the reason to be there.
Read that third card as the architectural point of the whole post. Region choice is reversible with effort — resources can be redeployed, data can be copied, DNS can be repointed. Cloud choice is not. An organisation that builds in global Azure and later learns it needed Azure Government is not migrating; it is rebuilding, in an environment where some of what it built may not exist.
Rather than collecting hostnames by hand, ask the tooling. az cloud show --name AzureUSGovernment returns that cloud's endpoints, and Get-AzEnvironment -Name AzureUSGovernment does the same from PowerShell. Anything that needs to work in more than one cloud should be reading endpoints from there rather than carrying a hardcoded list.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| What you are actually choosing first | The geography, then the region within it | The geography is the fixed data residency boundary and the thing a compliance obligation names. The region is where inside it you land. |
| Which region within a geography | One with availability zones, unless something rules it out | Every geography has at least one, and zonal resilience is the cheapest redundancy available. Starting in a region without zones means the option is gone until you move. |
| Designing for region pairs | Do not assume a pair exists | Many newer regions are unpaired by design and use zones instead. A DR plan built on pairing quietly excludes the regions you are most likely to expand into. |
| Sovereign cloud | Decide before the first deployment, from the compliance obligation | There is no migration path. This is the one decision on this list that cannot be corrected later at any price. |
| Tooling that may run in more than one cloud | Resolve endpoints from az cloud show or Get-AzEnvironment | Hardcoded hostnames are the most common reason a working pipeline fails on its first sovereign deployment, and they fail one service at a time. |
| Business continuity planning | List the nonregional services separately | They do not appear in a regional failure analysis because they are not in a region, and every workload depends on some of them. |
Closing Thought
Almost every Azure decision can be revisited. Resources move, templates are rewritten, subscriptions are reorganised. The geography is harder, because data residency obligations are external and do not negotiate. The cloud is hardest, because there is no supported way across.
Which makes this worth a conversation at the start rather than a dropdown in the middle: what must be true about where this data lives, and who must be able to touch the systems holding it. Everything else in the region choice is latency and service catalogue, and both of those you can work with.
#7 goes inside the region: what an availability zone actually is, what the physical separation buys you, and what a zone-redundant service is really promising when it says it survives a zone failure.
Comments