Condividi tramite

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 la rete WAN virtuale di Azure.

Hub-spoke è una delle topologie di rete consigliate da Cloud Adoption Framework. Vedere Definire una topologia di rete di Azure per comprendere perché questa topologia è considerata una procedura consigliata per molte organizzazioni.

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.

Concetti relativi a Hub-spoke

Le topologie di rete hub-spoke in genere includono i numerosi concetti architetturali seguenti:

  • Rete virtuale hub : la rete virtuale hub ospita i 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. L'hub contiene il punto principale di uscita e fornisce un meccanismo per connettere uno spoke a un altro in situazioni in cui è necessario il traffico tra reti virtuali.

    Un hub è una risorsa a livello di area. Le organizzazioni con carichi di lavoro in più aree devono avere più hub, uno per area.

    L'hub abilita i concetti seguenti:

    • Gateway cross-premise : la connettività cross-premise è la possibilità di connettersi e integrare ambienti di rete diversi tra loro. Questo gateway è in genere una VPN o un circuito ExpressRoute.

    • Controllo in uscita : gestione e regolamentazione del traffico in uscita originato nelle reti virtuali spoke con peering.

    • (facoltativo) Controllo in ingresso : gestione e regolazione del traffico in ingresso verso gli endpoint presenti nelle reti virtuali spoke con peering.

    • Accesso remoto : l'accesso remoto è il modo in cui si accede ai singoli carichi di lavoro nelle reti spoke dalla posizione di rete diversa dalla rete dello spoke. Potrebbe trattarsi di un piano di controllo o dati del carico di lavoro.

    • Accesso spoke remoto per le macchine virtuali : l'hub può essere una posizione comoda per creare una soluzione di connettività remota tra organizzazioni per RDP e l'accesso SSH alle macchine virtuali distribuite in reti spoke.

    • Routing : gestisce e indirizza il traffico tra l'hub e gli spoke connessi per consentire comunicazioni sicure ed efficienti.

  • 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. Un carico di lavoro può anche essere distribuito tra più spoke.

    Nella maggior parte degli scenari, un spoke deve essere sottoposto a peering solo a una singola rete hub e tale rete hub deve trovarsi nella stessa area dello spoke.

    Queste reti spoke seguono le regole per l'accesso in uscita predefinito. Lo scopo principale di questa topologia di rete hub-spoke è in genere indirizzare il traffico Internet in uscita attraverso i meccanismi di controllo offerti dall'hub.

  • Connettività tra reti virtuali: la connettività di rete virtuale è il percorso in cui una rete virtuale isolata può comunicare con un'altra tramite un meccanismo di controllo. Il meccanismo di controllo applica le autorizzazioni e la direzione consentita delle comunicazioni tra reti. Un hub fornirà un'opzione per supportare le connessioni tra reti selezionate per il flusso attraverso la rete centralizzata.

  • DNS : le soluzioni hub-spoke sono spesso responsabili della fornitura di una soluzione DNS da usare da tutti gli spoke con peering, in particolare per il routing cross-premise e per i record DNS dell'endpoint privato.

