Topologia di rete di Azure tradizionale

Importante

Provare la nuova esperienza topologia (anteprima) che offre una visualizzazione delle risorse di Azure per semplificare la gestione dell'inventario e il monitoraggio della rete su larga scala. Usare l'anteprima della topologia per visualizzare le risorse e le relative dipendenze tra sottoscrizioni, aree e località. Selezionare questo collegamento per passare all'esperienza.

Esplorare le considerazioni principali sulla progettazione e le raccomandazioni relative alle topologie di rete in Microsoft Azure.

Diagram that illustrates a traditional Azure network topology.

Figura 1: Topologia di rete di Azure tradizionale.

Considerazioni sulla progettazione:

  • Varie topologie di rete possono connettere più reti virtuali della zona di destinazione. Esempi di topologie di rete includono una rete virtuale flat di grandi dimensioni, più reti virtuali connesse a più circuiti o connessioni di Azure ExpressRoute, hub-spoke, mesh completa e ibrida.

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

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

  • Il peering di reti virtuali e il peering di reti virtuali globale non sono transitivi. Per abilitare una rete di transito, sono necessarie route definite dall'utente e appliance virtuali di rete.To enable a transit network, you need user-defined routes (UDR) and network virtual appliances (NVAs). Per altre informazioni, vedere Topologia di rete hub-spoke in Azure.

  • È possibile condividere un piano di protezione DDoS di Azure in 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 di Azure.

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

    • Il costo di un piano di protezione DDoS di Azure include 100 indirizzi IP pubblici in tutte le reti virtuali protette associate al piano di protezione DDoS. La protezione per più risorse è disponibile a un costo separato. Per altre informazioni sui prezzi del piano di protezione DDoS di Azure, vedere la pagina dei prezzi di Protezione DDoS di Azure o le domande frequenti.

    • Esaminare le risorse supportate dei piani di protezione DDoS di Azure.

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

    • Il traffico da rete a rete potrebbe riscontrare una maggiore latenza, perché il traffico deve raggiungere i router Microsoft Enterprise Edge (M edizione Standard E).

    • Lo SKU del gateway ExpressRoute vincola la larghezza di banda.

    • Distribuire e gestire le route definite dall'utente se è necessario esaminare o registrare le route definite dall'utente per il traffico 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 di Azure.

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

  • L'uso delle metriche BGP per influenzare il routing di ExpressRoute è una modifica della configurazione apportata 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 determinati limiti; sono disponibili un numero massimo di connessioni ExpressRoute per ogni gateway ExpressRoute e il peering privato di ExpressRoute può identificare un numero massimo di route da Azure a locale. Per altre informazioni sui limiti di ExpressRoute, 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 di Azure per semplificare il routing dinamico tra l'appliance virtuale di rete e la rete virtuale. Il server di route di Azure consente di scambiare informazioni di routing direttamente tramite il protocollo BGP (Border Gateway Protocol) tra qualsiasi appliance virtuale di rete che supporta il protocollo di routing BGP e la rete SDN (Software Defined Network) di Azure nella rete virtuale di Azure senza la necessità di configurare o gestire manualmente le tabelle di route.

Raccomandazioni sulla 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.

    • Architettura di rete che si estende su più aree di Azure e peering di reti virtuali globali in grado di connettere 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 è minore di 100 per 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. Usare le reti virtuali della zona di destinazione che si connettono con il peering di rete virtuale a una rete virtuale hub centrale per gli scenari seguenti:

    • Connettività cross-premise tramite ExpressRoute.

    • VPN per la connettività dei rami.

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

    • Protezione internet in uscita tramite Firewall di Azure o un'altra appliance virtuale di rete di terze parti.

Il diagramma seguente illustra la topologia hub-spoke. Questa configurazione consente un controllo del traffico appropriato per soddisfare la maggior parte dei requisiti per la segmentazione e l'ispezione.

Diagram that illustrates a hub-and-spoke network topology.

Figure 2: Topologia di rete hub-spoke.

  • Usare la topologia di più reti virtuali connesse con più circuiti ExpressRoute quando si verifica una di queste condizioni:

    • È necessario un livello elevato di isolamento.

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

    • È stato raggiunto il numero massimo di connessioni per ogni gateway ExpressRoute. Per il numero massimo, vedere l'articolo Limiti di ExpressRoute.

La figura seguente illustra questa topologia.

Diagram that illustrates multiple virtual networks connected with multiple ExpressRoute circuits.

Figura 3: Più reti virtuali connesse con più circuiti ExpressRoute.

  • 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 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 tecnologie di rete o appliance virtuali di rete dei partner, seguire le indicazioni del fornitore partner per assicurarsi che:

    • Il fornitore supporti la distribuzione.

    • Le linee guida supportano la disponibilità elevata e le prestazioni massime.

    • 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 di Protezione DDoS Standard 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 di Azure, non è disponibile alcun supporto per il transito in Azure tra i gateway ExpressRoute e VPN.

  • Se è necessaria la transitività tra ExpressRoute e i gateway VPN in uno scenario hub-spoke, usare il server di route di Azure come descritto in questo scenario di riferimento.

    Diagram that illustrates transitivity between ER and VPN gateways with Azure Route Server.

  • Quando si hanno reti hub-spoke in più aree di Azure e alcune zone di destinazione devono connettersi tra aree, usare il peering di reti virtuali globale per connettere direttamente le reti virtuali della zona di destinazione che devono instradare il traffico tra loro. A seconda dello SKU della macchina virtuale comunicante, il peering di reti virtuali globale può fornire una velocità effettiva di rete elevata. Il traffico tra 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 rete virtuale globale si applicano al traffico.

  • Quando sono presenti reti hub-spoke in più aree di Azure e la maggior parte delle zone di destinazione deve connettersi tra aree (o quando si usa il peering diretto per ignorare le appliance virtuali di rete dell'hub non è compatibile con i requisiti di sicurezza), usare appliance virtuali di rete hub per connettere le reti virtuali hub in ogni area e instradare il traffico tra aree. 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.

    • Il routing tramite ExpressRoute potrebbe comportare un aumento della latenza (a causa della puntina di attacco M edizione Standard E) e lo SKU del gateway ExpressRoute selezionato limita la velocità effettiva.

La figura seguente mostra entrambe le opzioni:

Diagram that illustrates options for hub-to-hub connectivity.

Figura 4: Opzioni per la connettività da hub a hub.

  • Quando due aree di Azure devono connettersi, usare il peering di rete virtuale globale per connettere entrambe le reti virtuali hub.

  • Quando più di due aree di Azure devono connettersi, è consigliabile che le reti virtuali hub in ogni area si connettano agli stessi circuiti ExpressRoute. Il peering di reti virtuali globale richiederebbe 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 reti hub-spoke in tre aree:

Diagram that illustrates ExpressRoute providing hub-to-hub connectivity between multiple regions.

Figura 5: ExpressRoute che fornisce connettività da hub a hub tra più aree.

  • Quando si usano circuiti ExpressRoute per la connettività tra aree, gli spoke in aree diverse comunicano direttamente e ignorano il firewall perché imparano tramite route BGP agli spoke dell'hub remoto. Se sono necessarie appliance virtuali di rete del firewall nelle reti virtuali hub per controllare il traffico tra spoke, è 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 connettività di transito globale tra reti virtuali di zone di destinazione tra aree di Azure e si vuole ridurre al minimo il sovraccarico di gestione della rete, è consigliabile 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 Azure Rete virtuale Manager per gestire la connettività e la configurazione della sicurezza delle reti virtuali a livello globale tra sottoscrizioni.

  • Usare Monitoraggio di Azure per le reti per monitorare lo stato end-to-end delle reti in Azure.

  • Quando si connettono reti virtuali spoke alla rete virtuale dell'hub centrale, è necessario considerare i due limiti seguenti:

    • Numero massimo di connessioni di peering di rete virtuale per rete virtuale.
    • Numero massimo di prefissi annunciati da ExpressRoute con peering privato da Azure a locale.

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