Modelli per connettere altri fornitori di servizi cloud con Google Cloud

Last reviewed 2023-07-05 UTC

Questo documento aiuta i Cloud Architect e i professionisti delle operazioni a decidere come connettere Google Cloud ad altri provider di servizi cloud (CSP) come Amazon Web Services (AWS) e Microsoft Azure. In un design multi-cloud, le connessioni tra i CSP consentono il trasferimento di dati tra le reti virtuali. Questo documento fornisce inoltre informazioni su come implementare l'opzione scelta.

Molte organizzazioni operano su più piattaforme cloud, sia come misura temporanea durante una migrazione sia perché l'organizzazione ha una strategia multi-cloud a lungo termine.

In questo documento sono disponibili diverse opzioni per lo scambio di dati tra Google Cloud e altri CSP:

Queste opzioni differiscono in termini di velocità di trasferimento, latenza, affidabilità, accordi sul livello del servizio (SLA), complessità e costi. Questo documento descrive in dettaglio ciascuna opzione e i relativi vantaggi e svantaggi e termina con un confronto tra tutte le opzioni.

Questo documento illustra i trasferimenti di dati tra macchine virtuali presenti in Google Cloud e in altre reti virtuali di CSP. Per i dati archiviati in altri prodotti Google Cloud come Cloud Storage e BigQuery, consulta la sezione relativa a questi prodotti.

Questo documento può fungere da guida per valutare le opzioni per il trasferimento di dati tra Google Cloud e uno o più altri CSP, in base ai tuoi requisiti e alle tue capacità.

I concetti contenuti in questo documento si applicano a più casi:

  • Quando prevedi di trasferire grandi quantità di dati per un breve periodo di tempo, ad esempio per un progetto di migrazione dei dati.
  • Se esegui trasferimenti di dati continui tra più cloud provider, ad esempio perché i carichi di lavoro di computing vengono eseguiti su un altro CSP, mentre quelli di big data utilizzano Google Cloud.

Considerazioni iniziali

Prima di scegliere come connettere i tuoi ambienti cloud, è importante considerare le regioni scelte in ogni ambiente e disporre di una strategia per il trasferimento di dati che non risiedono in ambienti di rete virtuali.

Scegli regioni cloud

Se sia Google Cloud che le risorse di altri CSP si trovano in regioni geografiche vicine tra loro, i trasferimenti di dati tra provider cloud presentano un vantaggio in termini di costi e latenza.

Il seguente diagramma illustra il flusso di dati tra Google Cloud e altri CSP.Architettura del flusso di dati tra Google Cloud e altri CSP.

Indipendentemente dal metodo di trasferimento, i dati passano da Google Cloud all'altro CSP in questo modo:

  • Dalla regione Google Cloud in cui le risorse sono ospitate sul POP perimetrale di Google.
  • Tramite una struttura di terze parti tra Google Cloud e l'altro CSP.
  • Dal POP perimetrale dell'altro CSP alla regione in cui si trovano le risorse all'interno della rete dell'altro CSP.

I dati che passano dall'altro CSP a Google Cloud seguono lo stesso percorso, ma nella direzione opposta.

Il percorso end-to-end determina la latenza del trasferimento di dati. Per alcune soluzioni, i costi di rete aumentano anche quando i POP perimetrali di entrambi i provider non si trovano in un'area metropolitana. I dettagli sono elencati nella seguente sezione dei prezzi di ciascuna soluzione.

Assicurati di scegliere in ogni cloud regioni adatte che possano ospitare i carichi di lavoro previsti. Visita la pagina Località per Google Cloud e pagine simili per altri CSP, ad esempio la tabella con le regioni AWS o i prodotti Azure per regione. Per assistenza generale sulla selezione di una o più località in Google Cloud, consulta Best practice per la scelta della regione per Compute Engine.

Trasferimento di dati in Cloud Storage e BigQuery

Per impostazione predefinita, solo i dati che risiedono in un ambiente VPC di Google Cloud passano un tunnel Cloud VPN o una connessione Cloud Interconnect.

Se vuoi trasferire i dati da e verso altri servizi Google, puoi utilizzare Private Service Connect e Accesso privato Google per gli host on-premise dall'altro ambiente dell'altro CSP.

Se vuoi trasferire l'archiviazione di oggetti, il database, il data warehouse o altri prodotti di un altro CSP, consulta la relativa documentazione per verificare se i dati possono passare attraverso il prodotto Interconnect o VPN gestita. In caso contrario, potresti essere in grado di passare questi dati tramite macchine virtuali proxy che hai configurato nel rispettivo ambiente CSP in modo che passino attraverso la connessione che preferisci.

Per trasferire i dati su Cloud Storage o BigQuery, puoi anche utilizzare Storage Transfer Service o BigQuery Transfer Service.

Trasferimento tramite indirizzi IP esterni su internet

Il modo più semplice per trasferire dati tra Google Cloud e un altro CSP è utilizzare internet e trasferire i dati utilizzando indirizzi IP esterni.

Il seguente diagramma illustra gli elementi di questa soluzione.

Architettura del trasferimento di dati tra Google Cloud e un altro CSP tramite indirizzo IP esterno su internet.

Tra il perimetro della rete di Google e quello dell'altro CSP, i dati passano attraverso internet o utilizzano un peering diretto tra Google Cloud e l'altro CSP. I dati possono essere trasferiti solo tra risorse a cui sono stati assegnati indirizzi IP pubblici.

In che modo Google si connette ad altre reti

I POP perimetrali di Google sono i punti in cui la rete Google si connette ad altre reti che collettivamente formano internet. Google è presente in numerose località di tutto il mondo.

Su internet, a ogni rete viene assegnato un ASN (Autonomous System Number) che comprende l'infrastruttura e le route di rete interne della rete. L'ASN principale di Google è 15169.

Una rete può inviare o ricevere traffico da o verso Google in due modi principali:

  • Acquista un servizio internet da un provider di servizi internet (ISP) che dispone già di connettività a Google (AS15169). Questa opzione viene generalmente chiamata IP Transit ed è simile a ciò che i consumatori e le aziende acquistano dai provider di accesso presso le loro case e le loro attività commerciali.
  • Connettersi direttamente a Google (AS15169). Questa opzione, denominata peering, consente a una rete di inviare e ricevere traffico direttamente verso Google (AS15169) senza utilizzare una rete di terze parti. Su larga scala, il peering è generalmente preferito rispetto al trasporto pubblico perché gli operatori di rete hanno un maggiore controllo su come e dove viene scambiato il traffico, consentendo l'ottimizzazione di prestazioni e costi. Il peering è un sistema volontario; quando scelgono il peering, gli operatori di rete decidono congiuntamente a quali strutture connettersi, quanta larghezza di banda eseguire il provisioning, come suddividere i costi di infrastruttura e qualsiasi altro dettaglio necessario per configurare le connessioni. AS15169 ha un criterio di peering aperto, il che significa che, se una rete soddisfa i requisiti tecnici, Google eseguirà il peering con loro.

Il peering è un accordo privato a vantaggio di due reti indipendenti e, come tale, le reti generalmente non comunicano pubblicamente con chi eseguono il peering in determinate località, quanta larghezza di banda è disponibile e così via. Tuttavia, a causa della scalabilità e di un criterio aperto, Google è in peering diretto con quasi tutti i principali ISP e fornitori di servizi cloud in più località e regioni. Il team della rete Google collabora direttamente con le controparti su queste reti per fornire una capacità di peering sufficiente a soddisfare la domanda.

Per ulteriori informazioni sul funzionamento del peering internet, consulta il playbook sul peering internet.

Implementazione

In questa configurazione, tutte le macchine virtuali che trasferiscono i dati tra Google Cloud e altri provider di servizi cloud devono avere un indirizzo IP pubblico. Da un lato, il firewall deve essere aperto per consentire la connessione dall'indirizzo IP pubblico dell'altro cloud provider. Non sono necessari ulteriori passaggi perché lo scambio di dati avviene sulla connessione a internet esistente.

Velocità e latenza di trasferimento

Sebbene non vi siano velocità e latenza garantite lungo il percorso attraverso internet, in genere i principali CSP e Google scambiano dati direttamente in più località in tutto il mondo. La capacità è condivisa con altri clienti e servizi, ma spesso a causa della connessione diretta tra entrambi i provider, la latenza è simile o inferiore rispetto alle altre opzioni.

Ti consigliamo di testare la latenza e la larghezza di banda tra Google Cloud e gli altri CSP nelle regioni che hai scelto. Puoi eseguire un rapido benchmark utilizzando strumenti come iperf o netperf oppure eseguire un benchmark personalizzato più completo in base alla tua app. Sebbene le condizioni possano cambiare nel tempo, il benchmark può fornire un'indicazione delle prestazioni che puoi aspettarti e se questa soluzione soddisfa le tue esigenze. Se hai bisogno di una larghezza di banda dedicata tra entrambi gli ambienti, devi scegliere un'altra soluzione.

