Modifica

Topologia di rete hub-spoke in Azure

Azure Bastion
Firewall di Azure
Azure Network Watcher
Rete virtuale di Azure
Gateway VPN di Azure

Questa architettura di riferimento implementa un modello di rete hub-spoke con i componenti dell'infrastruttura dell'hub gestito dal cliente. Per una soluzione di infrastruttura dell'hub gestito da Microsoft, vedere Topologia di rete hub-spoke con Azure rete WAN virtuale.

Architettura

Diagramma che mostra una topologia di rete virtuale hub-spoke in Azure con reti spoke connesse tramite l'hub o direttamente.

Scaricare un file di Visio di questa architettura.

Workflow

Questa configurazione di rete hub-spoke usa gli elementi architetturali seguenti:

  • Rete virtuale hub. La rete virtuale hub ospita servizi condivisi di Azure. I carichi di lavoro ospitati nelle reti virtuali spoke possono usare questi servizi. La rete virtuale hub è il punto centrale di connettività per le reti cross-premise.

  • Reti virtuali spoke. Le reti virtuali spoke isolano e gestiscono i carichi di lavoro separatamente in ogni spoke. Ogni carico di lavoro può includere più livelli, con più subnet connesse tramite servizi di bilanciamento del carico di Azure. Gli spoke possono esistere in sottoscrizioni diverse e rappresentano ambienti diversi, ad esempio Produzione e Non produzione.

  • Connettività di rete virtuale. Questa architettura connette le reti virtuali usando connessioni di peering o gruppi connessi. Le connessioni di peering e i gruppi connessi sono connessioni non transitive e a bassa latenza tra reti virtuali. Le reti virtuali con peering o connesse possono scambiare traffico attraverso il backbone di Azure senza bisogno di un router. Azure Rete virtuale Manager crea e gestisce i gruppi di rete e le relative connessioni.

  • Host Azure Bastion. Azure Bastion offre connettività sicura dal portale di Azure alle macchine virtuali usando il browser. Un host Azure Bastion distribuito all'interno di una rete virtuale di Azure può accedere alle macchine virtuali in tale rete virtuale o nelle reti virtuali connesse.

  • Firewall di Azure. Un'istanza del firewall gestita Firewall di Azure esiste nella propria subnet.

  • Azure Gateway VPN o il gateway Azure ExpressRoute. Un gateway di rete virtuale consente a una rete virtuale di connettersi a un dispositivo di rete privata virtuale (VPN) o a un circuito Azure ExpressRoute. Il gateway fornisce connettività di rete cross-premise. Per altre informazioni, vedere Connessione una rete locale a una rete virtuale di Microsoft Azure ed Estendere una rete locale tramite VPN.

  • Dispositivo VPN. Un dispositivo VPN o un servizio fornisce connettività esterna alla rete cross-premise. Il dispositivo VPN può essere un dispositivo hardware o una soluzione software, ad esempio routing e servizio di accesso remoto (RRAS) in Windows Server. Per altre informazioni, vedere Convalidare i dispositivi VPN e le guide alla configurazione dei dispositivi.

Componenti

  • Rete virtuale Manager è un servizio di gestione che consente di raggruppare, configurare, distribuire e gestire reti virtuali su larga scala tra sottoscrizioni, aree e tenant di Azure. Con Rete virtuale Manager è possibile definire gruppi di reti virtuali per identificare e segmentare logicamente le reti virtuali. È possibile definire e applicare configurazioni di connettività e sicurezza in tutte le reti virtuali in un gruppo di rete contemporaneamente.

  • Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Rete virtuale consente a molte risorse di Azure, ad esempio macchine virtuali di Azure, di comunicare in modo sicuro tra loro, reti cross-premise e Internet.

  • Azure Bastion è un servizio completamente gestito che offre un accesso RDP (Remote Desktop Protocol) e SSH (Remote Desktop Protocol) più sicuro e facile alle macchine virtuali senza esporre gli indirizzi IP pubblici.

  • Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse Rete virtuale. Questo servizio firewall con stato offre disponibilità elevata predefinita e scalabilità cloud senza restrizioni per creare, applicare e registrare criteri di connettività di rete e applicazioni tra sottoscrizioni e reti virtuali.

  • Gateway VPN è un tipo specifico di gateway di rete virtuale che invia traffico crittografato tra una rete virtuale e una posizione locale tramite Internet pubblico. È anche possibile usare Gateway VPN per inviare traffico crittografato tra reti virtuali di Azure tramite la rete Microsoft.

  • Monitoraggio di Azure può raccogliere, analizzare e agire sui dati di telemetria da ambienti cross-premise, tra cui Azure e locale. Monitoraggio di Azure consente di ottimizzare le prestazioni e la disponibilità delle applicazioni e identificare in modo proattivo i problemi in pochi secondi.

Dettagli dello scenario

Questa architettura di riferimento implementa un modello di rete hub-spoke in cui la rete virtuale hub funge da punto centrale di connettività a molte reti virtuali spoke. Le reti virtuali spoke si connettono all'hub e possono essere usate per isolare i carichi di lavoro. È anche possibile abilitare scenari cross-premise usando l'hub per connettersi alle reti locali.

Questa architettura descrive un modello di rete con i componenti dell'infrastruttura dell'hub gestito dal cliente. Per una soluzione di infrastruttura dell'hub gestito da Microsoft, vedere Topologia di rete hub-spoke con Azure rete WAN virtuale.

I vantaggi dell'uso di una configurazione hub-spoke includono:

  • Risparmi sui costi
  • Superamento dei limiti delle sottoscrizioni
  • Isolamento del carico di lavoro

Per altre informazioni, vedere Topologia di rete Hub-spoke.

Potenziali casi d'uso

Gli usi tipici per un'architettura hub-spoke includono carichi di lavoro che:

  • Avere diversi ambienti che richiedono servizi condivisi. Ad esempio, un carico di lavoro potrebbe avere ambienti di sviluppo, test e produzione. I servizi condivisi possono includere ID DNS, NTP (Network Time Protocol) o Dominio di Active Directory Services (AD DS). I servizi condivisi vengono inseriti nella rete virtuale hub e ogni ambiente viene distribuito in uno spoke diverso per mantenere l'isolamento.
  • Non richiedere la connettività tra loro, ma richiedere l'accesso ai servizi condivisi.
  • Richiedere il controllo centrale sulla sicurezza, ad esempio un firewall di rete perimetrale (noto anche come rete perimetrale) nell'hub con gestione separata dei carichi di lavoro in ogni spoke.
  • Richiedere il controllo centrale sulla connettività, ad esempio connettività selettiva o isolamento tra spoke di determinati ambienti o carichi di lavoro.

Consigli

Le raccomandazioni seguenti si applicano alla maggior parte degli scenari. Seguire queste raccomandazioni, a meno che non siano presenti requisiti specifici che li sostituiscono.

Gruppi di risorse, sottoscrizioni e aree

Questa soluzione di esempio usa un singolo gruppo di risorse di Azure. È anche possibile implementare l'hub e ogni spoke in gruppi di risorse e sottoscrizioni diversi.

Quando si esegue il peering di reti virtuali in sottoscrizioni diverse, è possibile associare le sottoscrizioni agli stessi tenant o a tenant di Microsoft Entra diversi. Questa flessibilità consente la gestione decentralizzata di ogni carico di lavoro mantenendo i servizi condivisi nell'hub. Vedere Creare un peering di rete virtuale - Resource Manager, sottoscrizioni diverse e tenant di Microsoft Entra.

Come regola generale, è consigliabile avere almeno un hub per area. Questa configurazione consente di evitare un singolo punto di errore, ad esempio per evitare che le risorse region A siano interessate a livello di rete da un'interruzione nell'area B.

Subnet della rete virtuale

Le raccomandazioni seguenti illustrano come configurare le subnet nella rete virtuale.

GatewaySubnet

Il gateway di rete virtuale richiede questa subnet. È anche possibile usare una topologia hub-spoke senza un gateway se non è necessaria la connettività di rete cross-premise.

Creare una subnet denominata GatewaySubnet con un intervallo di indirizzi di almeno /27. L'intervallo /27 di indirizzi offre alla subnet opzioni di configurazione di scalabilità sufficienti per evitare di raggiungere le limitazioni delle dimensioni del gateway in futuro. Per altre informazioni sulla configurazione del gateway, vedere le architetture di riferimento seguenti, a seconda del tipo di connessione:

Per una disponibilità più elevata, è possibile usare ExpressRoute più una rete VPN per il failover. Vedere Connettere una rete locale ad Azure tramite ExpressRoute con failover VPN.

AzureFirewallSubnet

Creare una subnet denominata AzureFirewallSubnet con un intervallo di indirizzi di almeno /26. Indipendentemente dalla scalabilità, l'intervallo /26 di indirizzi è la dimensione consigliata e copre eventuali limitazioni delle dimensioni future. Questa subnet non supporta i gruppi di sicurezza di rete.This subnet doesn't support network security groups (NSG).

Firewall di Azure richiede questa subnet. Se si usa un'appliance virtuale di rete del partner, seguire i requisiti di rete.

Connettività di rete spoke

Il peering di rete virtuale o i gruppi connessi sono relazioni non transitive tra reti virtuali. Se sono necessarie reti virtuali spoke per connettersi tra loro, aggiungere una connessione di peering tra questi spoke o inserirle nello stesso gruppo di rete.

Connessioni spoke tramite Firewall di Azure o appliance virtuale di rete

Il numero di peering di rete virtuale per rete virtuale è limitato. Se si hanno molti spoke che devono connettersi tra loro, è possibile esaurire le connessioni di peering. anche i gruppi Connessione ed presentano limitazioni. Per altre informazioni, vedere Limiti di rete e limiti dei gruppi Connessione ed.

In questo scenario è consigliabile usare route definite dall'utente per forzare l'invio del traffico spoke a Firewall di Azure o a un'altra appliance virtuale di rete che funge da router nell'hub. Questa modifica consente agli spoke di connettersi tra loro. Per supportare questa configurazione, è necessario implementare Firewall di Azure con la configurazione del tunnel forzato abilitata. Per altre informazioni, vedere Tunneling forzato di Firewall di Azure.

La topologia in questa progettazione architetturale facilita i flussi in uscita. Anche se Firewall di Azure è principalmente per la sicurezza in uscita, può anche essere un punto di ingresso. Per altre considerazioni sul routing in ingresso dell'appliance virtuale di rete dell'hub, vedere Firewall e gateway applicazione per le reti virtuali.

Connessioni spoke a reti remote tramite un gateway hub

Per configurare gli spoke per comunicare con reti remote tramite un gateway hub, è possibile usare peering di rete virtuale o gruppi di rete connessi.

Per usare i peering di rete virtuale, nella configurazione del peering di rete virtuale:

  • Configurare la connessione di peering nell'hub per Consentire il transito del gateway.
  • Configurare la connessione di peering in ogni spoke per usare il gateway della rete virtuale remota.
  • Configurare tutte le connessioni di peering in Consenti traffico inoltrato.

Per altre informazioni, vedere Creare un peering di rete virtuale.

Per usare i gruppi di rete connessi:

  1. In Rete virtuale Manager creare un gruppo di rete e aggiungere reti virtuali membro.
  2. Creare una configurazione della connettività hub-spoke.
  3. Per i gruppi di rete spoke selezionare Hub come gateway.

Per altre informazioni, vedere Creare una topologia hub-spoke con Azure Rete virtuale Manager.

Comunicazioni di rete spoke

Esistono due modi principali per consentire alle reti virtuali spoke di comunicare tra loro:

  • Comunicazione tramite un'appliance virtuale di rete come un firewall e un router. Questo metodo comporta un hop tra i due spoke.
  • Comunicazione tramite il peering di rete virtuale o Rete virtuale Manager connettività diretta tra spoke. Questo approccio non causa un hop tra i due spoke ed è consigliato per ridurre al minimo la latenza.

Comunicazione tramite un'appliance virtuale di rete

Se è necessaria la connettività tra spoke, è consigliabile distribuire Firewall di Azure o un'altra appliance virtuale di rete nell'hub. Creare quindi route per inoltrare il traffico da uno spoke al firewall o all'appliance virtuale di rete, che può quindi instradare al secondo spoke. In questo scenario occorre configurare le connessioni peering in modo da consentire il traffico inoltrato.

Diagramma che mostra il routing tra spoke usando Firewall di Azure

È anche possibile usare un gateway VPN per instradare il traffico tra spoke, anche se questa scelta influisce sulla latenza e sulla velocità effettiva. Per informazioni dettagliate sulla configurazione, vedere Configurare il transito del gateway VPN per il peering di rete virtuale.

Valutare i servizi condivisi nell'hub per assicurarsi che l'hub venga ridimensionato per un numero maggiore di spoke. Ad esempio, se l'hub fornisce servizi firewall, prendere in considerazione i limiti di larghezza di banda della soluzione firewall quando si aggiungono più spoke. È possibile spostare alcuni di questi servizi condivisi in un secondo livello di hub.

Comunicazione diretta tra reti spoke

Per connettersi direttamente tra reti virtuali spoke senza attraversare la rete virtuale hub, è possibile creare connessioni di peering tra spoke o abilitare la connettività diretta per il gruppo di rete. È consigliabile limitare il peering o la connettività diretta alle reti virtuali spoke che fanno parte dello stesso ambiente e dello stesso carico di lavoro.

Quando si usa Rete virtuale Manager, è possibile aggiungere manualmente reti virtuali spoke ai gruppi di rete o aggiungere automaticamente reti in base alle condizioni definite. Per altre informazioni, vedere Rete spoke-spoke.

Il diagramma seguente illustra l'uso di Rete virtuale Manager per la connettività diretta tra spoke.

Diagramma che mostra l'uso di Rete virtuale Manager per la connettività diretta tra spoke.

Raccomandazioni sulla gestione

Per gestire centralmente i controlli di connettività e sicurezza, usare Rete virtuale Manager per creare nuove topologie di rete virtuale hub-spoke o eseguire l'onboarding di topologie esistenti. L'uso di Rete virtuale Manager garantisce che le topologie di rete hub-spoke siano preparate per una crescita futura su larga scala tra più sottoscrizioni, gruppi di gestione e aree geografiche.

Gli scenari dei casi d'uso di Rete virtuale Manager di esempio includono:

  • Democratizzazione della gestione della rete virtuale spoke a gruppi come business unit o team di applicazioni. La democratizzazione può comportare un numero elevato di requisiti di connettività da rete virtuale a rete virtuale e regole di sicurezza di rete.
  • Standardizzazione di più architetture di replica in più aree di Azure per garantire un footprint globale per le applicazioni.

Per garantire la connettività uniforme e le regole di sicurezza di rete, è possibile usare i gruppi di rete per raggruppare le reti virtuali in qualsiasi sottoscrizione, gruppo di gestione o area nello stesso tenant di Microsoft Entra. È possibile eseguire automaticamente o manualmente l'onboarding delle reti virtuali nei gruppi di rete tramite assegnazioni di appartenenza dinamiche o statiche.

È possibile definire l'individuabilità delle reti virtuali gestite da Rete virtuale Manager tramite ambiti. Questa funzionalità offre flessibilità per un numero desiderato di istanze di gestione di rete, che consente un'ulteriore democratizzazione della gestione per i gruppi di reti virtuali.