Componenti

  • La rete virtuale di Azure è il blocco predefinito fondamentale per le 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.

    Questa architettura connette le reti virtuali all'hub usando connessioni di peering non transitive e a bassa latenza tra reti virtuali. Le reti virtuali con peering possono scambiare traffico tramite il backbone di Azure senza bisogno di un router. In un'architettura hub-spoke, il peering diretto delle reti virtuali tra loro è minimo e riservato per scenari di casi speciali.

  • 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. In questa architettura, Azure Bastion viene usato come offerta gestita per supportare l'accesso diretto alle macchine virtuali tra spoke connessi.

  • 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.

    In questa architettura Firewall di Azure ha più ruoli potenziali. Il firewall è il punto di uscita primario per il traffico destinato a Internet dalle reti virtuali spoke con peering. Il firewall può essere usato anche per controllare il traffico in ingresso, usando le regole IDPS. Infine, il firewall può essere usato anche come server proxy DNS per supportare le regole di traffico FQDN.

  • Il gateway VPN è un tipo specifico di gateway di rete virtuale che invia traffico crittografato tra una rete virtuale in Azure e una rete diversa tramite la rete Internet pubblica. È anche possibile usare il gateway VPN per inviare traffico crittografato tra altre reti virtuali hub tramite la rete Microsoft.

    In questa architettura, questa sarebbe un'opzione per connettere alcuni o tutti gli spoke alla rete remota. Gli spoke in genere non distribuiscono il proprio gateway VPN e usano invece la soluzione centralizzata offerta dall'hub. È necessario stabilire la configurazione del routing per gestire questa connettività.

  • Il gateway Azure ExpressRoute scambia route IP e instrada il traffico di rete tra la rete locale e la rete virtuale di Azure. In questa architettura ExpressRoute è l'opzione alternativa a un gateway VPN per connettere alcuni o tutti gli spoke a una rete remota. Gli spoke non distribuivano expressRoute e invece questi spoke userebbero la soluzione centralizzata offerta dall'hub. Analogamente a un gateway VPN, è necessario stabilire la configurazione di routing per gestire questa connettività.

  • 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. In questa architettura Monitoraggio di Azure è il sink di log e metrica per le risorse hub e per le metriche di rete. Monitoraggio di Azure può essere usato anche come sink di registrazione per le risorse nelle reti spoke, ma si tratta di una decisione per i vari carichi di lavoro connessi e non è richiesto da questa architettura.

Alternative

Questa architettura implica la creazione, la configurazione e la manutenzione di diverse primitive di risorse di Azure, ovvero virtualNetworkPeerings, routeTablese subnets. Gestione rete virtuale di Azure è un servizio di gestione che consente di raggruppare, configurare, distribuire e gestire reti virtuali su larga scala tra sottoscrizioni, aree e directory di Microsoft Entra di Azure. Con Virtual Network Manager è possibile definire gruppi di rete per identificare e segmentare logicamente le reti virtuali. È possibile usare gruppi connessi che consentono alle reti virtuali all'interno di un gruppo di comunicare tra loro come se fossero connesse manualmente. Questo livello aggiunge un livello di astrazione su tali primitive per concentrarsi sulla descrizione della topologia di rete e sull'uso dell'implementazione di tale topologia.

È consigliabile valutare l'uso di Virtual Network Manager come modo per ottimizzare la spesa in termini di tempo con le operazioni di gestione della rete. Valutare il costo del servizio rispetto al valore/risparmio calcolato per determinare se Virtual Network Manger è un vantaggio netto per le dimensioni e la complessità della rete.

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 la rete WAN virtuale di Azure.

I vantaggi dell'uso di una configurazione hub e spoke gestito dal cliente includono:

  • Risparmi sui costi
  • Superamento dei limiti delle sottoscrizioni
  • Isolamento del carico di lavoro
  • Flessibilità
    • Maggiore controllo sul modo in cui vengono distribuite le appliance virtuali di rete, ad esempio il numero di schede di interfaccia di rete, il numero di istanze o le dimensioni di calcolo.
    • Uso di appliance virtuali di rete non supportate dalla rete WAN virtuale

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.

Zone di destinazione di Azure

L'architettura della zona di destinazione di Azure si basa sulla topologia hub-spoke. In tale architettura, le risorse condivise e la rete dell'hub vengono gestite da un team centralizzato della piattaforma, mentre gli spoke condividono un modello di coproprietà con il team della piattaforma e il team del carico di lavoro che usa la rete spoke. Tutti gli hub risiedono in una sottoscrizione "Connettività" per la gestione centralizzata, mentre le reti virtuali spoke esistono in molte sottoscrizioni di carichi di lavoro singole, denominate sottoscrizioni dell'area di destinazione dell'applicazione.

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 26. L'intervallo /26 di indirizzi offre alla subnet opzioni di configurazione di scalabilità sufficienti per evitare di raggiungere le limitazioni delle dimensioni del gateway in futuro e di adattarsi a un numero più elevato di circuiti ExpressRoute. Per altre informazioni sulla configurazione del gateway, vedere Rete ibrida con un gateway 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. I gruppi connessi presentano anche limitazioni. Per altre informazioni, vedere Limiti di rete e Limiti dei gruppi connessi.

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 consentirà agli spoke di connettersi tra loro. Per supportare questa configurazione, è necessario implementare Firewall di Azure con la configurazione di tunnel forzato abilitata. Per altre informazioni, vedere Tunneling forzato di Firewall di Azure.