Tieni presente che prodotti di fornitori diversi possono avere caratteristiche prestazionali che potrebbero non essere sempre in linea. Ad esempio, la capacità della VPN IPsec per-tunnel potrebbe variare in base al fornitore.

Sicurezza

Il traffico su internet non è criptato e potrebbe passare attraverso provider di servizi internet (ISP), sistemi autonomi e strutture di terze parti. Di conseguenza, devi criptare il traffico sensibile a livello di applicazione o scegliere un'altra soluzione.

Affidabilità e SLA

In genere Google Cloud dispone di più percorsi diversi per la connettività internet da regioni e esistono connessioni di peering diretto con altri CSP principali in più località in tutto il mondo.

Tuttavia, Google Cloud non fornisce SLA (accordi sul livello del servizio) per la connettività ad altri CSP su internet. Anche se dovresti controllare gli SLA (accordi sul livello del servizio) per gli altri fornitori di servizi per i creator, in genere si riferiscono solo alla connettività internet nel complesso e non a provider specifici.

I provider possono avere diversi criteri di routing che possono influire sulla disponibilità. Ad esempio, nella sua pagina peeringdb, Amazon spiega che molte regioni AWS annunciano solo route locali, poiché i VPC AWS sono solo a livello di regione (i VPC di Google Cloud sono globali). Ciò significa che i clienti potrebbero fare affidamento su link in una singola località di peering, poiché il traffico in uscita da Google Cloud può utilizzare quei link solo per raggiungere la destinazione. Questo va bene in un normale funzionamento, con traffico scambiato all'interno della regione, ma è consigliabile che i clienti progettino i deployment in più regioni per tollerare gli errori a livello di regione. Ciò potrebbe includere la configurazione di gateway aggiuntivi, VPN ad alta disponibilità, peering di rete virtuale o altre topologie multiregionali nel cloud di terze parti.

Inoltre, le applicazioni devono essere create in modo tale da non essere aperte, come consigliato da Google SRE nel libro su SRE. Ad esempio, se crei un'applicazione che si basa sulla possibilità di raggiungere un servizio di terze parti tramite il routing internet, assicurati che l'applicazione continui a funzionare o almeno restituisca messaggi di errore utili all'utente in caso di problemi di connettività.

Quando si verificano problemi con il routing a Internet, il team della rete Google tenterà di ripristinare la connettività con la terza parte. Tuttavia, non tutti i problemi saranno sotto il controllo di Google. Quindi, in alcuni casi, la riparazione potrebbe dipendere dall'intervento di una terza parte (ISP o cloud provider). I clienti hanno la maggiore influenza sul modo in cui gli operatori rispondono alle interruzioni, quindi assicurati di offrire una copertura di assistenza con tutti i fornitori e un piano per riassegnare i problemi in caso di problemi. Inoltre, esegui analisi BCP (Business Continuity Process) periodici per garantire la resilienza delle applicazioni progettate su multi-cloud.

Prezzi

Per i trasferimenti di dati su internet, si applicano le normali tariffe del traffico in uscita da Google Cloud. Nei casi in cui la latenza non è critica, l'utilizzo del livello di servizio di rete Standard prevede un livello di prezzo più basso.

Gli altri CSP hanno i propri costi per i trasferimenti di dati. In molti casi, addebitano solo il traffico in uscita dalla rete. Consulta il listino prezzi di CSP, ad esempio per AWS, consulta Costi per il trasferimento di dati EC2 e, per Azure, consulta i dettagli dei prezzi per la larghezza di banda.

VPN gestita tra provider cloud

Puoi utilizzare i servizi VPN gestiti di entrambi i cloud provider, con due vantaggi. Fornisce un canale criptato tra le reti virtuali in entrambi gli ambienti cloud e ti consente di trasferire i dati utilizzando indirizzi IP privati. Si tratta di un'estensione della soluzione precedente di trasferimento su internet senza richiedere hardware o partner.

Il seguente diagramma illustra gli elementi di questa soluzione.

Architettura del trasferimento di dati tra Google Cloud e un altro CSP utilizzando una VPN gestita;

Con questa soluzione, i dati vengono criptati su Google Cloud tramite Cloud VPN e una soluzione VPN per l'altro CSP. Il trasferimento di dati tra Google Cloud e l'altro CSP utilizza internet come nella soluzione precedente.

Implementazione

