Topologia di rete hub-spoke

Questo articolo illustra come progettare una rete hub-spoke in Azure. Una rete virtuale hub centrale ospita servizi condivisi, mentre le reti virtuali spoke isolate ospitano singoli carichi di lavoro.

Informazioni su questo articolo

Questo articolo illustra i servizi condivisi della rete virtuale hub, l'isolamento spoke e i modelli di routing (standard, peering diretto e basati su stamp). Illustra anche il transito del gateway per la connettività ibrida e il ridimensionamento delle topologie hub-spoke con gestione rete virtuale di Azure.

Chi ha bisogno di questo articolo

Leggere questo articolo se si applicano una o più di queste condizioni:

Sono necessari servizi di rete condivisi, ad esempio firewall, DNS, Bastion, Gateway VPN o ExpressRoute per più carichi di lavoro.
Si vuole centralizzare l'ispezione del traffico, il controllo del routing o l'amministrazione anziché ripetere tali servizi in ogni rete virtuale.
È necessaria una topologia ripetibile per separare i servizi di piattaforma condivisi dalle VNet dei carichi di lavoro.
Vuoi confrontare il modello hub-and-spoke con altri modelli di transito prima di standardizzare la tua topologia.

Se si dispone di un singolo carico di lavoro senza requisiti di servizio condiviso, iniziare con una topologia di rete flat .

Tip

Si segue un percorso di scenario? Selezionare lo scenario nella parte superiore della pagina per indicazioni personalizzate. Le linee guida di base seguenti si applicano a tutti i lettori.

Focus su lift-and-shift: leggere questo articolo se si spostano carichi di lavoro locali in Azure e sono necessari servizi condivisi centralizzati (DNS, firewall, Gateway VPN) tra più reti virtuali spoke. Hub-and-spoke è la topologia predefinita per le migrazioni lift-and-shift di più carichi di lavoro che richiedono un'infrastruttura condivisa all'interno di un unico hub.

Focus: modernizzazione Leggi questo articolo se stai distribuendo servizi PaaS in più aree geografiche e hai bisogno di una topologia dual-hub con hub gestiti dall'IT e spoke gestiti dai team applicativi. Il modello hub-spoke viene ridimensionato per supportare limiti di sottoscrizione separati per i servizi della piattaforma e i carichi di lavoro delle applicazioni.

Focus sul multi-cloud: leggere questo articolo se si sta valutando hub-and-spoke rispetto alla rete WAN virtuale per il transito multi-cloud. Se il tuo ambiente multi-cloud è abbastanza piccolo da non giustificare rete WAN virtuale, una tradizionale architettura hub-and-spoke con connessioni tramite Gateway VPN verso altri cloud rappresenta un punto di partenza più semplice.

Azure servizi e funzionalità

La tabella seguente elenca i servizi e le funzionalità Azure che supportano una topologia hub-spoke:

Servizio o funzionalità	Ruolo nel modello hub-and-spoke	Ulteriori informazioni
Rete virtuale di Azure	Offre le reti virtuali hub e spoke.	Panoramica della rete virtuale
Peering reti virtuali	Connette ogni spoke al nodo hub	Peering di reti virtuali
Firewall di Azure	Ispezione e filtro del traffico centrale nell'hub	Panoramica del Firewall di Azure
Gateway VPN o Gateway ExpressRoute	Connettività ibrida condivisa tra tutti gli spoke	Panoramica di Gateway VPN
Azure Bastion	Proteggere l'accesso remoto alle VM attraverso spoke connessi tramite peering	Panoramica di Azure Bastion
Resolver privato DNS di Azure	Inoltro DNS tra Azure e locale	Panoramica del sistema di risoluzione DNS privato
Protezione di Azure dagli attacchi DDoS	Piano DDoS condiviso che copre gli indirizzi IP pubblici spoke	Panoramica della protezione DDoS
gestione rete virtuale di Azure (AVNM)	Peering automatizzato degli spoke, gestione degli UDR e gruppi di rete su larga scala	Panoramica di AVNM

Come funziona

In una topologia hub-and-spoke:

Una rete virtuale hub funge da punto centrale di connettività. Contiene servizi di rete condivisi, ad esempio un firewall, un gateway e un host Bastion.
Peering all'hub per Reti virtuali e spoke Ogni spoke ospita un carico di lavoro: un'applicazione, un ambiente del team o un servizio isolato.
Il peering di VNet è non transitivo. Gli spoke possono raggiungere l'hub, ma gli spoke non possono raggiungersi l'un l'altro direttamente tramite l'hub, a meno che non si configuri il routing o il peering diretto tra di essi.

