22/10/2026 9 min

Elencare tutte le regioni Azure con PowerShell e Cloud Shell

Quando devi capire in quali aree geografiche Azure è effettivamente presente, il portale non basta sempre. Per inventari, audit, automazioni e controlli di governance conviene interrogare l’API di Azure direttamente da PowerShell, anche dentro Cloud Shell. In questo modo ottieni l’elenco aggiornato delle regioni, con i relativi nomi tecnici, i display name e, se serve, anche attributi utili per filtrare le aree disponibili per una sottoscrizione o per una cloud specifica.

Il punto chiave è distinguere tra tre concetti che spesso vengono confusi: la lista globale delle regioni di Azure, le regioni effettivamente abilitate per la tua subscription, e le location che puoi usare per un servizio specifico. Se ti interessa una risposta operativa, non limitarti al portale: usa i cmdlet del modulo Az o, in Cloud Shell, lo stesso stack senza installazioni locali.

Che cosa stai davvero interrogando

In Azure esistono metadati sulle regioni che arrivano da più livelli. Il comando più utile per un inventario generale è quello che restituisce le location note alla sottoscrizione corrente o al tenant. In pratica, il risultato può includere aree fisiche, aree geografiche speciali, zone governative o cloud sovrani, a seconda dell’ambiente in cui ti trovi.

Se vuoi un elenco “di piattaforma”, il riferimento più semplice è Get-AzLocation. Se invece vuoi capire quali regioni siano accettate da uno specifico resource provider o da un servizio, devi fare un passo in più e interrogare anche le capability del provider. Per questo articolo ci concentriamo sul caso più comune: ottenere e filtrare tutte le regioni Azure con PowerShell, sia in locale sia da Cloud Shell.

Prerequisiti minimi in PowerShell e Cloud Shell

In locale ti serve il modulo Az installato e una sessione autenticata. In Cloud Shell, invece, il modulo è già disponibile e l’autenticazione è agganciata al tuo account Azure. Questo è il motivo per cui Cloud Shell è spesso la via più rapida quando devi verificare una lista di regioni senza toccare il tuo laptop o senza dover gestire versioni del modulo.

Se lavori in una console PowerShell locale, verifica prima la presenza del modulo e la connessione alla subscription corretta. Un errore banale qui porta a risultati incompleti o, peggio, riferiti a un tenant diverso da quello che ti aspettavi.

Recuperare l’elenco completo delle regioni con Get-AzLocation

Il comando base è questo:

Get-AzLocation

Il risultato contiene in genere proprietà come Location, DisplayName, PairedRegion e altri campi utili a seconda della versione del modulo. Per un output più leggibile puoi selezionare solo i campi che ti servono:

Get-AzLocation | Select-Object Location, DisplayName, PairedRegion

Se vuoi esportare i dati in una tabella ordinata, usa Format-Table oppure, meglio ancora, una struttura esportabile in CSV o JSON. Per esempio, in ottica di automazione, il CSV è comodo per inventari rapidi, mentre il JSON è più adatto se il dato verrà letto da un altro script.

Get-AzLocation | Select-Object Location, DisplayName, PairedRegion | Sort-Object DisplayName | Export-Csv -Path .\azure-regions.csv -NoTypeInformation -Encoding UTF8

Se stai usando Cloud Shell, il comando è identico. La differenza pratica è che non devi installare nulla e puoi salvare il file direttamente nell’area persistente montata nella tua home.

Elencare le regioni da Cloud Shell senza installazioni locali

Cloud Shell è utile quando devi lavorare da una postazione temporanea o quando vuoi evitare problemi di versione del modulo. Apri Cloud Shell dal portale Azure, scegli PowerShell come ambiente e lancia il comando base. La sessione è già autenticata con il tuo account, quindi spesso il primo test è semplicemente verificare che la subscription attiva sia quella giusta.

Get-AzContext

Se il contesto non è quello atteso, cambialo prima di fidarti dei risultati. Questo vale ancora di più quando lavori su più tenant o su sottoscrizioni con naming simile.

Get-AzSubscription | Select-Object Name, Id, TenantId

Per impostare la subscription attiva, usa:

Set-AzContext -SubscriptionId <subscription-id>

Una volta fissato il contesto, rilancia Get-AzLocation. In Cloud Shell il vantaggio operativo è che puoi concatenare il comando con filtri e export senza preoccuparti di compatibilità locale o di aggiornamenti del modulo su macchine diverse.

Filtrare per area geografica, nome o paese

Spesso non ti serve tutta la lista, ma solo un sottoinsieme. Per esempio, puoi voler cercare tutte le regioni che contengono “europe”, oppure verificare quelle con nome tecnico che inizia con una certa sigla. In questi casi PowerShell è più comodo del portale perché ti consente di filtrare in modo ripetibile.

Get-AzLocation | Where-Object { $_.DisplayName -like '*Europe*' } | Select-Object Location, DisplayName

Se vuoi filtrare per nome tecnico, il campo Location è quello da usare. Tieni presente che il nome visualizzato e il nome tecnico non coincidono sempre: ad esempio, il display name può essere leggibile per gli umani, mentre Location è quello che userai in template e script.

Get-AzLocation | Where-Object { $_.Location -match '^(westeurope|northeurope)$' } | Select-Object Location, DisplayName, PairedRegion

Se il tuo obiettivo è capire quali regioni siano compatibili con una policy o con un deploy, il filtro per display name non basta. In quel caso conviene normalizzare i dati e lavorare sul campo tecnico. È una piccola differenza, ma evita errori fastidiosi quando porti il codice in automazione.

Ottenere una lista pulita e leggibile

Il risultato grezzo di Get-AzLocation è utile, ma in un report spesso vuoi una colonna ordinata e un formato compatto. Ecco un esempio che produce una tabella chiara per lettura manuale:

Get-AzLocation | Sort-Object DisplayName | Format-Table Location, DisplayName, PairedRegion -AutoSize

Se invece devi passare il dato a un altro processo, meglio un oggetto serializzabile:

Get-AzLocation | Sort-Object DisplayName | Select-Object Location, DisplayName, PairedRegion | ConvertTo-Json -Depth 3

Questo approccio è più robusto del copiare e incollare da una tabella del terminale. In particolare, se devi archiviare il dato o confrontarlo nel tempo, JSON o CSV sono formati più affidabili rispetto a un output formattato per il display.

Confrontare regioni disponibili e regioni realmente usabili

Una trappola frequente è assumere che tutte le regioni restituite siano automaticamente utilizzabili in ogni contesto. Non è così. Alcuni servizi non sono presenti ovunque, alcune subscription hanno restrizioni, e alcuni cloud sovrani hanno un set differente di location. Quindi l’elenco globale è solo il primo livello di verifica.

Per un controllo più aderente al servizio, puoi interrogare il provider specifico. Per esempio, per capire dove è disponibile un resource provider, puoi usare i metadati di Azure Resource Manager. Il comando varia in base al tipo di risorsa, ma il principio resta lo stesso: non fidarti del solo elenco generale se il deploy deve finire in una regione precisa.

Get-AzResourceProvider -ProviderNamespace Microsoft.Web | Select-Object ProviderNamespace, ResourceTypes

Questo non sostituisce Get-AzLocation, ma lo completa. Se il tuo scopo è capire dove puoi deployare una specifica risorsa, devi incrociare il dato di piattaforma con quello del servizio.

Usare il dato in uno script di inventario

Un caso d’uso concreto è l’inventario periodico delle regioni supportate. Per esempio, puoi generare un file giornaliero e confrontarlo con il precedente per rilevare cambiamenti nella piattaforma o differenze tra ambienti. Un semplice script può salvare l’output in una directory di lavoro o in una share controllata.

$regions = Get-AzLocation | Select-Object Location, DisplayName, PairedRegion | Sort-Object Location $regions | Export-Csv -Path .\azure-regions-$(Get-Date -Format yyyyMMdd).csv -NoTypeInformation -Encoding UTF8

Se vuoi un controllo più stretto, puoi anche confrontare due snapshot con Compare-Object. È utile quando vuoi sapere se una regione è comparsa o sparita rispetto a un’esecuzione precedente.

Compare-Object (Get-Content .\old.txt) (Get-Content .\new.txt)

In produzione o in contesti con audit, conviene registrare anche timestamp, subscription e tenant. Il dato sulle regioni da solo è utile, ma senza contesto rischia di diventare poco verificabile nel tempo.

Controlli pratici quando il risultato non torna

Se il comando restituisce meno regioni del previsto, i motivi più comuni sono tre: contesto sbagliato, modulo non aggiornato, oppure ambiente Azure con restrizioni particolari. In ordine di probabilità, io controllerei prima il contesto, poi la versione del modulo e infine il tipo di cloud su cui stai lavorando.

Per vedere la versione del modulo:

Get-Module Az -ListAvailable | Select-Object Name, Version

Per verificare il cloud corrente:

Get-AzContext | Select-Object Name, Subscription, Tenant, Environment

Se lavori in Azure Commercial, Azure Government o in un cloud nazionale, l’elenco delle regioni può differire in modo netto. Non dare per scontato che una regione presente nel cloud pubblico esista anche nel tuo ambiente. Questo è uno dei motivi per cui conviene sempre leggere il dato direttamente dalla sessione autenticata.

Quando usare Cloud Shell e quando la shell locale

Cloud Shell è la scelta più rapida se devi fare una verifica occasionale, condividere un comando con il team o evitare dipendenze locali. La shell locale è preferibile quando devi integrare il comando in una pipeline, usare file già presenti sul filesystem o gestire un flusso di automazione più ampio.

Se il tuo obiettivo è solo “dammi l’elenco delle regioni Azure adesso”, Cloud Shell vince per semplicità. Se invece stai costruendo un controllo ripetibile, la shell locale con script versionato è più adatta. In entrambi i casi il comando di base resta lo stesso, e questo è il vantaggio di lavorare con il modulo Az: una sintassi abbastanza stabile tra ambienti diversi.

Esempio completo di sessione operativa

Qui sotto c’è un flusso essenziale che puoi eseguire quasi identico in locale o in Cloud Shell. Prima controlli il contesto, poi estrai le regioni, infine esporti il risultato.

Get-AzContext
Get-AzLocation | Select-Object Location, DisplayName, PairedRegion | Sort-Object DisplayName
Get-AzLocation | Select-Object Location, DisplayName, PairedRegion | Export-Csv .\regions.csv -NoTypeInformation

Se vuoi limitarti a poche regioni note, usa un filtro esplicito. È più leggibile e più sicuro di un pattern troppo generico che potrebbe includere valori inattesi.

$wanted = 'westeurope','northeurope','francecentral'
Get-AzLocation | Where-Object { $_.Location -in $wanted } | Select-Object Location, DisplayName, PairedRegion

Questo schema è pratico anche per documentare una baseline interna. Se domani un collega chiede quali regioni sono visibili dalla subscription, hai già il comando pronto e un output confrontabile.

Nota finale su accuratezza e manutenzione

Le regioni Azure non sono un elenco statico da memorizzare una volta per tutte. Cambiano, si arricchiscono, e in certi casi possono avere differenze tra cloud e tenant. Per questo il modo corretto di lavorare è interrogare Azure al momento, non affidarsi a una lista copiata in un documento vecchio. PowerShell e Cloud Shell ti danno proprio questo: un dato vivo, verificabile e pronto da riusare in script, audit e check operativi.