Google offre Cloud VPN come servizio VPN gestito per i tunnel IPsec criptati, che può essere utilizzato sul lato Google. Altri CSP offrono i propri prodotti VPN gestiti, che possono essere utilizzati per creare tunnel VPN IPsec tra entrambi gli ambienti. Ad esempio, AWS offre la VPN Site-to-Site AWS e Azure offre il gateway VPN di Azure. Puoi connettere le tue reti virtuali tra gli ambienti utilizzando i tunnel VPN.

Gli indirizzi IP nei due ambienti non devono sovrapporsi in quanto non è disponibile alcuna funzionalità NAT (Network Address Translation) in Cloud VPN. Sul router Cloud, le route sovrapposte potrebbero essere rimosse dallo scambio tra gli ambienti, ma non è possibile alcuna comunicazione tra i servizi che utilizzano questi indirizzi IP.

Con il router Cloud in modalità di routing dinamico globale, puoi raggiungere tutte le aree geografiche in una rete VPC globale utilizzando solo tunnel VPN verso quella regione. Per altri CSP, potrebbero essere necessari tunnel VPN per regione. Se in un ambiente cloud disponi di più reti virtuali non in peering, devi connettere tutte le reti virtuali che devono comunicare tra loro in modo indipendente utilizzando una VPN.

Google Cloud offre guide sull'interoperabilità con istruzioni dettagliate per la configurazione di tunnel VPN per altri principali cloud provider:

Velocità e latenza di trasferimento

Quando utilizzi tunnel VPN gestiti, i dati seguono comunque lo stesso percorso internet come se i dati venissero scambiati direttamente utilizzando indirizzi IP pubblici. La latenza osservata dovrebbe essere simile all'opzione precedente con un piccolo overhead di latenza per il tunnel VPN. La larghezza di banda disponibile è limitata dalla larghezza di banda massima per tunnel VPN su Google Cloud, dalla larghezza di banda massima degli altri tunnel CSP e dalla larghezza di banda disponibile sul percorso internet.

Per una larghezza di banda maggiore, puoi eseguire il deployment di più tunnel in parallelo. Per ulteriori informazioni su come eseguire il deployment di una soluzione di questo tipo, consulta Creazione di VPN ad alta velocità effettiva.

Puoi testare la latenza e la larghezza di banda come descritto nell'ultima sezione, ma le condizioni possono variare nel tempo e non vi sono garanzie riguardo alla latenza o alla larghezza di banda.

Sicurezza

Il traffico sui tunnel VPN IPsec viene criptato tramite crittografie accettate da entrambi i CSP. Per maggiori informazioni, consulta Le crittografie IKE supportate da Cloud VPN, le Domande frequenti sulla VPN AWS e i Parametri IPsec/IKE della VPN di Azure.

Affidabilità e SLA

Cloud VPN offre uno SLA (accordo sul livello del servizio) del 99,9%-99,99%, a seconda dell'opzione selezionata per VPN classica o VPN ad alta disponibilità. Altri CSP a volte offrono SLA per il loro prodotto VPN gestito, ad esempio SLA (accordo sul livello del servizio) della VPN Site-to-Site AWS e SLA di Azure per il gateway VPN. Tuttavia, questi SLA coprono solo la disponibilità dei gateway VPN e non includono la connettività ad altri CSP su internet, quindi non è previsto uno SLA nella soluzione end-to-end.

Per aumentare l'affidabilità, valuta la possibilità di utilizzare più gateway e tunnel VPN sia su Google Cloud che sugli altri CSP.

Prezzi

Per il servizio VPN gestito si applicano addebiti. Per Google Cloud viene applicato un addebito orario, consulta i prezzi di Cloud VPN. Per altri CSP, consulta i relativi elenchi dei prezzi, ad esempio consulta la pagina relativa ai prezzi della connessione VPN Site-to-Site AWS o ai prezzi del gateway VPN di Azure.

Oltre ai prezzi orari per il servizio VPN, devi pagare i dati trasferiti tramite i gateway VPN. Per Google Cloud e molti CSP, si applicano i costi standard per il trasferimento di dati internet, come descritto in Trasferimento tramite indirizzi IP esterni su internet. In molti casi, i costi per il trasferimento di dati superano il costo fisso di questa soluzione.

Partner Interconnect con partner abilitati per il multi-cloud

Partner Interconnect ti consente di connettere un virtual private cloud alle reti virtuali di un altro CSP tramite la rete di partner selezionati che offrono soluzioni multi-cloud dirette. Per connetterti, esegui il deployment di una o più istanze di routing virtuali che si occupano della configurazione necessaria del Border Gateway Protocol (BGP).

Il seguente diagramma mostra una configurazione ridondante utilizzando due connessioni Partner Interconnect.

Architettura del trasferimento di dati tra Google Cloud e un altro CSP utilizzando due Partner Interconnect.

Le route vengono scambiate tra il router Cloud e il gateway sul lato dell'altro CSP tramite un'istanza di routing virtuale gestita dal partner che fornisce l'interconnessione. Il traffico passa attraverso la rete del partner tra Google Cloud e l'altro CSP.

Implementazione

Questa soluzione richiede la configurazione di più componenti:

  • Sul lato Google Cloud, devi configurare Partner Interconnect con un provider di servizi di interconnessione che gestisce le tue regioni Google Cloud e offre connettività multi-cloud agli altri CSP.
  • Nell'altro CSP, devi utilizzare il prodotto Interconnect per la connessione allo stesso partner. Ad esempio, su AWS puoi utilizzare Direct Connect e su Azure puoi usare ExpressRoute.
  • Per quanto riguarda il fornitore di servizi partner, devi configurare l'apparecchiatura di routing virtuale che fornisce le sessioni BGP a Google Cloud e all'altro CSP.

Se lo spazio di indirizzi IP tra entrambi gli ambienti CSP si sovrappone, il tuo partner potrebbe offrire la funzionalità NAT per l'apparecchiatura di routing virtuale. Per ulteriori dettagli, consulta la documentazione dei partner.

Velocità e latenza di trasferimento

Questa soluzione offre capacità dedicata tra Google Cloud e altri CSP. A seconda del partner e dell'altro CSP, la capacità disponibile per i collegamenti può variare. Sul lato Google Cloud, Partner Interconnect è disponibile con una capacità di collegamento tra 50 Mbps e 50 Gbps.

La latenza per questa soluzione è la somma di quanto segue:

  • Latenza tra la regione in cui le risorse sono ospitate su Google Cloud e la località di interconnessione in cui il partner si connette a Google Cloud.
  • Latenza nella rete partner da, verso e attraverso l'istanza di routing virtuale verso l'altro CSP.
  • Latenza dalla località perimetrale dell'altro CSP, in cui avviene l'interconnessione con il partner, alla regione in cui le risorse sono ospitate nel CSP.

Per ottenere la latenza più bassa possibile, le località perimetrali di Google Cloud e dell'altro CSP devono trovarsi nella stessa area metropolitana, insieme all'istanza di routing virtuale. Ad esempio, potresti avere una connessione a bassa latenza se le regioni cloud di CSP, il POP perimetrale e l'istanza di routing virtuale si trovano nell'area di Ashburn, in Virginia.

Sebbene Google Cloud e molti altri CSP non offrano garanzie di latenza per il traffico verso il perimetro della rete, poiché sono presenti un percorso e una capacità dedicati attraverso il partner, in genere la latenza in questa soluzione è meno variabile rispetto all'uso di indirizzi IP esterni o di una soluzione VPN.

Sicurezza

Il traffico su Partner Interconnect non è criptato per impostazione predefinita. Per proteggere il traffico, puoi eseguire il deployment della VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP consentono di utilizzare il proprio servizio VPN gestito su un'interconnessione; ad esempio, la VPN AWS Site-to-Site può essere utilizzata su AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico sull'altro lato CSP.

Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.

Affidabilità e SLA

Questa soluzione prevede tre diversi SLA (accordi sul livello del servizio): uno di Google, uno del partner di interconnessione e uno dell'altro CSP.

Quando si utilizza Partner Interconnect in modo ridondante, Google offre SLA mensili del 99,9% -99,99% a seconda della topologia scelta. Non è previsto alcuno SLA (accordo sul livello del servizio) su una singola connessione Partner Interconnect.

Consulta la documentazione dell'altro CSP per lo SLA (accordo sul livello del servizio) sul relativo prodotto Interconnect, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.

Consulta la documentazione o i termini del fornitore di servizi partner per Partner Interconnect per il suo SLA (accordo sul livello del servizio) sulla disponibilità dell'istanza di connettività e routing virtuale. Ad esempio, consulta il Contratto per i servizi globali di Megaport.

Prezzi

Sul lato Google Cloud, è prevista una tariffa mensile per ogni collegamento Partner Interconnect, a seconda della larghezza di banda. Il traffico in uscita attraverso Partner Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per ulteriori informazioni, consulta la pagina dei prezzi di Partner Interconnect.

Consulta la pagina dei prezzi dell'altro CSP per il relativo prodotto Interconnect, ad esempio Prezzi di AWS Direct Connect o Prezzi di Azure ExpressRoute. In genere, i prezzi prevedono anche una tariffa mensile per le tariffe di interconnessione e trasferimento di dati tramite interconnessione a una tariffa inferiore rispetto a quella su internet.

Il partner fornisce tariffe per i servizi di interconnessione in base ai propri prezzi, che sono disponibili sul sito web o consultando il team di vendita per un preventivo. In genere, se tutti i trasferimenti di dati avvengono nella stessa area metropolitana, gli addebiti sono molto più bassi rispetto a quando i dati devono percorrere una distanza maggiore sulla rete di un partner.

Quando i dati vengono trasferiti regolarmente a volumi sufficientemente elevati, a seconda dei prezzi degli altri CSP, questa soluzione a volte può offrire il costo totale più basso grazie alle tariffe scontate per il traffico in uscita. Anche quando si aggiungono costi mensili per l'interconnessione per Partner Interconnect, per l'altro CSP e per il provider di servizi partner, l'utilizzo di questa soluzione può offrire risparmi significativi. Poiché i prezzi dei partner e di altri CSP possono cambiare senza preavviso, fai un confronto personale utilizzando preventivi aggiornati di tutte le parti coinvolte.

Dedicated Interconnect tramite un POP comune

Utilizzando uno o più dispositivi di routing fisici in una struttura di interconnessione comune tra Google Cloud e l'altro CSP, puoi connettere entrambi i cloud provider utilizzando Dedicated Interconnect sul lato Google Cloud e un prodotto equivalente nell'altro CSP. La località di interconnessione non si trova necessariamente nella stessa località in cui si trovano le risorse.

Il seguente diagramma mostra una configurazione ridondante utilizzando due connessioni Dedicated Interconnect:

Architettura del trasferimento dei dati tra Google Cloud e un altro CSP utilizzando due connessioni Dedicated Interconnect.

Le route vengono scambiate tra il router Cloud e il gateway dall'altro lato del CSP tramite un router fisico posizionato in una struttura di interconnessione comune. Il traffico passa attraverso questo router tra Google Cloud e l'altro CSP.

Implementazione

Questa soluzione richiede l'hosting e la gestione dei dispositivi di routing fisici in una struttura di colocation in cui sono presenti Google e il CSP a cui vuoi connetterti. Da questo dispositivo di routing, ordini due connessioni fisiche alla struttura: una verso Google Cloud utilizzando Dedicated Interconnect e l'altra verso l'altro fornitore di servizi utilizzando un prodotto equivalente, ad esempio AWS Direct Connect o Azure ExpressRoute. Sul dispositivo di routing, devi configurare il BGP per consentire gli scambi di route tra i due ambienti cloud.

Controlla l'elenco delle località delle strutture di colocation di Google Cloud e l'altro CSP, ad esempio Località di AWS Direct Connect o Località di peering di Azure ExpressRoute per identificare le località adatte per questa configurazione.

Gli intervalli di indirizzi IP tra le reti virtuali non dovrebbero sovrapporsi, a meno che il dispositivo di routing fisico non sia in grado di eseguire NAT tra gli ambienti o non limiti alcuni scambi di route tra gli ambienti.

Questa soluzione è efficace se utilizzi la connettività dedicata anche per connetterti di nuovo al tuo ambiente on-premise, oltre che a un altro CSP.

In altri casi, questa soluzione è complessa perché richiede la proprietà e la manutenzione di apparecchiature fisiche e un contratto con una struttura di colocation. Consigliamo questa soluzione solo se almeno una delle seguenti condizioni è vera:

  • Hai già l'attrezzatura in una struttura adatta per un altro scopo e hai già stipulato un contratto con la struttura.
  • Poiché trasferisci regolarmente grandi quantità di dati, questa è un'opzione conveniente o hai requisiti di larghezza di banda che i partner non possono soddisfare.

Velocità e latenza di trasferimento

Questa soluzione offre capacità dedicata tra Google Cloud e un altro CSP. Sul lato Google Cloud, Dedicated Interconnect è disponibile utilizzando una o più connessioni fisiche a 10 o 100 Gbps.

La latenza di questa soluzione è la somma di quanto segue:

  • Latenza tra la regione in cui le risorse sono ospitate su Google Cloud e la località di interconnessione in cui ti connetti con Google Cloud.
  • Latenza attraverso la struttura e l'apparecchiatura fisica, che è generalmente trascurabile se confrontata con qualsiasi latenza dovuta alla lunghezza della fibra.
  • Latenza dalla località di interconnessione attraverso la rete dell'altro CSP alla regione in cui le risorse sono ospitate nel CSP.

