• Cloud, Guide, Sicurezza
• 17 Gennaio 2026

Quando progettate architetture di rete in Microsoft Azure, uno dei temi ricorrenti è come consentire la comunicazione tra risorse distribuite su reti virtuali diverse senza perdere controllo, isolamento e sicurezza. Il peering tra Virtual Network è da tempo la soluzione standard: due VNet vengono collegate e, dal punto di vista del routing, si comportano come se facessero parte della stessa rete. Questo approccio, però, è spesso fin troppo permissivo.

Il subnet peering nasce proprio per risolvere questo limite. Invece di creare una relazione di peering tra intere reti virtuali, potete stabilire la connettività solo tra specifiche subnet, lasciando il resto dell’infrastruttura completamente isolato. In pratica, è un’evoluzione naturale del peering tradizionale che vi consente di ragionare in termini di segmenti di rete e non più di VNet “monolitiche”.

Dal punto di vista operativo, il comportamento resta quello a cui siete abituati: il traffico viaggia sulla rete backbone di Azure, non attraversa Internet pubblico e non richiede gateway, appliance o NAT. La differenza è tutta nel livello di controllo che ottenete.

Quando ha senso usare il subnet peering

Il subnet peering diventa particolarmente interessante negli ambienti complessi, dove la separazione logica e funzionale delle reti è un requisito, non un optional. Pensate, ad esempio, a un’architettura hub-and-spoke evoluta, in cui più team o più applicazioni condividono la stessa VNet spoke ma non devono necessariamente comunicare tra loro. In questi scenari, il peering classico rischia di aprire più di quanto desiderato.

Un altro caso tipico è quello dei contesti multi-tenant o multi-environment, come ambienti di test, staging e produzione che devono accedere a servizi comuni, ma senza instaurare una connettività bidirezionale completa. Con il subnet peering potete esporre solo le subnet che ospitano i servizi condivisi, mantenendo il resto dell’ambiente segregato.

C’è poi il tema, sempre più attuale, della micro-segmentazione. Se adottate un approccio zero-trust o comunque orientato alla riduzione della superficie di attacco, poter decidere quali subnet possono parlarsi e quali no, direttamente a livello di routing, vi semplifica notevolmente la vita e riduce la dipendenza esclusiva da NSG o firewall.

Perché preferirlo al peering tradizionale

Il vero valore del subnet peering sta nella granularità. Non siete più costretti a fare compromessi tra “tutto collegato” e “tutto isolato”, ma potete modellare la connettività in modo molto più aderente alle reali esigenze applicative.

Dal punto di vista della sicurezza, questo si traduce in un’esposizione ridotta e più prevedibile. Meno percorsi di rete implicano meno possibilità di configurazioni errate e meno traffico indesiderato che attraversa ambienti sensibili. Anche la governance ne beneficia, perché le regole diventano più facili da spiegare, documentare e mantenere nel tempo.

Di fatto, quindi, il subnet peering non sostituisce il peering tra VNet, ma lo completa.

Prerequisiti per l’utilizzo del subnet peering

Prima di poter configurare il subnet peering in Azure è necessario soddisfare alcuni prerequisiti specifici, che è importante conoscere fin dalle fasi iniziali di progettazione per evitare blocchi in fase di implementazione.

Prima di configurare il subnet peering è necessario verificare che la subscription Azure sia abilitata alla feature richiesta dal provider Microsoft.Network. Il subnet peering, infatti, non è attivo di default e richiede la registrazione esplicita della funzionalità AllowMultiplePeeringLinksBetweenVnets.

Dal punto di vista della disponibilità geografica, il subnet peering è supportato in tutte le regioni Azure. Tuttavia, al momento non è configurabile tramite il portale Azure. Per la creazione e la gestione dovete necessariamente utilizzare strumenti di automazione o interfacce avanzate, come Terraform, Azure PowerShell, Azure CLI, API REST o ARM template. Questo implica che l’adozione del subnet peering si inserisce naturalmente in contesti Infrastructure as Code e richiede una minima familiarità con questi strumenti.

Figura 1: Diagramma di funzionamento del VNET Subnet Peering

Nello scenario che vi propongo l’obiettivo è abilitare la comunicazione esclusivamente tra la Subnet-1 di VNET-A (10.1.1.0/24) e la Subnet-2 di VNET-B (10.2.2.0/24), mantenendo tutte le altre subnet completamente isolate, nonostante le VNet abbiano più address space e più subnet definite.

