Connettività tra aree e multicloud

Questo articolo illustra come connettere Azure carichi di lavoro in più aree ed estendere la connettività ad altri provider di servizi cloud, ad esempio Amazon Web Services (AWS) e Google Cloud.

Informazioni su questo articolo

Questo articolo illustra le decisioni di progettazione per la connessione Azure reti virtuali tra aree e la definizione di percorsi di rete per i carichi di lavoro in esecuzione in altri cloud. Imparerai quando usare il peering globale di reti virtuali, rete WAN virtuale, ExpressRoute Global Reach, VPN da sito a sito e Server di route Azure per scenari tra aree geografiche e multicloud.

Chi ha bisogno di questo articolo

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

• L'architettura si estende su più aree Azure e richiede la connettività privata tra di esse.
• È necessario connettere Azure carichi di lavoro ad AWS, Google Cloud o a un'altra rete esterna.
• È necessario confrontare Global VNet Peering, rete WAN virtuale, ExpressRoute Global Reach, VPN da sito a sito o Server di route Azure.
• È necessario progettare connettività resiliente per il ripristino di emergenza, l'espansione globale o le operazioni multicloud.

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: includere questo articolo nel percorso di lettura solo se la migrazione si estende su più aree Azure o si connette a un altro cloud. La maggior parte dei progetti lift-and-shift inizia con una singola area e aggiunge la connettività tra aree in un secondo momento quando il ripristino di emergenza o l'espansione geografica diventa una priorità.

Focus sulla modernizzazione: includere questo articolo se la modernizzazione richiede connettività privata esplicita tra aree oltre a quanto illustrato nell'articolo relativo al multi-area. Queste linee guida sono necessarie quando gli spoke in regioni diverse richiedono percorsi di comunicazione diretti o quando la distribuzione attiva-attiva richiede il peering privato tra gli hub regionali.

Focus sul multi-cloud: Questo articolo è la decisione di progettazione centrale. Leggerlo prima di scegliere tra hub-spoke e rete WAN virtuale per l'architettura di transito tra cloud. Questo articolo viene usato per individuare la topologia multicloud esistente, eseguire il mapping dei servizi tra AWS o Google Cloud e Azure e definire come Azure si connette ai carichi di lavoro che rimangono in altri cloud durante la migrazione.

Azure servizi e funzionalità

Azure offre diversi servizi per la connettività tra aree e multicloud. Ogni servizio soddisfa requisiti di scalabilità, larghezza di banda e gestione diversi.

Service	Elementi forniti	Quando usarlo
Peering reti virtuali globale	Connettività privata a bassa latenza tra reti virtuali in aree Azure diverse. Il traffico rimane sul backbone Microsoft. La larghezza di banda è limitata solo dallo SKU della macchina virtuale, non da un gateway.	Comunicazione diretta tra due VNet in regioni diverse senza un'appliance gateway.
rete WAN virtuale di Azure (livello Standard)	Hub di transito globale gestito da Microsoft che connette VNets, filiali e utenti remoti in tutte le regioni. Fornisce il routing transitivo tra tutte le reti connesse.	Organizzazioni con molte regioni e filiali che richiedono connettività tra qualsiasi punto senza gestire singole connessioni di peering.
ExpressRoute tramite Cloud Exchange	Connessione cross-cloud dedicata tramite un provider di scambio di terze parti (ad esempio Equinix o Megaport). Fornisce connettività privata e a larghezza di banda elevata per AWS o Google Cloud.	Architetture multicloud con requisiti del contratto di servizio per la larghezza di banda in cui il traffico non deve attraversare la rete Internet pubblica.
VPN da sito a sito ad altri cloud	Tunnel IPsec crittografato tra Gateway VPN di Azure e un altro gateway VPN del provider di servizi cloud (AWS Virtual Private Gateway o Google Cloud VPN).	Connettività multicloud per scenari di test, sviluppo o produzione in cui i circuiti dedicati non sono giustificati.
Server di route Azure	Abilita lo scambio di route BGP dinamico tra la rete virtuale e le appliance virtuali di rete. Immette le route apprese da NVA nel fabric di routing SDN di Azure.	Routing personalizzato con NVA (appliance virtuali di rete) di terze parti in una rete virtuale hub, o routing multi-cloud complesso che richiede la propagazione BGP verso le reti connesse ad Azure.

Come funziona il peering globale delle VNet

Global VNet Peering crea un collegamento diretto tra due reti virtuali in aree di Azure diverse. Il collegamento viene eseguito interamente sul backbone Microsoft e non attraversa mai la rete Internet pubblica. Dopo aver configurato una relazione di peering, le risorse in ogni rete virtuale possono comunicare usando indirizzi IP privati come se fossero nella stessa rete.

A differenza degli approcci basati su gateway, il peering non introduce un singolo punto critico. La larghezza di banda tra reti virtuali connesse tramite peering varia in funzione dello SKU della macchina virtuale su ciascun lato. Non esiste un'appliance gateway dedicata che limiti la capacità effettiva. Questa configurazione rende Global VNet Peering l’opzione a minore latenza per la comunicazione tra aree geografiche tra un numero limitato di reti virtuali.

Tuttavia, il peering non è transitivo per impostazione predefinita. Se la rete virtuale A è in peering con la rete virtuale B e la rete virtuale B è in peering con la rete virtuale C, il traffico dalla rete virtuale A non può raggiungere la rete virtuale C tramite la rete virtuale B. Ogni coppia di reti virtuali che necessita di una comunicazione diretta deve disporre di un proprio collegamento di peering. In un modello hub-spoke, questo significa che in genere si collegano in peering tra loro le reti virtuali degli hub regionali e si usano route definite dall'utente (UDR) o NVA per inoltrare il traffico tra spoke di aree geografiche diverse attraverso gli hub.

rete WAN virtuale transito globale

rete WAN virtuale di Azure (livello Standard) rimuove la necessità di configurare manualmente il peering tra hub a livello di area. Quando si distribuiscono hub rete WAN virtuale in più aree, Microsoft stabilisce automaticamente connessioni da hub a hub tramite il backbone. I percorsi appresi da un hub si propagano a tutti gli altri hub, creando una rete di transito tra qualsiasi coppia di hub.

Questo routing automatico significa che una rete virtuale spoke connessa a un hub negli Stati Uniti orientali può raggiungere una rete virtuale spoke connessa a un hub in Europa occidentale senza alcuna configurazione aggiuntiva di peering o tabella di route. rete WAN virtuale estende anche questa transitività alle succursali (connesse tramite VPN da sito a sito o ExpressRoute) e agli utenti remoti (connessi tramite VPN da punto a sito). Il risultato è una rete globale completamente interconnessa, gestita da Microsoft.

Per l'ispezione del traffico tra aree geografiche, abilitare Routing Intent sugli hub virtuali protetti. L'intento di instradamento forza il traffico tra gli hub attraverso Firewall di Azure, offrendo visibilità centralizzata e applicazione dei criteri in tutte le aree geografiche senza dover distribuire e gestire singole appliance virtuali di rete in ogni hub.

Come scegliere

Usare le tabelle decisionali seguenti per selezionare l'approccio di connettività appropriato per lo scenario in uso.

Opzioni di connettività tra aree

Il tuo scenario	Approccio consigliato	Perché
Due reti virtuali in aree diverse richiedono la comunicazione diretta	Peering reti virtuali globale	Latenza più bassa rispetto ai percorsi Internet, nessun collo di bottiglia del gateway, semplice da configurare. La larghezza di banda dipende dalla SKU della VM.
Molte aree, molti rami, transito gestito necessario	rete WAN virtuale di Azure (livello Standard)	Fornisce un routing transitivo any-to-any tra tutti gli hub connessi. Microsoft gestisce l'infrastruttura di routing.
Connettere i siti locali tra loro tramite Azure	Copertura globale di ExpressRoute	Collega due circuiti ExpressRoute in modo che il traffico locale attraversi il backbone Microsoft. Non è necessario instradare il traffico passando attraverso le reti virtuali di Azure.
Routing personalizzato o NVA di terze parti in un hub regionale	Server di route Azure	Abilita il peering BGP dinamico tra le NVA e Azure. Le route apprese dalla NVA vengono iniettate automaticamente nelle macchine virtuali spoke.

Opzioni di connettività multicloud

Il tuo scenario	Approccio consigliato	Perché
Larghezza di banda elevata e contratto di servizio necessari per il traffico tra cloud	ExpressRoute tramite provider di Exchange cloud	Fornisce capacità dedicata con latenza prevedibile. Il provider di scambio connette il circuito ExpressRoute al servizio di connessione diretta dell'altro cloud.
Carichi di lavoro con budget limitato, di test o a basso throughput	VPN da sito a sito	Usa la connettività Internet esistente senza costi di circuito. Adatto quando i requisiti di larghezza di banda sono modesti.
Ibrido più multicloud (locale, Azure e un altro cloud)	Copertura globale di ExpressRoute e Exchange cloud	Combina copertura globale per il transito da locale a Azure con uno scambio cloud per la connettività da Azure ad altro cloud, creando un backbone privato unificato.

Considerazioni relative alla progettazione

Per la maggior parte delle migrazioni in modalità lift-and-shift, la connettività tra aree è una futura considerazione di espansione anziché un requisito immediato. La distribuzione iniziale è probabilmente destinata a una singola area Azure.

Quando si pianifica l'espansione futura:

• Peering globale di reti virtuali: usare il peering globale di reti virtuali tra reti virtuali hub regionali quando si aggiunge una seconda area di Azure. Questo approccio offre connettività privata a bassa latenza senza distribuire un'appliance gateway. Il traffico rimane sul backbone Microsoft e viene ridimensionato con lo SKU della macchina virtuale.
• Complessità differita: evitare di implementare reti WAN virtuali o copertura globale ExpressRoute finché l'ambiente non si espande oltre due regioni o non si aggiungono requisiti di connettività delle filiali.
• Preparazione del ripristino di emergenza: Anche se attualmente non è necessaria la connettività tra aree, documentare i carichi di lavoro che richiedono il ripristino di emergenza e pre-pianificare la topologia di peering in modo da poterla distribuire rapidamente quando necessario.

L'architettura modernizzata usata distribuzioni in modalità attiva-attiva tra aree. Il peering tra aree consente la comunicazione diretta spoke-to-spoke quando i livelli dell'applicazione si estendono su limiti regionali.

Decisioni di progettazione chiave per la modernizzazione:

• Peering multi-area per configurazioni attive-attive: configurare il peering delle reti virtuali hub delle aree primaria e di backup per consentire il flusso di traffico bidirezionale. I team applicativi negli spoke ContosoBiz e ContosoCare possono raggiungere le risorse in entrambe le aree geografiche tramite il percorso di peering dell'hub.
• Instradamento tramite hub: poiché il peering globale delle reti virtuali non è transitivo, instradare il traffico spoke tra aree geografiche tramite la NVA dell'hub regionale o Firewall di Azure. Usare route definite dall'utente (UDR) per instradare il traffico spoke-to-spoke tra aree diverse attraverso il firewall dell'hub per l'ispezione del traffico.
• Peering selettivo: non tutti gli spoke necessitano di connettività tra aree. Effettuare il peering solo delle reti virtuali hub e usare la propagazione delle route per raggiungere specifiche reti virtuali spoke che partecipano a carichi di lavoro attivo-attivo.

Questo articolo illustra come progettare l'architettura di connettività multicloud. Prima di pianificare Azure'infrastruttura, è necessario individuare la topologia cloud esistente e mappare i servizi tra provider.

Flusso di lavoro di individuazione multi-cloud

1. Individuare la topologia esistente: Usare l'individuazione del carico di lavoro in AWS e Google Cloud Network Intelligence Center per eseguire il mapping della topologia VPC (Virtual Private Cloud), delle relazioni di peering e dei modelli di flusso del traffico correnti.
2. Identificare i flussi di traffico: Documentare le comunicazioni da VPC a VPC, percorsi internet in ingresso e in uscita e connessioni da ramo a cloud nell'ambiente AWS o Google Cloud.
3. Mappare i servizi alle controparti di Azure: Le corrispondenze principali per la progettazione della connettività sono:

AWS/Servizio Google Cloud	Equivalente di Azure
Gateway di transito	Rete WAN virtuale di Azure
VPC / Rete VPC	Rete virtuale di Azure
Gruppi di sicurezza/Regole del firewall	Gruppi di sicurezza di rete (NSG)

Per i mapping completi di servizi da AWS a Azure e da Google Cloud a Azure, vedere Elenco di controllo di Cross-Cloud Discovery.

Decisioni sull'architettura della connettività

Dopo aver completato il rilevamento e la mappatura dei servizi, decidi:

• Modello di transito: Scegliere rete WAN virtuale se sono presenti più VPC, rami, aree o bordi cloud. La rete WAN virtuale fornisce l'equivalente in Azure di AWS Transit Gateway con routing any-to-any gestito.
• VPN cross-cloud: Distribuisci le connessioni Gateway VPN dal tuo hub rete WAN virtuale (o hub VNet) ad AWS Virtual Private Gateway e a Google Cloud VPN. Usare i tunnel IPsec per le comunicazioni tra cloud crittografate.
• Applicazioni che rimangono: Identificare i carichi di lavoro che rimangono in AWS o Google Cloud durante la migrazione. Questi carichi di lavoro necessitano di connettività permanente tramite i tunnel VPN tra cloud fino al completamento della migrazione.

Prerequisiti

Prima di implementare la connettività tra aree o multicloud, verificare i requisiti seguenti:

• Due o più aree Azure con reti virtuali distribuite: i carichi di lavoro devono già esistere (o essere pianificati) in più aree. Vedere l'articolo Reti virtuali e subnet per indicazioni sulla pianificazione della rete virtuale.
• Topologia hub-spoke o rete WAN virtuale: le progettazioni tra aree si basano su una topologia stabilita in ogni area. Consultare l'articolo su hub-spoke o l'articolo su rete WAN virtuale.
• Circuiti ExpressRoute (per Copertura globale): Se si prevede di connettere i siti locali, sono necessari circuiti ExpressRoute esistenti in ogni posizione. Vedere l'articolo sulla connettività ibrida.
• Accesso tra account cloud: Per la connettività VPN multicloud o di scambio, è necessario l'accesso amministrativo alla console di rete dell'altro provider di servizi cloud per configurare il lato remoto della connessione.

Considerazioni relative alla sicurezza

La connettività tra aree e multicloud introduce problemi di sicurezza specifici che non esistono nelle distribuzioni a singola area.

Ispezione del traffico tra aree

Il peering globale di VNet non è transitivo. Il traffico tra reti virtuali con peering scorre direttamente senza passare attraverso un firewall o un punto di ispezione. Se è necessario esaminare il traffico tra aree, instradarlo tramite un'appliance virtuale di rete o Firewall di Azure in ogni hub a livello di area.

Per rete WAN virtuale, abilita Routing Intent con criteri per il traffico privato negli hub virtuali protetti. La finalità di routing forza il traffico tra hub attraverso firewall gestiti da Gestione firewall di Azure, che fornisce un'ispezione centralizzata del traffico tra aree. Questa configurazione richiede il livello di rete WAN virtuale Standard.

Crittografare le connessioni tra cloud