Sebbene non venga offerta alcuna garanzia di latenza, questa soluzione in genere consente la latenza più bassa e le massime velocità di trasferimento tra Google Cloud e altri ambienti cloud su indirizzi IP privati.

Sicurezza

Il traffico su Dedicated Interconnect non è criptato per impostazione predefinita. Per proteggere il traffico, puoi eseguire il deployment della VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP consentono di utilizzare il proprio servizio VPN gestito su un'interconnessione; ad esempio, la VPN AWS Site-to-Site può essere utilizzata su AWS Direct Interconnect. In alternativa, puoi utilizzare un'appliance virtuale che cripta il traffico sull'altro lato CSP.

Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.

Affidabilità e SLA

Quando si utilizza Dedicated Interconnect in modo ridondante, Google offre SLA mensili del 99,9%-99,99% a seconda della topologia scelta. Non è previsto uno SLA (accordo sul livello del servizio) su una singola connessione Dedicated Interconnect.

Per ulteriori informazioni, consulta la documentazione dell'altro CSP relativa allo SLA (accordo sul livello del servizio) sul relativo prodotto di interconnessione, ad esempio SLA di AWS Direct Connect o SLA di Azure per ExpressRoute.

La struttura di colocation o il fornitore di hardware per l'attrezzatura di routing fisico potrebbe anche offrire SLA per i loro servizi.

Prezzi

Sul lato di Google Cloud è prevista una tariffa mensile per ogni porta Dedicated Interconnect e per ogni collegamento VLAN connesso a un ambiente VPC. Il traffico in uscita attraverso Dedicated Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per ulteriori informazioni, consulta la pagina dei prezzi di Dedicated Interconnect.

Consulta la pagina dei prezzi dell'altro CSP per il relativo prodotto Interconnect, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi prevedono anche una tariffa mensile per le tariffe di interconnessione e trasferimento di dati tramite interconnessione a una tariffa inferiore rispetto a quella su internet.

Inoltre, devi tenere conto degli addebiti per i servizi delle strutture di colocation che forniscono spazio, energia elettrica e connessioni fisiche per entrambi gli ambienti cloud, nonché eventuali costi e contratti di servizio in corso con il fornitore per l'apparecchiatura di routing fisico. Se la connessione tra i due CSP non può avvenire nella stessa struttura e devi ottenere connettività tra le strutture, i prezzi di questi servizi potrebbero essere molto più alti.

Connessioni gestite Cross-Cloud Interconnect

Puoi connettere le reti VPC Google Cloud alle reti virtuali in un altro CSP sull'infrastruttura di rete di Google. In un certo senso, questa configurazione funziona come Partner Interconnect, ma lo SLA (accordo sul livello del servizio) di Google copre sia le reti Google sia le interconnessioni stesse.

Il seguente diagramma mostra una configurazione di Cross-Cloud Interconnect con il numero minimo di connessioni.

Architettura di una configurazione minima di Cross-Cloud Interconnect.

Le route vengono scambiate tra il router Cloud e il gateway dall'altro lato del CSP sull'infrastruttura di rete di Google. Il traffico passa attraverso questa struttura tra Google Cloud e l'altro CSP.

Implementazione

Quando acquisti Cross-Cloud Interconnect, Google fornisce una connessione fisica dedicata tra la rete Google e quella di un altro provider di servizi cloud. Puoi utilizzare questa connessione per eseguire il peering della tua rete Virtual Private Cloud (VPC) di Google Cloud con una rete ospitata da un provider di servizi cloud supportato.

Dopo aver eseguito il provisioning della connessione, Google supporta la connessione fino al punto in cui raggiunge la rete dell'altro fornitore di servizi cloud. Google non garantisce l'uptime dell'altro fornitore di servizi cloud. Tuttavia, Google rimane il punto di contatto principale per il servizio completo e ti avviserà nel caso in cui fosse necessario aprire una richiesta di assistenza con l'altro CSP.

Questa soluzione richiede di seguire la procedura di configurazione per l'altro CSP, inclusa la scelta del percorso di interconnessione delle due reti. Solo alcuni CSP sono supportati.

Velocità e latenza di trasferimento

Questa soluzione offre capacità dedicata tra Google Cloud e un altro CSP. Sul lato Google Cloud, Dedicated Interconnect è disponibile utilizzando una o più coppie di connessioni fisiche a 10 Gbps o 100 Gbps.