Con il peering tradizionale tra VNet, questo requisito non sarebbe soddisfatto: una volta creato il peering tra VNET-A e VNET-B, tutte le subnet di entrambe le reti potrebbero comunicare tra loro, salvo blocchi espliciti tramite NSG o firewall. Dal punto di vista del routing, Azure considererebbe le due VNet come un’unica rete piatta, cosa che nel vostro scenario introdurrebbe una connettività eccessiva e non desiderata.

Il subnet peering, invece, è esattamente lo strumento adatto a questo tipo di esigenza. Potete definire una relazione di peering che espone solo la Subnet-1 di VNET-A verso la Subnet-2 di VNET-B e viceversa. Tutte le altre subnet, come la Subnet-3 e Subnet-4 di VNET-A o la Subnet-1 e Subnet-3 di VNET-B, rimangono fuori dal dominio di routing e quindi non sono raggiungibili, nemmeno accidentalmente.

Dal punto di vista logico, Azure crea rotte solo tra le subnet peered, senza propagare l’intero address space delle VNet. Questo significa che, anche se VNET-A e VNET-B hanno spazi di indirizzi ampi (/16) e multipli, la connettività resta confinata ai soli prefissi /24 che avete deciso di collegare. È un aspetto fondamentale perché vi consente di progettare la rete in modo modulare, evitando di dover “difendere” con regole di sicurezza ciò che non dovrebbe essere raggiungibile in primo luogo.

Nel disegno è inoltre evidente un altro vantaggio: VNET-C, pur avendo address space parzialmente sovrapposti a VNET-A, non entra in conflitto con questo scenario perché il subnet peering opera a livello di subnet specifiche e non di VNet complete. Questo vi permette di mantenere ambienti separati e controllati anche in presenza di indirizzamenti complessi o legacy.

Qui di seguito sono mostrate le subnet e gli indirizzi della VNET-A e della VNET-B

Figura 2: Subnet della VNET-A

Figura 3: Subnet della VNET-B

Creazione del subnet peering

Per la creazione dei subnet peering utilizzeremo Azure Cloud Shell e Azure CLI. Come per il peering tradizionale tra Virtual Network, anche il subnet peering richiede la configurazione di entrambe le relazioni di peering, una per ciascun lato, in modo da rendere effettiva la connettività bidirezionale tra le subnet coinvolte.

Di seguito è riportato il comando Azure CLI per la creazione del subnet peering da VNET-A verso VNET-B. In questo esempio viene stabilita la connettività esclusivamente tra la subnet-1 di VNET-A e la subnet-2 di VNET-B, senza estendere il peering all’intero address space delle due reti virtuali.

Il parametro –peer-complete-vnet false è fondamentale in questo scenario, perché indica ad Azure di non creare un peering completo tra le due VNet, ma di limitare la relazione alle sole subnet specificate tramite –local-subnet-names e –remote-subnet-names.

Nel prossimo passaggio sarà necessario creare il peering inverso, da VNET-B verso VNET-A, per rendere effettiva la comunicazione bidirezionale tra le due subnet.

È possibile che, lanciando i comandi di creazione del subnet peering, riceviate un errore simile al seguente:

is not registered for feature Microsoft.Network/AllowMultiplePeeringLinksBetweenVnets required to carry out the requested operation

Questo messaggio indica che la vostra subscription non è ancora abilitata per la funzionalità necessaria a creare link di peering “multipli”/selettivi (come quelli richiesti dal subnet peering). In pratica, Azure sta rifiutando l’operazione perché la feature AllowMultiplePeeringLinksBetweenVnets non risulta registrata per il provider Microsoft.Network nella subscription corrente.

Per risolvere, da Azure Cloud Shell (Azure CLI) potete registrare la feature e poi aggiornare la registrazione del provider:

Quando lo stato risulta Registered, potete ripetere i comandi az network vnet peering create per il subnet peering.

Figura 4: Errore restituito da Azure CLI durante la creazione del subnet peering quando la subscription non è abilitata alla feature AllowMultiplePeeringLinksBetweenVnets.

Dopo aver completato la registrazione della feature richiesta sulla subscription, potete rilanciare il comando di creazione del subnet peering. In questo caso l’operazione viene eseguita correttamente e Azure restituisce l’output JSON relativo al nuovo peering appena creato.

Come mostrato nell’immagine, lo stato di provisioning risulta Succeeded e il peering viene inizializzato limitatamente alle subnet specificate.

Figura 5: Creazione del subnet peering da VNET-A verso VNET-B completata con successo

Per completare la configurazione ed abilitare la connettività bidirezionale, è necessario creare anche il subnet peering da VNET-B verso VNET-A. Questo secondo comando è indispensabile perché il peering, anche in modalità subnet, è unidirezionale e deve essere definito su entrambi i lati.

Con questo comando viene esposta la subnet-2 di VNET-B verso la subnet-1 di VNET-A, completando la relazione di subnet peering. Al termine della configurazione, solo queste due subnet saranno in grado di comunicare tra loro, mentre tutte le altre subnet presenti nelle rispettive Virtual Network resteranno isolate per design.

Figura 6: Creazione del subnet peering da VNET-B verso VNET-A completata con successo

Sincronizzazione del peering

Quando create un subnet peering, Azure non applica immediatamente e automaticamente tutte le informazioni di routing tra i due lati del peering. Ogni lato del peering mantiene una propria “vista” della configurazione, che include le subnet locali, le subnet remote e i relativi prefissi di indirizzo. Finché queste informazioni non sono allineate, il peering può risultare creato ma non pienamente operativo.

La funzionalità di Sync peerings serve proprio a questo: forzare la sincronizzazione dello stato e delle informazioni di routing tra i due lati del peering. In pratica, dite ad Azure di riallineare la configurazione locale con quella remota, assicurandovi che entrambi i lati abbiano una visione coerente delle subnet coinvolte.

Questo meccanismo diventa particolarmente importante in alcuni scenari tipici del subnet peering:

• quando create i due peering in momenti diversi (prima VNET-A → VNET-B, poi VNET-B → VNET-A);
• quando modificate le subnet incluse nel peering, ad esempio aggiungendo o rimuovendo subnet locali o remote;
• quando cambiano gli address space o i prefissi associati alle subnet già peered.

In questi casi, senza una sincronizzazione esplicita, il peering può rimanere in uno stato come Initiated o LocalAndRemoteNotInSync, e la connettività potrebbe non comportarsi come previsto.

La sincronizzazione va eseguita su entrambi i peering, come mostrato di seguito:

Dopo la sincronizzazione, lo stato del subnet peering risulta allineato su entrambi i lati e la propagazione delle rotte tra le subnet peered viene completata correttamente.

Figura 7: Esecuzione del comando az network vnet peering sync tramite Azure CLI per sincronizzare lo stato del peering lato VNET-A e completare l’allineamento della configurazione

Figura 8: FullyInSync, con propagazione corretta delle rotte tra le subnet peered

Verifica dello stato del subnet peering

Dopo aver creato e sincronizzato i subnet peering, è buona pratica verificare lo stato di ciascun peering per assicurarsi che la configurazione sia completa e correttamente allineata su entrambi i lati.

Potete utilizzare il comando az network vnet peering show per visualizzare i dettagli del peering e controllarne lo stato operativo:

Dall’output del comando è possibile verificare informazioni rilevanti come lo stato di connessione del peering, l’allineamento tra lato locale e remoto e le subnet effettivamente incluse nella relazione di peering. In particolare, uno stato Connected e FullyInSync indica che il subnet peering è operativo e che la propagazione delle rotte tra le subnet peered è avvenuta correttamente.

Questa verifica consente di individuare rapidamente eventuali problemi di configurazione prima di procedere con i test di connettività tra le macchine virtuali.

Figura 9: Verifica dello stato del subnet peering

Test di funzionamento del subnet peering

Per verificare il corretto funzionamento del subnet peering, potete utilizzare due macchine virtuali distribuite sulle subnet che avete deciso di collegare. In questo scenario il test viene eseguito posizionando una macchina virtuale nella subnet-1 di VNET-A e una seconda macchina virtuale nella subnet-2 di VNET-B.

Una volta completata la distribuzione delle macchine virtuali, potete avviare un test di connettività dalla VM presente in VNET-A verso l’indirizzo IP privato della VM in VNET-B. Se il subnet peering è configurato correttamente, il traffico verrà instradato attraverso il backbone Azure e la comunicazione avverrà senza la necessità di gateway, NAT o componenti aggiuntivi.

Figura 10: Test di connettività riuscito tra le subnet collegate tramite subnet peering

Conclusioni

Con il subnet peering avete a disposizione uno strumento efficace per controllare in modo granulare la connettività tra reti virtuali in Azure, superando i limiti del peering tradizionale basato sull’intera VNet. La possibilità di collegare solo le subnet realmente necessarie consente di progettare architetture più sicure, ordinate e aderenti ai reali requisiti applicativi.

Il subnet peering non sostituisce il peering tradizionale, ma lo affianca come opzione avanzata per scenari complessi, ambienti multi-tenant e architetture orientate alla micro-segmentazione. Se adottate un approccio Infrastructure as Code e puntate a un maggiore controllo della rete, questa funzionalità rappresenta un tassello importante nella progettazione di infrastrutture Azure moderne e governate.