I tunnel VPN da sito a sito ad altri cloud vengono crittografati per impostazione predefinita (IPsec/IKE). Tuttavia, le connessioni ExpressRoute tramite uno scambio cloud sono private ma non crittografate a livello di rete. Se è necessaria la crittografia tramite ExpressRoute, distribuire MACsec nei circuiti ExpressRoute Direct o usare la crittografia TLS a livello di applicazione.

Per il traffico multi-cloud che attraversa un cloud exchange senza overlay VPN, prendere in considerazione l'implementazione di un tunnel IPsec basato su un'appliance virtuale di rete all'interno del percorso ExpressRoute. Questo approccio aggiunge la crittografia senza rinunciare ai vantaggi della larghezza di banda e della latenza di un circuito dedicato. In alternativa, usare tls reciproco (mTLS) a livello di applicazione in modo che ogni endpoint del servizio convalide l'identità e crittografi i dati indipendentemente dal trasporto sottostante. La scelta dipende dal fatto che sia necessaria la crittografia a livello di rete (tutto il traffico) o che sia possibile applicare la crittografia a livello di applicazione.

Considerazioni sui costi

Tutta la connettività tra aree comporta addebiti per il trasferimento dei dati. Global VNet Peering, il traffico tra hub di rete WAN virtuale e i tunnel interregionali di Gateway VPN utilizzano tutti un modello di tariffazione basato sul traffico in uscita. Le tariffe variano in base alla coppia di zone:

• Intra-continental (ad esempio, Stati Uniti orientali e Stati Uniti occidentali): tariffa inferiore per GB, in genere nell'intervallo di prezzi standard in uscita per l'area.
• Intercontinentale (ad esempio, da Stati Uniti orientali a Europa occidentale): tariffa per GB più elevata a causa delle maggiori distanze della rete backbone e della capacità intercontinentale.

rete WAN virtuale aggiunge un addebito per unità di connessione per ogni rete virtuale spoke o filiale collegata a un hub, oltre a un addebito per l'elaborazione dei dati per il traffico che transita attraverso un hub protetto in cui è in esecuzione Firewall di Azure. Questo modello tariffario a più livelli significa che rete WAN virtuale può costare più del semplice Global VNet Peering per architetture con solo poche aree geografiche e pochi spoke, ma offre migliori economie unitarie su larga scala quando si connettono decine di filiali e aree geografiche.

Per la connettività multi-cloud, ExpressRoute tramite un cloud exchange comporta costi delle porte e tariffe di multi-connect del provider del cloud exchange, oltre ai costi del circuito Azure ExpressRoute e ai costi del servizio di connessione diretta dell'altro cloud. La VPN da sito a sito evita i costi del circuito, ma comporta comunque addebiti standard in uscita per i dati che lasciano Azure.

Indicazioni: Colocare carichi di lavoro ad alto traffico nella stessa area, quando possibile. Riservare percorsi interregionali per la sincronizzazione del piano di controllo, la replica asincrona e il failover per il disaster recovery, che in genere comportano volumi di traffico inferiori.

Modelli di ripristino di emergenza

La connettività tra aree è fondamentale per il ripristino di emergenza. Il modello scelto determina l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO).

Active-active

Entrambe le aree gestiscono il traffico di produzione contemporaneamente. Un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure o Gestione traffico di Azure, distribuisce le richieste tra aree. Se un'area ha esito negativo, il traffico passa all'area rimanente con interruzioni minime. Questo modello offre l'obiettivo RTO più basso (secondi a minuti), ma richiede un'infrastruttura completa in entrambe le aree e la sincronizzazione dei dati bidirezionali, aumentando i costi e la complessità.

Active-passive

Un'area gestisce il traffico di produzione, mentre la seconda area rimane in standby con un'infrastruttura preinstallata (ma potenzialmente dimensionata al ribasso). La replica mantiene aggiornati i dati dell'area passiva. In caso di errore, si promuove l'area passiva e si reindirizza il traffico. L'RTO dipende dalla rapidità con cui si scalano le risorse passive e si completa il failover DNS o del bilanciatore del carico, in genere da pochi minuti a qualche decina di minuti.

Luce pilota

Una presenza minima nella regione secondaria (database in fase di replica, rete core implementata) senza capacità di calcolo attiva. Durante il failover, si distribuiscono o si ridimensionano le risorse di calcolo dell'applicazione e si reindirizza il traffico. Questo modello riduce al minimo i costi dello stato costante, ma aumenta l'RTO perché le risorse di calcolo devono iniziare prima che l'area possa gestire il traffico.

In tutti gli schemi, la connettività tra aree geografiche (Global macchina virtuale Peering o inter-hub di rete WAN virtuale) fornisce il percorso dati privato per il traffico di replica. Assicurarsi che i runbook di disaster recovery tengano conto di eventuali ritardi nella propagazione delle route e verificare che le regole del gruppo di sicurezza di rete (NSG) nella regione secondaria consentano il traffico di failover.

Vincoli di chiave

Constraint	Impatto
Il peering delle reti virtuali globali non è transitivo	Il fatto che la rete virtuale A sia in peering con la rete virtuale B e che la rete virtuale B sia in peering con la rete virtuale C non significa che A possa raggiungere C. È necessario configurare un peering diretto tra A e C oppure usare una soluzione di transito come rete WAN virtuale.
Il livello Basic di rete WAN virtuale non supporta la transitività	Basic rete WAN virtuale non supporta la connettività transitiva da VNet a VNet. Usare il livello Standard per il transito tra aree.
Global Reach di ExpressRoute richiede lo SKU Premium per le connessioni tra aree geopolitiche diverse	I circuiti in aree geopolitiche diverse (ad esempio, Stati Uniti ed Europa) richiedono il componente aggiuntivo Premium. I circuiti SKU Standard si connettono solo all'interno dello stesso limite geopolitico.
Gateway VPN attivo-attivo consigliato per AWS	AWS Virtual Private Gateway crea due tunnel per ogni connessione VPN. Configurare Gateway VPN di Azure in modalità attiva-attiva per usare tutti i tunnel disponibili ed evitare il routing asimmetrico.

Articoli correlati

• Reti virtuali e subnet: nozioni fondamentali sulla pianificazione della rete virtuale a cui fa riferimento questo articolo.
• Connettività ibrida: ExpressRoute e Gateway VPN basi su cui si basa la connettività tra aree.
• Topologia hub-spoke: modelli di progettazione hub-spoke regionali che si estendono alle architetture multi-area.
• topologia rete WAN virtuale: transito globale gestito con hub di rete WAN virtuale.
• Gestione centralizzata della rete: gestione rete virtuale di Azure per la gestione del peering su larga scala tra aree.

Ulteriori informazioni

• Panoramica del peering di rete virtuale: include le funzionalità del peering globale di reti virtuali, il comportamento della larghezza di banda e la configurazione.
• rete WAN virtuale architettura di transito globale: come rete WAN virtuale consente qualsiasi transito tra aree.
• Copertura globale di ExpressRoute: connettere reti locali tramite circuiti ExpressRoute.
• Connettere Azure ad AWS tramite VPN BGP: esercitazione dettagliata per vpn multicloud ad AWS.
• Panoramica del Server di route Azure: instradamento BGP dinamico con appliance virtuali di rete in Azure.
• Concetti relativi ai prezzi di rete WAN virtuale: Informazioni sui costi di trasferimento dei dati tra hub e tra aree geografiche.

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:

Rete in più aree: pianificare la connettività e il failover di più aree se la migrazione si espande oltre un'area.

Nel prossimo percorso di modernizzazione:

Monitoraggio e osservabilità della rete: abilitare l'osservabilità tra le aree per l'idoneità alla produzione.

Il prossimo passo nel tuo percorso multicloud:

Topologia di rete WAN virtuale: Usare rete WAN virtuale come hub di transito per la connettività multicloud e multibranch.