Cosa accade nella rete virtuale hub

Usare la tabella seguente per determinare quali servizi inserire nell'hub:

Service	Includere?	Note
Firewall di Azure	Raccomandato	Fornisce un'ispezione centralizzata del traffico per tutto il traffico est-ovest e nord-sud. Richiede una subnet denominata esattamente `AzureFirewallSubnet`.
VPN o gateway ExpressRoute	Se è necessaria la connettività ibrida	Tutti gli spoke condividono un singolo gateway tramite il transito del gateway. Richiede una subnet con nome esatto `GatewaySubnet` (minimo /27).
Azure Bastion	Raccomandato	Un host Bastion nell'hub può raggiungere le macchine virtuali in tutte le reti virtuali spoke collegate tramite peering. Richiede SKU Basic o versione successiva: lo SKU per sviluppatori non supporta l'accesso peering tra reti virtuali.
resolver DNS privato	Se è necessario un DNS personalizzato	Inoltra le query DNS tra le zone DNS private ospitate di Azure e i server DNS locali.
Azure piano di protezione DDoS	Se la protezione DDoS è abilitata	Un singolo piano può proteggere gli indirizzi IP pubblici in tutte le reti virtuali spoke collegate alla sottoscrizione dell'hub.

Importante

Mantenere i carichi di lavoro dell'applicazione all'esterno dell'hub. L'hub ospita solo servizi di infrastruttura condivisa: firewall, gateway, Bastion e DNS. Le macchine virtuali, i contenitori e le risorse PaaS dell'applicazione appartengono alle reti virtuali spoke. Questa separazione mantiene pulita l'hub, semplifica il peering e consente al team della piattaforma di gestire i servizi condivisi indipendentemente dai team delle applicazioni.

Struttura della subnet dell'hub

Una rete virtuale hub ben progettata include in genere queste subnet:

Nome della sottorete	Purpose	Dimensioni minime
`AzureFirewallSubnet`	distribuzione di Firewall di Azure	/26
`AzureFirewallManagementSubnet`	NIC di gestione per il tunneling forzato (solo Standard/Premium)	/26
`GatewaySubnet`	VPN e gateway ExpressRoute	/27
`AzureBastionSubnet`	Azure Bastion	/26
Subnet in ingresso del resolver DNS	Endpoint in ingresso del Resolver privato DNS	/28
Subnet in uscita del resolver DNS	Endpoint in uscita del Resolver privato DNS	/28

Per indicazioni dettagliate sul ridimensionamento delle subnet, vedere Reti virtuali e subnet.

Come scegliere una variante

Hub-and-spoke ha tre varianti comuni. Scegliere in base ai requisiti di isolamento e comunicazione:

Variant	Percorso del traffico	Quando utilizzare
Topologia hub-and-spoke standard	Tutto il traffico spoke-to-spoke passa tramite il firewall dell'hub	È necessaria un'ispezione centralizzata del traffico. Gli spoke non richiedono comunicazioni peer-to-peer dirette.
Hub-and-spoke con peering diretto	Anche coppie specifiche di spoke stabiliscono una connessione peering diretta tra loro	I carichi di lavoro strettamente associati richiedono comunicazioni spoke-to-spoke a bassa latenza senza attraversare il firewall.
Stamp (completamente isolati)	Nessun hub. Ogni rete virtuale è completamente indipendente.	Rigido isolamento del raggio d'impatto, separazione guidata dalla conformità o SaaS multi-tenant con stack indipendenti.

Topologia hub-and-spoke standard

Questa variante è la più comune. Il traffico spoke-to-spoke passa attraverso il firewall dell'hub per l'ispezione. I nodi spoke comunicano solo tramite l'hub, mai direttamente.

Modello di routing: Applicare una route definita dall'utente a ogni subnet spoke con la route predefinita (0.0.0.0/0) che punta all'indirizzo IP privato del firewall hub. Questo instrada tutto il traffico in uscita, compreso quello spoke-to-spoke, tramite il firewall per la registrazione e il filtraggio.