Per connettere reti virtuali spoke nello stesso gruppo di rete tra loro, usare Rete virtuale Manager per implementare il peering di rete virtuale o la connettività diretta. Usare l'opzione mesh globale per estendere la connettività diretta mesh alle reti spoke in aree diverse. Il diagramma seguente mostra la connettività mesh globale tra aree.

Diagramma che mostra la connettività diretta della mesh globale spoke sulle aree.

È possibile associare reti virtuali all'interno di un gruppo di rete a un set di base di regole di amministrazione della sicurezza. Le regole di amministrazione della sicurezza del gruppo di rete impediscono ai proprietari della rete virtuale spoke di sovrascrivere le regole di sicurezza di base, consentendo loro di aggiungere in modo indipendente i propri set di regole di sicurezza e gruppi di sicurezza di rete. Per un esempio di uso delle regole di amministrazione della sicurezza nelle topologie hub-spoke, vedere Esercitazione: Creare una rete hub-spoke protetta.

Per facilitare un'implementazione controllata di gruppi di rete, connettività e regole di sicurezza, le distribuzioni di configurazione di Rete virtuale Manager consentono di rilasciare in modo sicuro modifiche di configurazione potenzialmente di rilievo agli ambienti hub e spoke. Per altre informazioni, vedere Distribuzioni di configurazione in Azure Rete virtuale Manager.

Per iniziare a usare Rete virtuale Manager, vedere Creare una topologia hub-spoke con Azure Rete virtuale Manager.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Per garantire un set di base di regole di sicurezza, assicurarsi di associare le regole di amministratore della sicurezza alle reti virtuali nei gruppi di rete. Le regole di amministrazione della sicurezza hanno la precedenza e vengono valutate prima delle regole del gruppo di sicurezza di rete. Come le regole del gruppo di sicurezza di rete, le regole di amministrazione della sicurezza supportano la definizione delle priorità, i tag del servizio e i protocolli L3-L4. Per altre informazioni, vedere Regole di amministratore della sicurezza in Rete virtuale Manager.

Usare le distribuzioni di Rete virtuale Manager per facilitare l'implementazione controllata di modifiche potenzialmente importanti alle regole di sicurezza dei gruppi di rete.

Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Quando si distribuiscono e si gestiscono reti hub-spoke, considerare i fattori correlati ai costi seguenti. Per altre informazioni, vedere Prezzi della rete virtuale.

Firewall di Azure costi

Questa architettura distribuisce un'istanza di Firewall di Azure nella rete hub. L'uso di una distribuzione Firewall di Azure come soluzione condivisa usata da più carichi di lavoro può ridurre significativamente i costi del cloud rispetto ad altre appliance virtuali di rete. Per altre informazioni, vedere Firewall di Azure e appliance virtuali di rete.

Per usare tutte le risorse distribuite in modo efficace, scegliere le dimensioni Firewall di Azure appropriate. Decidere le funzionalità necessarie e il livello più adatto al set corrente di carichi di lavoro. Per informazioni sugli SKU di Firewall di Azure disponibili, vedere Che cos'è Firewall di Azure?

Costi degli indirizzi IP privati

È possibile usare indirizzi IP privati per instradare il traffico tra reti virtuali con peering o tra reti in gruppi connessi. Si applicano le considerazioni sui costi seguenti:

  • Il traffico in ingresso e in uscita viene addebitato a entrambe le estremità delle reti con peering o connesse. Ad esempio, il trasferimento dei dati da una rete virtuale nella zona 1 a un'altra rete virtuale nella zona 2 comporta una velocità di trasferimento in uscita per la zona 1 e una velocità in ingresso per la zona 2.
  • Diverse zone hanno tariffe di trasferimento diverse.

