By David,
Azure Virtual Desktop session hosts can run in any Azure region, but the service's metadata (your host pools, application groups and workspaces) is stored in a geography or, for regional host pools, a single region you choose when you create the host pool. That choice is fixed: it can't be changed later, and AVD objects can't be moved to another region. The metadata is names and configuration, not user data; documents, profiles and app data stay in the regions where you put your session hosts and storage.
The short version: Pick a host pool region in the geography where your metadata must live, from the list below. Put session hosts in the region closest to your users, which can be any Azure region. In East US 2 and Central US you can also choose a Regional deployment scope, which keeps metadata in that one region; Microsoft says creating new geographical host pools will be deprecated at a future date. Because the scope and location are set at creation, choose deliberately.
This expands the metadata section of our Azure regions directory. Everything below is from Microsoft Learn as of November 2026, with each source linked.
Geographical and regional host pools
AVD now has two deployment scopes (data locations):
| Geographical (default) | Regional | |
|---|---|---|
| Where metadata is stored | "in the geography associated with the Azure region you choose" | "within the single Azure region you choose" |
| How it's protected | Encrypted at rest, with "geo-redundant mirrors... maintained within the geography" | "Replicas are maintained across availability zones within the Azure region, with metadata replicated to a paired region (where applicable)" |
| Where it's offered | The regions listed below | Central US and East US 2 |
Regional host pools became generally available in September 2026 (what's new). In regions that don't support them yet, "the Deployment scope option is not offered, and host pools are created as geographical." In PowerShell, New-AzWvdHostPool -DeploymentScope Regional creates one; without the parameter, the scope is Geographical (regional host pools).
Rules that catch people out (service architecture and resilience):
- "Deployment scope is set when the object is created and cannot be changed afterwards."
- Regional and geographical objects can't be mixed: a regional host pool can only be in a regional workspace. The scope applies to workspaces, application groups and App Attach packages too.
- Microsoft says "at a future date the ability to create new geographical host pools will be deprecated" (regional host pools).
AVD metadata geographies
The geographies Microsoft lists for geographical host pools (data locations):
| Geography | Code |
|---|---|
| Asia Pacific | (none listed) |
| Australia | AU |
| Canada | CA |
| Europe | EU |
| India | IN |
| Japan | JP |
| Korea | KR |
| South Africa | ZA |
| United Kingdom | UK |
| United States | US |
Asia Pacific was added as a data location in March 2025 (what's new).
Regions where you can create host pools, workspaces and application groups
Microsoft's prerequisites list these regions for AVD's service objects (prerequisites):
| Americas | Europe and Africa | Asia Pacific |
|---|---|---|
| Canada Central | North Europe | Australia East |
| Canada East | West Europe | Central India |
| Central US | UK South | East Asia |
| East US | UK West | Japan East |
| East US 2 | South Africa North | Japan West |
| North Central US | Southeast Asia | |
| South Central US | ||
| West Central US | ||
| West US | ||
| West US 2 | ||
| West US 3 |
Two notes on that list. Microsoft says West US 3 "isn't supported for automated host pools (host pools that use session host configuration)." And although Korea (KR) is listed as a geography, no Korea region appears in the list of regions, and Microsoft doesn't publish which regions map to which geography. If Korea residency matters to you, confirm with Microsoft before you design around it.
What AVD stores, and what it doesn't
Stored as metadata (data locations): host pool, application group and workspace names, user principal names, application names and VM names. It's "the same data you can access using the Azure Virtual Desktop portal, PowerShell, or Azure command-line interface (CLI)."
Not stored by the service: "The Azure Virtual Desktop service doesn't directly store any user data or application-related data, such as user-created Word documents, databases or configuration files." User data and app settings "reside in the Azure region you choose", meaning your session hosts and storage such as FSLogix profile shares.
Stored outside the chosen geography:
- Azure Resource Manager paths, which count as organizational information, so data residency doesn't apply to them.
- Diagnostic data from user connections, which goes to the location closest to the user and to the host pool's location.
- Aggregated service-generated data, which is sent to the US geography. Microsoft says customer data isn't aggregated.
Session hosts: any region
"Session hosts for the user sessions can be located in any Azure region, and on-premises when using Azure Virtual Desktop on Azure Local" (prerequisites). Microsoft's gateway service "enables session hosts to be in any region and still be accessible to users" (service architecture). So a host pool whose metadata is in the US geography can have session hosts in, for example, Mexico Central, as long as that meets your residency requirements.
Choose the session host region for latency: Microsoft recommends round-trip time from the client's network to the host pool's region "less than 150 ms." See Azure latency by region.
Can you move AVD to another region?
Not the AVD objects themselves. Host pools, application groups, workspaces, scaling plans and App Attach packages can move to another resource group or subscription, but not to another region (move support). To change region, create new objects in the target region, add session hosts there, assign users, and retire the old ones. Session hosts are ordinary VMs, usually rebuilt from your image rather than moved.
How the AVD service stays available
Microsoft runs AVD's own components in "around 40 Azure regions", with "at least six distinct and separate instances or clusters of each component" in each, and redirects traffic "to the next closest available instance in the nearest region" if one fails. A database failover briefly stops new connections but "doesn't affect existing connections" (service architecture and resilience). Your session hosts and storage are still yours to make resilient: see availability zones.
Azure Government and other clouds
"Azure Virtual Desktop is also available in sovereign clouds, such as Azure for US Government and Azure operated by 21Vianet in China" (prerequisites). Microsoft doesn't publish a separate region list for them on these pages. See Azure Government regions.
How Atlas AVD helps
Atlas AVD deploys host pools and session hosts into the regions you choose and shows them in one console whichever region they're in. The metadata location is still set by Azure when the host pool is created, so decide on it before you deploy.
FAQ
Where is Azure Virtual Desktop metadata stored?
In the geography associated with the region you create the host pool in, or, for a regional host pool, in that single region. It's names and configuration, not user data.
Can AVD session hosts be in a different region from the host pool?
Yes. Session hosts can be in any Azure region, or on-premises with Azure Local. Microsoft recommends placing them in the region closest to your users.
What is a regional host pool in AVD?
A host pool whose metadata is stored in one Azure region instead of a geography. It's available in East US 2 and Central US, became generally available in September 2026, and the scope can't be changed after creation.
Can I move an Azure Virtual Desktop host pool to another region?
No. AVD objects can move between resource groups and subscriptions, but not regions. Create new objects in the target region instead.
Which geographies can store AVD metadata?
Asia Pacific, Australia, Canada, Europe, India, Japan, Korea, South Africa, the United Kingdom and the United States, as of November 2026.
Details are from Microsoft Learn as of November 2026: data locations, prerequisites, regional host pools, service architecture and resilience, what's new and move support for resources.