La latenza di questa soluzione è la somma di quanto segue:

  • Latenza tra la regione in cui le risorse sono ospitate su Google Cloud e la località cross-cloud.
  • Latenza tra la località perimetrale di Google e l'altra località perimetrale di CSP (spesso nella stessa struttura)
  • Latenza dall'altra località perimetrale di CSP in cui viene eseguito il deployment di Cross-Cloud Interconnect nella regione in cui sono ospitate le risorse in CSP.

Sebbene non vengano offerte garanzie di latenza, questa soluzione in genere consente la latenza minima e le massime velocità di trasferimento tra Google Cloud e altri ambienti cloud su indirizzi IP privati.

Sicurezza

Poiché il traffico su Cross-Cloud Interconnect non è criptato, ti consigliamo di utilizzare la crittografia a livello di applicazione per il traffico sensibile.

Se tutto il traffico deve essere criptato, le appliance virtuali disponibili nei partner Google Cloud in Cloud Marketplace possono fornire soluzioni per criptare il traffico nell'ambiente degli altri CSP.

Affidabilità e SLA

Cross-Cloud Interconnect utilizza lo SLA di Cloud Interconnect. Per l'idoneità allo SLA (accordo sul livello del servizio), la configurazione di Cross-Cloud Interconnect deve utilizzare una o più coppie di connessioni, come descritto nella sezione Accordo sul livello di servizio della panoramica di Cross-Cloud Interconnect.

Lo SLA copre tutto il lato Google fino al perimetro della rete dell'altro cloud provider. Non copre la rete dell'altro CSP. Per ulteriori informazioni, consulta la documentazione dell'altro CSP relativa allo SLA (accordo sul livello del servizio) sul relativo prodotto di interconnessione; ad esempio, SLA di AWS Direct Connect o SLA di Azure per ExpressRoute.

Prezzi

È prevista una tariffa oraria per ogni connessione Cross-Cloud Interconnect e per ogni collegamento VLAN connesso a un ambiente VPC. Il traffico in uscita attraverso Cross-Cloud Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per maggiori informazioni, consulta Prezzi di Cross-Cloud Interconnect.

Consulta la pagina dei prezzi dell'altro CSP per il relativo prodotto Interconnect, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere viene addebitato un costo mensile per l'interconnessione. I costi per il trasferimento di dati attraverso l'interconnessione sono generalmente inferiori a quelli per il trasferimento di dati su internet.

Non sono previsti costi separati per le località o le apparecchiature di interconnessione.

Confronto tra le opzioni

Le opzioni presentate variano in termini di velocità, disponibilità, complessità, sicurezza e prezzi. Dovresti valutare attentamente tutte le opzioni in base alle tue esigenze.

Il seguente diagramma ti guida nella scelta di una delle soluzioni menzionate in questo documento tramite un semplice diagramma di flusso.

Diagramma di flusso decisionale che ti aiuta a determinare la soluzione di interconnessione da scegliere.

In genere, possiamo consigliare le seguenti opzioni:

  • Per molti scenari in cui i dati vengono scambiati occasionalmente o a basso volume e i trasferimenti non sono fondamentali, il trasferimento dei dati su internet è l'opzione più semplice e offre comunque una latenza relativamente bassa e una larghezza di banda elevata.
  • Se è necessaria la crittografia o il trasferimento di quantità minori di dati tramite indirizzi IP privati, valuta la possibilità di utilizzare Cloud VPN e un servizio VPN gestito sull'altro lato CSP.
  • Se trasferisci grandi quantità di dati, l'utilizzo di Partner Interconnect con un partner multi-cloud abilitato offre diversi vantaggi: capacità dedicata, costi inferiori per il trasferimento dei dati e, a seconda della topologia, uno SLA per ogni parte della soluzione. La capacità di Partner Interconnect è normalmente inferiore a 10 Gbps per connessione.
  • Se connetti l'apparecchiatura on-premise a più cloud, l'opzione di Dedicated Interconnect tramite un POP comune è comune. Inoltre, aumenta la complessità della gestione dell'hardware e delle relazioni con una struttura di colocation. A meno che tu non abbia già implementato l'infrastruttura, questa soluzione è riservata ai casi in cui le normali velocità di trasferimento dei dati sono pari o superiori a 10 Gbps.
  • Se non vuoi il sovraccarico per la gestione delle connessioni incrociate e del routing delle apparecchiature nei POP remoti, Cross-Cloud Interconnect offre una soluzione gestita in cui Google si occupa di tutto questo per te.

Passaggi successivi