Pianificare l'indirizzamento IP in base ai requisiti di peering e assicurarsi che lo spazio indirizzi non si sovrapponga tra posizioni cross-premise e posizioni di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Usare Azure Network Watcher per monitorare e risolvere i problemi dei componenti di rete con gli strumenti seguenti:

  • Analisi del traffico mostra i sistemi nelle reti virtuali che generano il maggior traffico. È possibile identificare visivamente i colli di bottiglia prima che diventino problemi.
  • Network Monitor prestazioni monitora le informazioni sui circuiti ExpressRoute.
  • La diagnostica VPN consente di risolvere i problemi relativi alle connessioni VPN da sito a sito che connettono le applicazioni agli utenti locali.

Valutare anche la possibilità di abilitare Firewall di Azure registrazione diagnostica per ottenere informazioni più dettagliate sulle richieste DNS e sui risultati di autorizzazione/negazione nei log.

Distribuire lo scenario

Questa distribuzione include una rete virtuale hub e due spoke connessi e distribuisce anche un'istanza Firewall di Azure e un host Azure Bastion. Facoltativamente, la distribuzione può includere macchine virtuali nella prima rete spoke e in un gateway VPN.

È possibile scegliere tra il peering di rete virtuale o i gruppi connessi di Rete virtuale Manager per creare le connessioni di rete. Ogni metodo include diverse opzioni di distribuzione.

Usare il peering di rete virtuale

  1. Eseguire il comando seguente per creare un gruppo di risorse denominato hub-spoke nell'area eastus per la distribuzione. Selezionare Prova per usare una shell incorporata.

    az group create --name hub-spoke --location eastus

  2. Eseguire il comando seguente per scaricare il modello Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke/bicep/main.bicep > main.bicep

  3. Eseguire il comando seguente per distribuire la configurazione della rete hub-spoke, i peering di rete virtuale tra l'hub e gli spoke e un host Azure Bastion. Quando richiesto, immettere un nome utente e una password. È possibile usare questo nome utente e la password per accedere alle macchine virtuali nelle reti spoke.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Per informazioni dettagliate e opzioni di distribuzione aggiuntive, vedere i modelli arm e Bicep hub-spoke che distribuiscono questa soluzione.

Usare i gruppi connessi di Rete virtuale Manager

  1. Eseguire il comando seguente per creare un gruppo di risorse per la distribuzione. Selezionare Prova per usare una shell incorporata.

    az group create --name hub-spoke --location eastus

  2. Eseguire il comando seguente per scaricare il modello Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/main.bicep > main.bicep

  3. Eseguire i comandi seguenti per scaricare tutti i moduli necessari in una nuova directory.

    mkdir modules

curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnm.bicep > modules/avnm.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnmDeploymentScript.bicep > modules/avnmDeploymentScript.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/hub.bicep > modules/hub.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/spoke.bicep > modules/spoke.bicep

  4. Eseguire il comando seguente per distribuire la configurazione di rete hub-spoke, le connessioni di rete virtuale tra l'hub e gli spoke e un host Bastion. Quando richiesto, immettere un nome utente e una password. È possibile usare questo nome utente e la password per accedere alle macchine virtuali nelle reti spoke.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Per informazioni dettagliate e opzioni di distribuzione aggiuntive, vedere i modelli arm e Bicep hub-spoke che distribuiscono questa soluzione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Alejandra): | Senior Customer Engineer

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

  • Per informazioni sugli hub virtuali protetti e sui criteri di sicurezza e routing associati configurati da Firewall di Azure Manager, vedere Che cos'è un hub virtuale protetto?

  • L'hub in una topologia di rete hub-spoke è il componente principale di una sottoscrizione di connettività in una zona di destinazione di Azure. Per altre informazioni sulla creazione di reti su larga scala in Azure con routing e sicurezza gestiti dal cliente o da Microsoft, vedere Definire una topologia di rete di Azure.

Esplorare le architetture correlate seguenti: