Topologia di rete di Azure tradizionale

Questo articolo descrive le principali considerazioni sulla progettazione e le raccomandazioni relative alle topologie di rete in Microsoft Azure. Il diagramma seguente illustra una topologia di rete di Azure tradizionale:

Considerazioni relative alla progettazione

• Varie topologie di rete possono connettere più reti virtuali della zona di destinazione. Esempi di topologie di rete includono topologie hub-spoke, full-mesh e ibride. È anche possibile disporre di più reti virtuali connesse tramite più connessioni o circuiti di Azure ExpressRoute.

• Le reti virtuali non possono attraversare i limiti della sottoscrizione. Tuttavia, è possibile usare il peering di reti virtuali, un circuito ExpressRoute o i gateway VPN per ottenere la connettività tra reti virtuali tra sottoscrizioni diverse.

• Il peering di reti virtuali è il metodo preferito per connettere le reti virtuali in Azure. È possibile usare il peering di reti virtuali per connettere reti virtuali nella stessa area, tra aree di Azure diverse e tra tenant di Microsoft Entra diversi.

• Il peering di reti virtuali e il peering di reti virtuali globale non sono transitivi. Per abilitare una rete di transito, è necessario disporre di route definite dall'utente e di appliance virtuali di rete (NVA). Per altre informazioni, vedere Topologia di rete hub-spoke in Azure.

• È possibile condividere un piano di protezione DDoS di Azure tra tutte le reti virtuali in un singolo tenant di Microsoft Entra per proteggere le risorse con indirizzi IP pubblici. Per altre informazioni, vedere Protezione DDoS.

  • I piani di protezione DDoS riguardano solo le risorse con indirizzi IP pubblici.

  • Il costo di un piano di protezione DDoS include 100 indirizzi IP pubblici tra reti virtuali protette associate al piano di protezione DDoS. La protezione di un numero superiore di risorse ha un costo maggiore. Per altre informazioni, vedere Prezzi di Protezione DDoS o le Domande frequenti.

  • Esaminare le risorse supportate dei piani di protezione DDoS.

• È possibile usare i circuiti ExpressRoute per stabilire la connettività tra reti virtuali all'interno della stessa area geopolitica oppure usare il componente aggiuntivo Premium per la connettività tra aree geopolitiche. Tieni in considerazione i seguenti punti:

  • Il traffico da rete a rete potrebbe subire una latenza maggiore a causa dell'hairpin del traffico nei router Microsoft Enterprise Edge (MSEE).

  • La SKU del gateway ExpressRoute limita la larghezza di banda.

  • Distribuire e gestire le route definite dall'utente se è necessario ispezionarle o registrarle tra reti virtuali.

• I gateway VPN con Border Gateway Protocol (BGP) sono transitivi all'interno di Azure e nelle reti locali, ma non forniscono l'accesso transitivo alle reti connesse tramite ExpressRoute per impostazione predefinita. Se è necessario l'accesso transitivo alle reti connesse tramite ExpressRoute, prendere in considerazione il Server di route Azure.

• Quando si connettono più circuiti ExpressRoute alla stessa rete virtuale, usare i pesi di connessione e le tecniche BGP per garantire un percorso ottimale per il traffico tra reti locali e Azure. Per altre informazioni, vedere Ottimizzare il routing in ExpressRoute.

Se si usano le metriche BGP per influenzare il routing di ExpressRoute, è necessario modificare la configurazione all'esterno della piattaforma Azure. L'organizzazione o il provider di connettività deve configurare i router locali di conseguenza.

• I circuiti ExpressRoute con componenti aggiuntivi Premium offrono una connettività globale.

• ExpressRoute ha alcuni limiti, incluso un numero massimo di connessioni ExpressRoute per ogni gateway ExpressRoute. Il peering privato di ExpressRoute impone un limite massimo sul numero di route che può identificare da Azure alla rete locale. Per altre informazioni, vedere Limiti di ExpressRoute.

• La velocità effettiva aggregata massima di un gateway VPN è di 10 gigabit al secondo. Un gateway VPN supporta fino a 100 tunnel da sito a sito o da rete a rete.

• Se un'appliance virtuale di rete fa parte dell'architettura, prendere in considerazione il server di route per semplificare il routing dinamico tra l'appliance virtuale di rete e la rete virtuale. Usare il server di route per scambiare informazioni di routing direttamente tramite BGP tra qualsiasi appliance virtuale di rete che supporta BGP e la rete definita dal software (SDN) di Azure nella rete virtuale di Azure. Non è necessario configurare o gestire manualmente le tabelle di route con questo approccio.

Suggerimenti per la progettazione

• Considerare una progettazione di rete basata sulla topologia di rete hub-spoke tradizionale per gli scenari seguenti:

  • Un'architettura di rete distribuita all'interno di una singola area di Azure.

  • Un'architettura di rete che si estende su più aree di Azure, senza la necessità di connettività transitiva tra le reti virtuali per le zone di destinazione tra aree.

  • Un'architettura di rete che si estende su più aree di Azure e il peering di reti virtuali globale che possono connettere le reti virtuali tra aree di Azure.

  • Non è necessaria la connettività transitiva tra connessioni VPN ed ExpressRoute.

  • Il metodo di connettività ibrida principale è ExpressRoute e il numero di connessioni VPN è inferiore a 100 per ogni gateway VPN.

  • Esiste una dipendenza dalle appliance virtuali di rete centralizzate e dal routing granulare.

• Per le distribuzioni a livello di area, usare principalmente la topologia hub-spoke con un hub a livello di area per ogni area di Azure spoke. Usare le reti virtuali della zona di destinazione dell'applicazione che usano il peering di reti virtuali per connettersi a una rete virtuale hub centrale a livello di area per gli scenari seguenti:

  • Connettività cross-premise tramite ExpressRoute abilitata in due posizioni di peering diverse. Per altre informazioni, vedere Progettare e architettare Azure ExpressRoute per la resilienza.

  • Una VPN per la connettività delle filiali.

  • Connettività spoke-to-spoke tramite appliance virtuali di rete e route definite dall'utente.

  • Protezione connettività Internet in uscita tramite Firewall di Azure o un'altra appliance virtuale di rete non Microsoft.

• Il diagramma seguente illustra la topologia hub-spoke. Usare questa configurazione per garantire un controllo del traffico appropriato e soddisfare la maggior parte dei requisiti di segmentazione e ispezione.

  

• Usare la topologia con più reti virtuali connesse tramite più circuiti ExpressRoute in posizioni di peering diverse se:

  • È necessario un livello elevato di isolamento. Per altre informazioni, vedere Progettare e architettare Azure ExpressRoute per la resilienza.

  • È necessaria una larghezza di banda ExpressRoute dedicata per business unit specifiche.

  • Si raggiunge il numero massimo di connessioni per ogni gateway ExpressRoute. Per determinare il numero massimo, vedere Limiti di ExpressRoute.

• Il diagramma seguente illustra questa topologia.

  

• Per il peering dual-homed all'interno della stessa città, prendere in considerazione ExpressRoute Metro.

• Distribuire Firewall di Azure o appliance virtuali di rete partner nella rete virtuale hub centrale per la protezione e il filtraggio del traffico est/ovest o sud/nord.

• Distribuire un set di servizi condivisi minimi, inclusi gateway ExpressRoute, gateway VPN (se necessario) e Firewall di Azure o appliance virtuali di rete partner (se necessario) nella rete virtuale hub centrale. Se necessario, distribuire anche i controller di dominio e i server DNS di Active Directory.

• Distribuire un singolo piano standard di protezione DDoS nella sottoscrizione di connettività. Usare questo piano per tutte le reti virtuali della piattaforma e della zona di destinazione.

• Usare la rete esistente, la funzionalità MPLS (Multiprotocol Label Switching) e la rete SD-WAN per connettere le filiali alla sede centrale dell'azienda. Se non si usa il server di route, il supporto per il transito in Azure tra connessioni ExpressRoute e gateway VPN non è disponibile.

• Distribuire Firewall di Azure o appliance virtuali di rete partner per la protezione e il filtraggio del traffico est/ovest o sud/nord nella rete virtuale hub centrale.

• Quando si distribuiscono appliance virtuali di rete o tecnologie di rete partner, seguire le indicazioni del fornitore partner per assicurarsi che:

  • Il fornitore supporti la distribuzione.

  • Le linee guida supportino la disponibilità elevata e un livello di prestazioni superiore.

  • Non siano presenti configurazioni in conflitto con la rete di Azure.

• Non distribuire appliance virtuali di rete in ingresso di livello 7, ad esempio il gateway applicazione di Azure, come servizio condiviso nella rete virtuale hub centrale. Distribuirle invece insieme all'applicazione nelle rispettive zone di destinazione.

• Distribuire un singolo piano di protezione standard DDoS nella sottoscrizione di connettività.

  • Tutte le reti virtuali della zona di destinazione e della piattaforma devono usare questo piano.

• Usare la rete esistente, la rete MPLS (Multiprotocol Label Switching) e la rete SD-WAN per connettere le succursali alla sede centrale dell'azienda. Se non si usa il server di route, non è disponibile alcun supporto per il transito in Azure tra i gateway VPN ed ExpressRoute.

• Se è necessaria la transitività tra i gateway VPN ed ExpressRoute in uno scenario hub-spoke, usare il server di route. Per altre informazioni, vedere Supporto del server di route Azure per ExpressRoute e VPN di Azure.

  

• Quando si dispone di reti hub-spoke in più aree di Azure ed è necessario connettere alcune zone di destinazione tra le aree, usare il peering di reti virtuali globale. È possibile connettere direttamente le reti virtuali della zona di destinazione che devono instradare il traffico tra loro. A seconda della SKU della macchina virtuale comunicante, il peering di reti virtuali globale può fornire una velocità effettiva di rete elevata. Il traffico tra le reti virtuali della zona di destinazione con peering diretto ignora le appliance virtuali di rete all'interno delle reti virtuali hub. Le limitazioni del peering di reti virtuali globale si applicano al traffico.

• Quando si dispone di reti hub-spoke in più aree di Azure ed è necessario connettere la maggior parte delle zone di destinazione tra le aree, usare le appliance virtuali di rete hub per connettere tra loro le reti virtuali hub in ogni area e per instradare il traffico tra le aree. È anche possibile usare questo approccio se non è possibile usare il peering diretto per ignorare le appliance virtuali di rete hub a causa dell'incompatibilità con i requisiti di sicurezza. Il peering di reti virtuali globale o i circuiti ExpressRoute consentono di connettere le reti virtuali hub nei modi seguenti:

  • Il peering di reti virtuali globale offre una connessione a bassa latenza e velocità effettiva elevata, ma genera tariffe per il traffico.

  • Se si esegue il routing tramite ExpressRoute, è possibile aumentare la latenza a causa dell'hairpin MSEE. La SKU del gateway ExpressRoute limita la velocità effettiva.

Il diagramma seguente mostra le opzioni per la connettività da hub a hub:

• Quando è necessario connettere due aree di Azure, usare il peering di reti virtuali globale per connettere le reti virtuali hub in ogni area.

• Usare un'architettura di rete di transito globale gestita basata su rete WAN virtuale di Azure se l'organizzazione:

  • Richiede architetture di rete hub-spoke in più di due aree di Azure.

  • Richiede la connettività di transito globale tra le reti virtuali delle zone di destinazione nelle aree di Azure.

  • Vuole ridurre al minimo il sovraccarico di gestione della rete.

• Quando è necessario connettere più di due aree di Azure, è consigliabile che le reti virtuali hub di ogni area si connettano agli stessi circuiti ExpressRoute. Il peering di reti virtuali globale richiede la gestione di un numero elevato di relazioni di peering e di un set complesso di route definite dall'utente tra più reti virtuali. Il diagramma seguente illustra come connettere le reti hub-spoke in tre aree:

  

• Quando si usano i circuiti ExpressRoute per la connettività tra aree, gli spoke di aree diverse comunicheranno direttamente e ignoreranno il firewall perché apprendono attraverso le route BGP agli spoke dell'hub remoto. Se è necessario che il traffico tra spoke sia ispezionato dalle appliance virtuali di rete del firewall, è necessario implementare una di queste opzioni:

  • Creare voci di route più specifiche nelle route definite dall'utente degli spoke per il firewall nella rete virtuale hub locale per reindirizzare il traffico tra gli hub.

  • Per semplificare la configurazione delle route, disabilitare la propagazione BGP nelle tabelle di route degli spoke.

• Quando l'organizzazione richiede architetture di rete hub-spoke in più di due aree di Azure e la connettività di transito globale tra le reti virtuali delle zone di destinazione nelle aree di Azure e si vuole ridurre al minimo il sovraccarico di gestione della rete, è consigliabile valutare un'architettura di rete di transito globale gestita basata su rete WAN virtuale.

• Distribuire le risorse di rete hub di ogni area in gruppi di risorse separati e ordinarle in ogni area distribuita.

• Usare Gestione rete virtuale di Azure per gestire la configurazione della connettività e della sicurezza delle reti virtuali a livello globale tra sottoscrizioni.

• Usare Informazioni dettagliate sulla rete di Monitoraggio di Azure per monitorare lo stato end-to-end delle reti in Azure.

• È necessario considerare i seguenti due limiti quando si connettono le reti virtuali spoke alla rete virtuale hub centrale:

  • Numero massimo di connessioni di peering di reti virtuali per rete virtuale.

  • Numero massimo di prefissi annunciati da ExpressRoute con peering privato da Azure all'ambiente locale.

  • Assicurarsi che il numero di reti virtuali spoke connesse alla rete virtuale hub non superi questi limiti.

Passaggio successivo