Limite di peering: Una singola rete virtuale hub supporta fino a 500 connessioni di peering (limite di piattaforma standard). Se si usa gestione rete virtuale di Azure (AVNM) con una configurazione di connettività hub-spoke, il limite aumenta a 1.000 spoke.

Hub-and-spoke con peering diretto

In alcune architetture, coppie spoke specifiche richiedono comunicazioni a bassa latenza senza attraversare il firewall dell'hub. In questi casi, aggiungere il peering diretto della rete virtuale tra i due spoke oppure usare i gruppi connessi di AVNM.

Usare il peering spoke diretto quando:

Due carichi di lavoro scambiano dati a capacità effettiva elevata (ad esempio, la replica di database tra gli spoke).
La latenza dall'hop del firewall non è accettabile per un percorso di dati specifico.
Si accetta che il traffico con peering diretto ignora l'ispezione del firewall centrale.

Note

Il peering tra gli spoke non elimina la necessità dell'hub. Il traffico associato all'hub (in uscita, connettività ibrida, servizi condivisi) viene comunque instradato attraverso il firewall hub.

Modello stamp (completamente isolato)

Il modello Stamps è un'alternativa per scenari che richiedono un isolamento rigoroso del raggio di esplosione. Ogni carico di lavoro viene distribuito in una rete virtuale completamente indipendente senza hub e senza peering ad altri carichi di lavoro.

Quando usare i francobolli:

La conformità alle normative non richiede alcun percorso di rete tra carichi di lavoro.
SaaS multi-tenant in cui ogni tenant ha uno stack indipendente.
Isolamento massimo degli errori: un errore in un timbro non può propagarsi ad altri.

Esempio: isolamento SaaS multitenant

Un provider SaaS ospita ogni cliente aziendale in uno stamp dedicato. Ogni stamp contiene la propria macchina virtuale (10.x.0.0/16), il gateway applicativo, il livello di calcolo e il database. Non esiste alcun peering di VNet tra gli stamp, quindi un NSG configurato in modo errato o un carico di lavoro compromesso nello stamp del tenant A non può raggiungere le risorse del tenant B tramite la rete. Il fornitore gestisce gli stamp tramite i modelli di Azure Resource Manager e li distribuisce in gruppi di risorse distinti o in sottoscrizioni separate per i tenant di grandi dimensioni. Lo scambio di dati inter-tenant, se necessario, utilizza un namespace condiviso di bus di servizio di Azure. Ogni stamp accede a questo spazio dei nomi tramite endpoint privati.

Compromessi:

Nessun servizio condiviso. Ogni stamp richiede un firewall, un gateway e un host Bastion (se necessario), che aumentano i costi.
Nessuna comunicazione tra carichi di lavoro tramite rete privata.
Il sovraccarico operativo aumenta perché si gestiscono reti indipendenti anziché un'infrastruttura centralizzata.
I costi aumentano in modo lineare con il conteggio dei francobolli perché i risparmi del servizio condiviso non vengono applicati.

Se i carichi di lavoro richiedono servizi condivisi o comunicazioni tra carichi di lavoro, usare invece la variante hub-and-spoke standard.

Modelli di comunicazione spoke-to-spoke

Poiché il peering reti virtuali non è transitivo, la comunicazione spoke-to-spoke richiede un instradamento esplicito. Questa sezione descrive come il traffico fluisce tra gli spoke tramite il firewall dell'hub.

Flusso del traffico: dallo spoke A allo spoke B attraverso il firewall dell'hub

La sequenza seguente descrive come un pacchetto passa da una macchina virtuale in spoke A (10.1.0.4) a una macchina virtuale in spoke B (10.2.0.4):

Una macchina virtuale spoke invia un pacchetto destinato a 10.2.0.4. La tabella delle route effettive della macchina virtuale contiene una UDR con 0.0.0.0/0 → 10.0.1.4 (l'indirizzo IP privato di Firewall di Azure).
Il pacchetto attraversa il collegamento di peering della VNet da Spoke A alla VNet hub. Il peering consente al traffico di raggiungere la subnet del firewall.
Firewall di Azure riceve il pacchetto nella relativa interfaccia interna. Valuta il pacchetto rispetto alle regole di rete e alle regole dell'applicazione in ordine di priorità.
Se una regola consente il flusso, il firewall inoltra il pacchetto a 10.2.0.4. Il pacchetto attraversa il collegamento di peering tra l'hub e Spoke-B.
La macchina virtuale spoke B riceve il pacchetto. Il traffico di ritorno segue lo stesso percorso inverso. L'UDR dello spoke B rimanda la risposta attraverso il firewall.

Configurazione delle tabelle di route

Applicare queste tabelle di route per abilitare il modello precedente:

Crea una tabella di routing per le subnet spoke. Disattivare la propagazione delle route BGP se si desidera impedire che le route locali sovrascrivano le UDR.
Aggiungere una route predefinita (0.0.0.0/0) con il tipo di hop successivo VirtualAppliance e l'indirizzo dell'hop successivo impostato sull'indirizzo IP privato di Firewall di Azure.
Associare la tabella di routing a ogni subnet spoke che deve raggiungere altri spoke o Internet.
Creare regole di rete del firewall che consentano lo specifico traffico spoke-to-spoke. Ad esempio, consentire 10.1.0.0/16 → 10.2.0.0/16 sulle porte 443 e 1433.

Tip

Usate i gruppi di indirizzi IP in Firewall di Azure per organizzare gli intervalli di indirizzi delle reti spoke. Ciò semplifica la gestione delle regole man mano che si aggiungono nuovi spoke.

Alternativa: gruppi AVNM connessi per la comunicazione diretta tra spoke

Se non è necessaria l'ispezione tramite firewall tra determinati spoke, i gruppi connessi di AVNM forniscono un modello di connettività a mesh. Gli spoke nello stesso gruppo connesso comunicano direttamente senza attraversare l'hub. Ciò riduce i requisiti di latenza e velocità effettiva del firewall, ma ignora l'ispezione centralizzata.

Importante

Se si abilita il tunneling forzato in Firewall di Azure (per instradare il traffico associato a Internet a un'appliance locale), è necessario il livello Standard o Premium. Il tunneling forzato richiede anche una subnet di gestione (AzureFirewallManagementSubnet) e disattiva le regole DNAT.

Transito gateway

Il transito del gateway consente a tutti gli spoke di condividere un singolo gateway VPN o ExpressRoute distribuito nell'hub. Senza transito tramite gateway, ogni spoke deve disporre di un proprio gateway per raggiungere le reti locali.

Passaggi di configurazione

Distribuire un gateway VPN o ExpressRoute nel GatewaySubnet dell'hub.
Nella connessione peering dal lato hub (hub → spoke): abilitare Consenti transito del gateway.
Nella connessione di peering sul lato spoke (spoke → hub): abilitare Usa gateway remoti.
Verificare la propagazione della route. Dopo la configurazione, controllare le route valide in una scheda di interfaccia di rete della macchina virtuale spoke. La tabella di routing mostra i prefissi on-premises appresi tramite il gateway dell'hub con un tipo di hop successivo pari a VNetGlobalPeering o VNetPeering.

Se configurata, le route apprese dal gateway hub (ad esempio, prefissi locali da ExpressRoute) vengono propagate automaticamente alle tabelle di routing spoke.

Limitazioni di transito del gateway

Il transito del gateway funziona con tutti i livelli Gateway VPN ad eccezione del livello Basic. Se si usa il Gateway VPN Basic, non è possibile condividerlo con reti virtuali con peering.
Una rete virtuale spoke può usare un solo gateway remoto. Non è possibile abilitare Use remote gateways su uno spoke con più hub.
Se si usano UDR per forzare il traffico attraverso il firewall, assicurarsi che le UDR non sovrascrivano involontariamente le route locali propagate dal gateway. Impostare route più specifiche per i prefissi locali, se necessario.

Note

Quando si utilizza ExpressRoute con il transito gateway, attivare Consenti transito gateway prima di stabilire i peering dello spoke. Il gateway deve prima esistere ed essere sottoposto a provisioning.

gestione rete virtuale di Azure su larga scala

Quando l'ambiente cresce oltre una manciata di spoke, la gestione delle connessioni di peering e delle tabelle di route diventa manualmente complessa. AVNM offre l'automazione per le topologie hub-spoke:

Funzionalità AVNM	Funzionamento
Configurazione della connettività hub-spoke	Crea e gestisce automaticamente il peering tra l'hub e tutti gli spoke in un gruppo di rete. Supporta fino a 1.000 spoke per hub.
Gruppi connessi	Abilita la connettività direct spoke-to-spoke senza peering manuale. Limite predefinito: 250 reti virtuali per gruppo (espandibile a 1.000 per richiesta).
Gruppi di rete con appartenenza dinamica	Usa le condizioni di Criteri di Azure per aggiungere automaticamente reti virtuali ai gruppi in base a tag, nomi o sottoscrizioni.
Gestione UDR	Automatizza la distribuzione delle tabelle di route tra più topologie hub-spoke.

AVNM è particolarmente utile quando si gestiscono topologie hub-spoke in più regioni o quando è necessaria un'appartenenza dinamica man mano che nuove reti virtuali spoke vengono attivate.

Considerazioni sulla scalabilità

Con l'espansione della topologia hub-spoke, prevedi i seguenti limiti della piattaforma e modelli organizzativi:

Limiti di peering e connettività

Dimension	Limite standard	Con AVNM	Note
Peering di reti virtuali per rete virtuale	500	1.000 (configurazione hub-spoke)	Ogni peering spoke-to-hub usa uno slot su entrambi i lati
Reti virtuali per gruppo connesso AVNM	250 (impostazione predefinita)	Fino a 1.000 (per richiesta)	Richiedere l'aumento tramite supporto tecnico di Azure
Sottoscrizioni per ambito AVNM	N/A	1,000	L'ambito può estendersi a più sottoscrizioni in un gruppo di gestione

Organizzazione della sottoscrizione

Separare gli spoke in sottoscrizioni specifiche per i carichi di lavoro per ambienti con più di 10 spoke. Questo isola fatturazione, RBAC e limiti di quota per ciascun team di workload.
Usare una sottoscrizione di connettività dedicata per la rete virtuale, i gateway e il firewall dell'hub. Questo è il modello consigliato dalle landing zone di Azure (sottoscrizione di piattaforma).
Raggruppa le sottoscrizioni in un gruppo di gestione in modo che AVNM possa individuare e gestire dinamicamente le spoke VNet nelle varie sottoscrizioni tramite le condizioni di Criteri di Azure.

Applicazione della topologia con Criteri di Azure

Usare Criteri di Azure per evitare la deriva della configurazione:

Nega il peering alle reti virtuali che non sono hub. Assegnare un criterio a livello del gruppo di gestione che blocchi la creazione del peering della macchina virtuale, a meno che la destinazione non sia la macchina virtuale hub designata.
Richiedere l'associazione UDR. Assegnare un criterio che verifichi (o neghi) le subnet spoke senza una tabella di routing che includa la route 0.0.0.0/0 → Firewall.
Imporre l'appartenenza al gruppo AVNM. Usare regole di appartenenza dinamica in AVNM in base ai tag (ad esempio, NetworkRole:Spoke) in modo che le nuove reti virtuali vengano registrate automaticamente.

Percorso di migrazione da un'architettura flat a un'architettura hub-spoke

Se si è iniziato con una topologia di rete flat e l'ambiente è cresciuto per richiedere servizi condivisi o segmentazione tra carichi di lavoro, seguire questo percorso di migrazione:

Passaggio 1: Pianificare la rete virtuale dell'hub

Alloca un nuovo spazio di indirizzi per l'hub (ad esempio, 10.0.0.0/16) che non si sovrapponga alla VNet flat esistente.
Determinare i servizi condivisi da distribuire: firewall, gateway, Bastion, resolver DNS.
Dimensionare le subnet dell'hub secondo la tabella layout delle subnet dell'hub.

Passaggio 2: Distribuire servizi condivisi nell'hub

Creare la VNet dell'hub e distribuire Firewall di Azure (o l'NVA scelta).
Distribuire il gateway VPN/ExpressRoute se è necessaria la connettività ibrida.
Distribuire Azure Bastion per l'accesso sicuro alle macchine virtuali.
Configurare DNS privato resolver se si usa dns personalizzato.

Passaggio 3: Migrare i carichi di lavoro nelle spoke

Creare macchine virtuali spoke con nuovi spazi di indirizzi per ogni carico di lavoro. Se non è possibile effettuare il re-IP, è possibile mantenere gli intervalli di indirizzi esistenti purché non si sovrappongano con l'hub.
Eseguire il peering di ogni spoke all'hub. Abilitare il transito del gateway sul lato hub e usare gateway remoti sul lato spoke.
Applicare le route definite dall'utente (UDR) alle subnet spoke con la route predefinita che punta al firewall dell'hub.
Spostare o ridistribuire macchine virtuali e servizi dalla rete virtuale flat allo spoke appropriato. Usa Spostamento risorse di Azure o la ridistribuzione, a seconda della complessità del carico di lavoro.
Creare regole del firewall per consentire i modelli di traffico tra spoke e spoke-to-Internet consentiti in precedenza all'interno della rete virtuale flat.

Passaggio 4: Dismettere la VNet flat

Verificare che tutti i carichi di lavoro siano raggiungibili tramite la nuova topologia hub-spoke.
Aggiornare i record DNS se gli indirizzi IP privati sono stati modificati.
Rimuovere la vecchia rete virtuale flat dopo la migrazione e convalidare tutto il traffico.

Tip

Eseguire la migrazione dei carichi di lavoro in fasi. Iniziare con un carico di lavoro non critico per convalidare il routing e le regole del firewall, quindi procedere con i carichi di lavoro di produzione.

Quando prendere in considerazione la rete virtuale WAN

Se la topologia hub-spoke aumenta in complessità, valutare se rete WAN virtuale di Azure offre una soluzione migliore:

Fattore	Hub-and-spoke (tradizionale)	Rete WAN virtuale di Azure
Management	Infrastruttura dell'hub gestito dal cliente	routing e connettività dell'hub gestito da Microsoft
Ideale per	Meno di 30 connessioni di ramo VPN, controllo completo necessario	Più di 30 rami VPN, molte aree Azure
Routing	Il cliente configura manualmente le UDR	Instradamento automatico nell'hub
integrazione SD-WAN	Distribuzione manuale di NVA	Integrazione nativa dei partner SD-WAN
Transito globale	Richiede il routing tra hub gestito dal cliente	Integrato: tutti gli hub si interconnettono automaticamente

Per un confronto dettagliato, vedere rete WAN virtuale di Azure topologia.

Considerazioni relative alla progettazione

Per una migrazione di tipo lift-and-shift, distribuisci un singolo hub con servizi condivisi utilizzati da tutti i carichi di lavoro in fase di migrazione:

Hub singolo con Gateway VPN. Distribuire Gateway VPN (o gateway ExpressRoute) nel GatewaySubnet dell'hub. Tutti i carichi di lavoro spoke condividono questo gateway attraverso il transito del gateway per la connettività locale durante e dopo la migrazione.
Azure Bastion nell'hub. Una singola distribuzione di Bastion nell'hub fornisce un accesso RDP/SSH sicuro alle macchine virtuali in tutti gli spoke connessi tramite peering, senza esporre indirizzi IP pubblici sui server migrati.
Firewall centralizzato per il traffico in uscita. Distribuire Firewall di Azure nell'hub. Configurate le route definite dall'utente in ogni subnet spoke con la route predefinita che indirizza il traffico al firewall. Tutto il traffico in uscita e il traffico spoke-to-spoke transita attraverso questo singolo punto di ispezione.
Inizia con un hub, aggiungi i raggi gradualmente. Eseguire il peering della rete virtuale spoke di ogni carico di lavoro con l'hub durante la migrazione. Un singolo hub supporta fino a 500 connessioni di peering (1.000 con AVNM).

Per uno scenario di migrazione e modernizzazione, pianificare la topologia dual-hub che separa l'infrastruttura della piattaforma dai carichi di lavoro dell'applicazione:

Distribuzione a doppio hub. Distribuire un hub nell'area primaria e un secondo hub nell'area di backup. Ogni hub contiene il proprio firewall, il gateway e Bastion. Supporta le architetture attive-attive per i carichi di lavoro PaaS.
Hub gestiti dall’IT, spoke gestiti dal team delle app. Il team della piattaforma gestisce le sottoscrizioni dell'hub (modello di sottoscrizione della connettività, una sottoscrizione Azure dedicata per le risorse di rete dell'hub condiviso, separate dalle sottoscrizioni del carico di lavoro). I team delle applicazioni possiedono le sottoscrizioni spoke con il controllo delegato sulle subnet di collegamento privato e sulle risorse del carico di lavoro.
Subnet di collegamento privato per spoke. Ogni rete virtuale spoke include una subnet dedicata per gli endpoint privati. I team applicativi creano connessioni di collegamento privato ai propri servizi PaaS (Azure SQL, Storage, un insieme di credenziali delle chiavi) nei propri spoke.
Firewall dell'hub come SNAT/DNAT. Il firewall centrale in ogni hub fornisce NAT di origine per il traffico in uscita e NAT di destinazione per i modelli di traffico in ingresso. I team delle applicazioni non possono ignorare l'ispezione centralizzata.

Per la connettività tra cloud, valutare se hub-spoke tradizionale o rete WAN virtuale fornisce il modello di transito corretto:

Scelta tra Hub-spoke e rete WAN virtuale. Se si hanno meno di 30 connessioni di ramo, un numero ridotto di tunnel VPN tra cloud e funziona in una o due aree Azure, il tradizionale hub-spoke con Gateway VPN è più semplice. Se si dispone di molte VPN, rami, aree o bordi del cloud, rete WAN virtuale offre un routing automatizzato che migliora la scalabilità.
Gateway VPN per tunnel tra cloud diversi In un modello hub-spoke, distribuire Gateway VPN nell'hub e creare connessioni site-to-site ai gateway virtuali privati di AWS e agli endpoint VPN di Google Cloud. Ogni connessione usa la crittografia IPSec/IKE.
Valutare la crescita della complessità. Se il tuo ambiente multicloud si espande (più account AWS, progetti Google Cloud o regioni di Azure), rivedi la scelta tra hub-spoke e rete WAN virtuale. rete WAN virtuale diventa più conveniente quando si gestiscono molti tunnel su larga scala.

Per un confronto completo, vedere rete WAN virtuale di Azure topologia.

Prerequisiti

Prima di progettare una rete hub-spoke:

Completa il piano per la rete virtuale e le subnet. Conoscere il numero di spoke necessari e le subnet necessarie per ogni spoke.
Definire lo schema di indirizzi IP. Gli spazi di indirizzi hub e spoke non devono sovrapporsi.
Tenere presente che il peering di macchina virtuale non è transitivo: gli spoke non ereditano la connettività con altri spoke tramite l'hub.

Considerazioni relative alla sicurezza

Una topologia hub-spoke centralizza l'applicazione della sicurezza nell'hub. Applicare questi principi:

Instradare tutto il traffico degli spoke attraverso il firewall dell'hub. Usare route definite dall'utente con la route predefinita che punta al firewall. Questa configurazione garantisce che il firewall ispezioni e registri tutti i flussi spoke-to-spoke e spoke-to-internet.
Usare gli NSG sulle subnet spoke come difesa in profondità. Anche con un firewall centrale, i gruppi di sicurezza di rete nelle subnet spoke offrono un ulteriore livello di segmentazione. Negare il traffico laterale imprevisto a livello di subnet. Per indicazioni sulla progettazione dei gruppi di sicurezza di rete, vedere Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni.
Abilitare il transito del gateway con attenzione. Il transito del gateway espone le route locali a tutti gli spoke. Assicurarsi che le regole del firewall tengano conto della connettività ampliata.
Rimuovere gli indirizzi IP pubblici nelle macchine virtuali spoke. Azure Bastion nell'hub fornisce accesso sicuro alla gestione senza esporre le macchine virtuali a Internet.
Considerare ogni spoke come un perimetro di sicurezza. I carichi di lavoro nei diversi spoke rimangono isolati per impostazione predefinita. La connettività tra spoke richiede regole esplicite di routing e firewall.

Topologia di rete flat: per singoli carichi di lavoro che non necessitano di servizi condivisi
topologia rete WAN virtuale di Azure: per il routing gestito e la connettività su larga scala
Rete in più aree: per i carichi di lavoro che si estendono su più aree Azure
Reti virtuali e subnet: ridimensionamento della subnet per i componenti dell'hub
Pianificazione degli indirizzi IP: pianificazione CIDR per hub e spokes
Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni: difesa a più livelli per le subnet spoke

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Connetti la tua rete locale: Configura Gateway VPN o ExpressRoute nella rete virtuale dell'hub per stabilire questa dipendenza critica per la migrazione.

Nel prossimo percorso di modernizzazione:

Pianificare la distribuzione in più aree: distribuire active-active tra le aree primarie e di backup per le applicazioni rivolte ai clienti.

Il prossimo passo nel tuo percorso multicloud:

Valutare rete WAN virtuale di Azure come modello di transito: valutare se rete WAN virtuale o hub-spoke meglio si adattano al cross-cloud estate con più VPC, rami e aree geografiche.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-07-01