La topologia in questa progettazione architettonica facilita i flussi in uscita. Anche se Firewall di Azure è destinato principalmente alla 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 Gestione rete virtuale di Azure.

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.
  • Il collegamento privato può essere usato per esporre in modo selettivo singole risorse ad altre reti virtuali. Ad esempio, l'esposizione di un servizio di bilanciamento del carico interno a una rete virtuale diversa, senza dover formare o gestire relazioni di peering o routing.

Per altre informazioni sui modelli di rete spoke-to-spoke, vedere Rete spoke-spoke.

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 con 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.

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

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

Considerazioni

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

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Usare le zone di disponibilità per i servizi di Azure nell'hub che li supportano.

Come regola generale, è consigliabile avere almeno un hub per area e connettere solo gli spoke a tali hub dalla stessa area. Questa configurazione consente alle aree della testa bulk di evitare un errore nell'hub di un'area causando errori di routing di rete diffusi in aree non correlate.

Per una disponibilità più elevata, è possibile usare ExpressRoute più una rete VPN per il failover. Vedere Connettere una rete locale ad Azure usando ExpressRoute con failover VPN e seguire le indicazioni per progettare e progettare Azure ExpressRoute per la resilienza.

A causa del modo in cui Firewall di Azure implementa le regole dell'applicazione FQDN, assicurarsi che tutte le risorse in uscita attraverso il firewall usino lo stesso provider DNS del firewall stesso. Senza questo, Firewall di Azure potrebbe bloccare il traffico legittimo perché la risoluzione IP del firewall del nome di dominio completo differisce dalla risoluzione IP dell'origine del traffico dello stesso FQDN. L'incorporazione del proxy di Firewall di Azure come parte della risoluzione DNS spoke è una soluzione per garantire che i nomi di dominio completi siano sincronizzati sia con l'origine del traffico che con Firewall di Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.

Per proteggersi dagli attacchi DDoS, abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale. Qualsiasi risorsa con un indirizzo IP pubblico è soggetta a un attacco DDoS. Anche se i carichi di lavoro non sono esposti pubblicamente, sono ancora disponibili indirizzi IP pubblici che devono essere protetti, ad esempio:

  • Indirizzi IP pubblici di Firewall di Azure
  • Indirizzi IP pubblici del gateway VPN
  • IP pubblico del piano di controllo di ExpressRoute

Per ridurre al minimo il rischio di accesso non autorizzato e applicare criteri di sicurezza rigorosi, impostare sempre regole di negazione esplicite nei gruppi di sicurezza di rete.

Usare la versione Premium di Firewall di Azure per abilitare l'ispezione TLS, il rilevamento delle intrusioni e il sistema di prevenzione delle intrusioni di rete (IDPS) e il filtro URL.

Sicurezza di Virtual Network Manager

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 amministrazione della sicurezza in Virtual Network Manager.

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

Ottimizzazione costi

L'ottimizzazione dei costi riguarda i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione 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?

Peering diretto

L'uso selettivo del peering diretto o di altre comunicazioni indirizzate non hub tra spoke può evitare il costo dell'elaborazione di Firewall di Azure. I risparmi possono essere significativi per le reti con carichi di lavoro con velocità effettiva elevata, comunicazioni a basso rischio tra spoke, ad esempio la sincronizzazione del database o le operazioni di copia di file di grandi dimensioni.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Abilitare le impostazioni di diagnostica per tutti i servizi, ad esempio Azure Bastion, Firewall di Azure e il gateway cross-premise. Determinare quali impostazioni sono significative per le operazioni. Disattivare le impostazioni che non sono significative per evitare costi non dovuti. Le risorse come Firewall di Azure possono essere dettagliate con la registrazione ed è possibile sostenere costi di monitoraggio elevati.

Usare Monitoraggio connessione per il monitoraggio end-to-end per rilevare anomalie e per identificare e risolvere i problemi di rete.

Usare Azure Network Watcher per monitorare e risolvere i problemi dei componenti di rete, incluso l'uso di Analisi del traffico per mostrare i sistemi nelle reti virtuali che generano il maggior traffico. È possibile identificare visivamente i colli di bottiglia prima che diventino problemi.

Se si usa ExpressRoute, usare l'agente di raccolta traffico ExpressRoute in cui è possibile analizzare i log di flusso per i flussi di rete inviati sui circuiti ExpressRoute. L'agente di raccolta traffico ExpressRoute offre visibilità sul traffico che scorre sui router perimetrali aziendali Microsoft.

Usare le regole basate su FQDN in Firewall di Azure per protocolli diversi da HTTP o durante la configurazione di SQL Server. L'uso dei nomi di dominio completi riduce il carico di gestione sulla gestione dei singoli indirizzi IP.

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.

Automazione con Gestione rete virtuale di Azure

Per gestire centralmente i controlli di connettività e sicurezza, usare Gestione rete virtuale di Azure 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 Virtual Network 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 Virtual Network 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 Virtual Network 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 Gestione rete virtuale di Azure.

Per semplificare e semplificare il processo di creazione e gestione delle configurazioni di route, è possibile usare la gestione automatizzata delle route definite dall'utente in Gestione rete virtuale di Azure.

Per semplificare e centralizzare la gestione degli indirizzi IP, è possibile usare gestione degli indirizzi IP in Gestione rete virtuale di Azure. Gestione indirizzi IP impedisce conflitti di spazio indirizzi IP tra reti virtuali locali e cloud.

Per iniziare a usare Virtual Network Manager, vedere Creare una topologia hub-spoke con Gestione rete virtuale di Azure.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Per i carichi di lavoro che comunicano dall'ambiente locale alle macchine virtuali in una rete virtuale di Azure che richiedono bassa latenza e larghezza di banda elevata, è consigliabile usare ExpressRoute FastPath. FastPath consente di inviare il traffico direttamente alle macchine virtuali nella rete virtuale dall'ambiente locale, ignorando il gateway di rete virtuale ExpressRoute, aumentando le prestazioni.

Per le comunicazioni spoke-to-spoke che richiedono bassa latenza, è consigliabile configurare la rete spoke-to-spoke.

Scegliere lo SKU del gateway appropriato che soddisfi i requisiti, ad esempio il numero di connessioni da punto a sito o da sito a sito, i pacchetti necessari al secondo, i requisiti di larghezza di banda e i flussi TCP.

Per i flussi sensibili alla latenza, ad esempio SAP o l'accesso all'archiviazione, valutare la possibilità di ignorare Firewall di Azure o anche di instradare l'hub. È possibile testare la latenza introdotta da Firewall di Azure per informare la decisione. È possibile usare funzionalità come il peering reti virtuali che connette due o più reti o collegamento privato di Azure che consente di connettersi a un servizio tramite un endpoint privato nella rete virtuale.

Comprendere che l'abilitazione di determinate funzionalità in Firewall di Azure, ad esempio il rilevamento delle intrusioni e il sistema di prevenzione (IDPS), riduce la velocità effettiva. Per altre informazioni, vedere Prestazioni di Firewall di Azure.

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.

Collaboratori

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

Autori principali:

Altri contributori:

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

Passaggi successivi

Scenari avanzati

L'architettura può differire da questa semplice architettura hub-spoke. Di seguito è riportato un elenco di indicazioni per alcuni scenari avanzati:

Esplorare le architetture correlate seguenti: