Azure Virtual Desktop regional host pools (preview)
- Azure Virtual Desktop regional host pools: la novità che cambia la resilienza del control plane
- Geographical vs Regional: qual è la differenza vera?
- Benefici: perché dovresti interessartene
- Preview: regioni supportate e limitazioni importanti
- Un concetto da non sbagliare: “Deployment Scope” e non-interoperabilità
- Come abilitare la preview (opt-in)
- Creare un regional host pool (PowerShell e portale)
- Quando usarli: scenari pratici
- Migrazione: cosa aspettarsi
- Checklist rapida (prima di provarli in produzione)
- Conclusione
Azure Virtual Desktop regional host pools: la novità che cambia la resilienza del control plane
Azure Virtual Desktop (AVD) introduce i regional host pools, un nuovo tipo di host pool pensato per aumentare la resilienza dell’infrastruttura di backend e ridurre le dipendenze “cross-region” del piano di controllo (control plane). La feature è in public preview e convive con il modello storico, chiamato geographical host pools.
Geographical vs Regional: qual è la differenza vera?
Nel modello geographical, i metadati degli oggetti AVD (host pool, workspace, app group) sono archiviati in un database “di geografia”, replicato per resilienza anche su una regione accoppiata (paired region). Il problema? Una dipendenza centralizzata: un incidente sul database o sulla regione che lo ospita può propagare impatti a host pool di altre regioni appartenenti alla stessa geografia.
Con i regional host pools, Microsoft sta distribuendo database e infrastruttura di backend in ogni regione AVD supportata, in modo che l’impatto di un outage tenda a restare confinato alla regione del metadato (pur mantenendo replica locale e failover su paired region). In pratica: meno dipendenze incrociate, più controllo sulla collocazione dei metadati (data sovereignty).

Benefici: perché dovresti interessartene
- Resilienza maggiore: riduzione della “blast radius” legata a problemi su database/regioni del control plane.
- Data sovereignty: possibilità di allineare i metadati dell’host pool alla regione scelta.
- Direzione chiara: Microsoft prevede in futuro di deprecare la creazione di nuovi host pool geografici e, successivamente, di ritirare l’infrastruttura geografica (tempistiche da comunicazioni future).
Non cambia la funzionalità “di superficie” per l’utente finale: cambiano soprattutto infrastruttura e resilienza dietro le quinte.
Preview: regioni supportate e limitazioni importanti
Al momento della preview, i regional host pools sono supportati inizialmente solo in East US 2 e Central US. Le regioni abilitate aumenteranno nel tempo con un rollout graduale.
Inoltre, in preview ci sono limitazioni che impattano il design: ad esempio App Attach non è supportato sui regional host pools durante la preview, e ci sono limitazioni anche su Private Link, dynamic autoscaling, session host update e sulla reportistica di errori/checkpoint verso Log Analytics.

Un concetto da non sbagliare: “Deployment Scope” e non-interoperabilità
I regional host pools introducono un nuovo parametro/concetto: Deployment Scope (Geographical o Regional). Durante il periodo di coesistenza, gli oggetti AVD devono restare nello stesso scope: non puoi, ad esempio, agganciare un application group “Regional” a un workspace “Geographical”, e viceversa.
Come abilitare la preview (opt-in)
L’accesso alla preview è opt-in e controllato dall’amministratore. Puoi abilitarla via PowerShell o dal portale (Preview Features) registrando la feature AVDRegionalResourcesPublicPreview.
PowerShell (registrazione feature)
Register-AzProviderFeature -ProviderNamespace Microsoft.DesktopVirtualization -FeatureName AVDRegionalResourcesPublicPreview
Azure Portal (registrazione feature)
- Subscriptions –> select your subscription.
- Go to: Settings –> Preview Features
- Filter using AVDRegionalResourcesPublicPreview
- Select AVDRegionalResourcesPublicPreview
- Click on Register
Per creare host pool regional via PowerShell è richiesto anche un modulo Az.DesktopVirtualization in versione preview (come indicato da Microsoft).

Creare un regional host pool (PowerShell e portale)
In PowerShell, la creazione avviene aggiungendo il parametro -DeploymentScope Regional ai comandi di creazione dell’host pool (il default, se omesso, resta Geographical).
New-AzWvdHostPool -DeploymentScope Regional [...]
Nel portale, quando disponibile nella tua subscription/region, vedrai un campo Deployment scope durante la creazione dell’host pool. Il campo compare solo scegliendo regioni che supportano il backend “regional” (in preview: East US 2 e Central US).
Quando usarli: scenari pratici
- Ambienti enterprise multi-regione: vuoi ridurre gli impatti “a catena” sul control plane.
- Requisiti di sovranità del dato: vuoi controllare dove risiedono i metadati degli oggetti AVD.
- Nuove implementazioni: se devi creare host pool da zero, ha senso iniziare a pianificare già sul modello regional (tenendo conto della preview).
Migrazione: cosa aspettarsi
Microsoft indica che verranno forniti strumenti per supportare la transizione da oggetti geografici a regional, ma nel frattempo l’approccio più pragmatico è: creare nuovi host pool regional con configurazione equivalente e migrare progressivamente gli utenti (pilot → rollout).
Checklist rapida (prima di provarli in produzione)
- Verifica che la tua regione target supporti i regional host pools (in preview: East US 2 / Central US).
- Valuta l’impatto delle limitazioni preview (App Attach, Private Link, autoscaling, session host update, Log Analytics).
- Allinea tutti gli oggetti AVD sullo stesso Deployment Scope (host pool, app group, workspace).
- Pianifica pilot e rollback (pool parallelo) invece di “upgrade in-place”.
Conclusione
I regional host pools sono una di quelle novità “silenziose” che non cambiano l’esperienza utente, ma migliorano l’affidabilità del servizio nel tempo. Se stai pianificando nuove implementazioni AVD o stai rivedendo la tua strategia di resilienza, vale la pena tenerli nel radar già adesso, con la prudenza dovuta a una preview.