Questo documento aiuta gli architetti cloud e i professionisti delle operazioni a decidere come connettersi Google Cloud ad altri fornitori di servizi cloud (CSP) come Amazon Web Services (AWS) e Microsoft Azure. In una progettazione multicloud, le connessioni tra i CSP consentono i trasferimenti di dati tra le tue reti virtuali. Questo documento fornisce anche informazioni su come implementare l'opzione che scegli.
Molte organizzazioni operano su più piattaforme cloud, temporaneamente durante una migrazione o perché l'organizzazione ha una strategia multi-cloud a lungo termine.
Per lo scambio di dati tra Google Cloud e altri CSP, esistono diverse opzioni descritte in questo documento:
- Trasferimento di dati tramite indirizzi IP pubblici su internet.
- Utilizzo di un servizio VPN gestito tra Google Cloud e l'altro CSP.
- Utilizzando Partner Interconnect su Google Cloud per connettersi a un partner che può connettersi direttamente all'altro CSP.
- Utilizzo di Dedicated Interconnect su Google Cloud per trasferire dati all'altro CSP tramite un punto di presenza (PoP) comune.
- Utilizzo di Cross-Cloud Interconnect su Google Cloud per una connessione gestita a un altro CSP.
Queste opzioni differiscono in termini di velocità di trasferimento, latenza, affidabilità, contratti di livello di servizio (SLA), complessità e costi. Questo documento descrive in dettaglio ogni opzione, i relativi vantaggi e svantaggi e si conclude con un confronto di tutte le opzioni.
Questo documento tratta i trasferimenti di dati tra macchine virtuali che si trovano in Google Cloud e altre reti virtuali di CSP. Per i dati archiviati in altri prodottiGoogle Cloud come Cloud Storage e BigQuery, consulta la sezione relativa a questi prodotti.
Questo documento può fungere da guida per valutare le opzioni di trasferimento dei dati tra Google Cloud e uno o più altri CSP, in base ai tuoi requisiti e alle tue capacità.
I concetti descritti in questo documento si applicano in 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 tuoi carichi di lavoro di calcolo vengono eseguiti su un altro CSP mentre i tuoi carichi di lavoro di big data utilizzano Google Cloud.
Considerazioni iniziali
Prima di scegliere come connettere gli ambienti cloud, è importante esaminare le regioni che scegli in ogni ambiente e avere una strategia per il trasferimento dei dati che non si trovano in ambienti di rete virtuale.
Scegliere le regioni cloud
Se sia Google Cloud che le risorse di altri CSP si trovano in regioni geograficamente vicine tra loro, esiste un vantaggio in termini di costi e latenza per i trasferimenti di dati tra i provider di servizi cloud.
Il seguente diagramma illustra il flusso di dati tra Google Cloud
e altri CSP.
Indipendentemente dal metodo di trasferimento, i dati fluiscono da Google Cloud all'altro CSP come segue:
- Dalla Google Cloud regione in cui sono ospitate le risorse al 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 fluiscono dall'altro CSP a Google Cloud percorrono lo stesso percorso, ma in direzione opposta.
Il percorso end-to-end determina la latenza del trasferimento dei dati. Per alcune soluzioni, i costi di rete aumentano anche quando i PoP perimetrali di entrambi i provider non si trovano in un'unica area metropolitana. I dettagli sono elencati nella sezione seguente di ciascuna soluzione.
Assicurati di scegliere regioni adatte in ogni cloud che possano ospitare i workload previsti. Visita la pagina Località per Google Cloud e pagine simili per altri CSP, ad esempio la tabella delle regioni AWS o Prodotti Azure per regione. Per assistenza generale nella selezione di una o più località in Google Cloud, consulta Best practice per la scelta della regione di Compute Engine.
Trasferimento dei dati in Cloud Storage e BigQuery
Per impostazione predefinita, solo i dati che si trovano all'interno di un ambiente VPC passano attraverso un tunnel Cloud VPN o una connessione Cloud Interconnect. Google Cloud
Se vuoi trasferire dati da e verso altri servizi Google, puoi utilizzare Private Service Connect e Private Google Access per host on-premise dall'ambiente dell'altro CSP.
Se vuoi trasferire l'object storage, 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 di interconnessione o VPN gestita. In caso contrario, potresti essere in grado di trasmettere questi dati tramite macchine virtuali proxy che hai configurato nell'ambiente del rispettivo CSP per farli passare attraverso la connessione che preferisci.
Per trasferire i dati a Cloud Storage o BigQuery, puoi utilizzare anche Storage Transfer Service o BigQuery Transfer Service.
Trasferimento tramite indirizzi IP esterni su internet
Il modo più semplice per trasferire i 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.
Tra l'edge di rete di Google e l'edge di rete 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 assegnati indirizzi IP pubblici.
Come 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 insieme formano internet. Google è presente in numerose località in tutto il mondo.
Su internet, a ogni rete viene assegnato un numero di sistema autonomo (ASN) che comprende l'infrastruttura e le route di rete interna della rete. L'ASN principale di Google è 15169.
Esistono due modi principali in cui una rete può inviare o ricevere traffico da o verso Google:
- Acquista un servizio internet da un provider di servizi internet (ISP) che dispone già della connettività a Google (AS15169). Questa opzione è generalmente denominata transito IP ed è simile a ciò che consumatori e aziende acquistano da provider di accesso per le proprie case e attività.
- Connettiti direttamente a Google (AS15169). Questa opzione, chiamata peering, consente a una rete di inviare e ricevere direttamente traffico a Google (AS15169) senza utilizzare una rete di terze parti. Su larga scala, il peering è generalmente preferito al transito 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 di eseguire il peering, gli operatori di rete decidono congiuntamente quali strutture connettere, quanta larghezza di banda fornire, come dividere i costi dell'infrastruttura e qualsiasi altro dettaglio necessario per configurare le connessioni. AS15169 ha una policy di peering aperta, il che significa che, se una rete soddisfa i requisiti tecnici, Google stabilirà un peering con la rete.
Il peering è un accordo privato e reciprocamente vantaggioso tra due reti indipendenti e, in quanto tale, le reti in genere non rivelano pubblicamente con chi effettuano il peering in determinate località, quanta larghezza di banda è disponibile e così via. Tuttavia, grazie alle dimensioni e a una policy aperta, Google è in peering diretto con quasi tutti i principali ISP e fornitori di servizi cloud in più località e regioni. Il team di rete di Google collabora direttamente con i colleghi di queste reti per fornire una capacità di peering sufficiente a soddisfare la domanda.
Per saperne di più su come funziona il peering di internet, consulta The Internet Peering Playbook.
Implementazione
In questa configurazione, tutte le macchine virtuali che trasferiscono dati traGoogle Cloud e altri fornitori di servizi cloud devono avere un indirizzo IP pubblico. Da un lato, il firewall deve essere aperto per consentire una connessione dall'indirizzo IP pubblico dell'altro provider cloud. Non sono necessari passaggi aggiuntivi perché lo scambio di dati avviene tramite la connettività a internet esistente.
Velocità di trasferimento e latenza
Sebbene non vi siano garanzie di velocità e latenza sul 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 ad altre opzioni.
Ti consigliamo di testare la latenza e la larghezza di banda tra Google Cloud e gli altri CSP nelle regioni scelte. Puoi eseguire un benchmark rapido utilizzando strumenti come iperf o netperf oppure eseguire un benchmark personalizzato più completo in base alla tua app. Anche se le condizioni potrebbero 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 i due ambienti, devi scegliere un'altra soluzione.
Tieni presente che i prodotti di fornitori diversi potrebbero avere caratteristiche di rendimento che potrebbero non essere sempre allineate. Ad esempio, la capacità VPN IPsec per tunnel può variare da fornitore a fornitore.
Sicurezza
Il traffico su internet non è criptato e potrebbe passare attraverso provider di servizi internet (ISP), sistemi autonomi e strutture di terze parti. Pertanto, devi criptare il traffico sensibile a livello di applicazione o scegliere un'altra soluzione.
Affidabilità e SLA
Google Cloud generalmente dispone di più percorsi diversi per la connettività a internet dalle regioni e sono presenti connessioni di peering diretto con altri CSP principali in più località in tutto il mondo.
Tuttavia, Google Cloud non fornisce SLA per la connettività ad altri CSP su internet. Sebbene tu debba controllare gli SLA per gli altri CSP, in genere si riferiscono solo alla connettività a internet nel suo complesso e non a provider specifici.
I provider potrebbero avere norme di routing diverse che possono influire sulla disponibilità. Ad esempio, nella pagina peeringdb, Amazon spiega che molte regioni AWS annunciano solo route locali, perché i VPC AWS sono solo regionali (i VPCGoogle Cloud sono globali). Ciò significa che i clienti potrebbero fare affidamento sui link in una singola posizione di peering, poiché il traffico in uscita da Google Cloud può utilizzare solo questi link per raggiungere la destinazione. Questo va bene durante il normale funzionamento <0A>con il traffico scambiato nella regione, ma è consigliabile che i clienti <0A>progettino deployment multiregionali per tollerare gli errori regionali. Ciò potrebbe includere la configurazione di gateway e tunnel aggiuntivi, peering di reti virtuali o altre topologie multiregionali nel cloud di terze parti.
Le applicazioni devono anche essere create in modo da "fallire in modo aperto", 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 utilizzando il routing internet, assicurati che l'applicazione funzioni ancora o che almeno restituisca messaggi di errore utili all'utente in caso di problemi di connettività.
Quando si verificano problemi di routing di internet, il team di rete di Google tenta di ripristinare la connettività con la terza parte. Tuttavia, non tutti i problemi saranno sotto il controllo di Google. Pertanto, in alcuni casi, la riparazione potrebbe dipendere dall'intervento di una terza parte (ISP o provider cloud). I clienti hanno la maggiore influenza sul modo in cui gli operatori rispondono alle interruzioni, quindi assicurati di avere una copertura di assistenza con tutti i provider e un piano per riassegnare i problemi in caso di imprevisti. Esegui anche test periodici del processo di continuità aziendale per garantire la resilienza delle applicazioni progettate su più cloud.
Prezzi
Per i trasferimenti di dati su internet, si applicano le normali tariffe per il traffico in uscita da internet per il traffico in uscita da Google Cloud. Nei casi in cui la latenza non è critica, l'utilizzo del livello di servizio di rete Standard offre un livello di prezzo inferiore.
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 del tuo CSP. Ad esempio, per AWS, consulta Addebiti per il trasferimento di dati EC2 e per Azure, consulta Dettagli sui prezzi della larghezza di banda.
VPN gestita tra provider cloud
Puoi utilizzare i servizi VPN gestiti di entrambi i provider cloud, il che offre due vantaggi. Fornisce un canale criptato tra le reti virtuali in entrambi gli ambienti cloud e 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.
Utilizzando questa soluzione, i dati vengono criptati su Google Cloud utilizzando Cloud VPN e una soluzione VPN per l'altro CSP. Il trasferimento dei dati tra Google Cloud e l'altro CSP utilizza internet come nella soluzione precedente.
Implementazione
Google offre la VPN ad alta disponibilità come servizio VPN gestito per tunnel IPsec criptati, che possono essere utilizzati all'estremità Google. Altri CSP offrono i propri prodotti VPN gestiti, che puoi utilizzare per creare tunnel VPN IPsec tra entrambi gli ambienti. Ad esempio, AWS offre AWS Site-to-Site VPN e Azure offre Azure VPN Gateway. Puoi connettere le tue reti virtuali tra gli ambienti utilizzando i tunnel VPN.
Puoi connetterti a un altro CSP utilizzando la VPN ad alta disponibilità da sola oppure puoi configurarla come spoke ibrido di Network Connectivity Center. Network Connectivity Center ti consente di connettere località on-premise, reti VPC e altri cloud utilizzando la gestione centralizzata.
La VPN ad alta disponibilità non dispone di funzionalità Network Address Translation (NAT) integrate. Tuttavia, puoi abilitare NAT ibrido sulla connessione.
Con Cloud Router in modalità di routing dinamico globale, puoi raggiungere tutte le regioni in una rete VPC globale utilizzando solo tunnel VPN per quella regione. Per altri CSP, potresti aver bisogno di tunnel VPN per regione. Se hai più reti virtuali in un ambiente cloud che non sono in peering, devi connettere tutte le reti virtuali che devono comunicare tra loro in modo indipendente utilizzando una VPN.
Google Cloud offre guide all'interoperabilità, che contengono istruzioni passo passo per configurare tunnel VPN ad altri importanti provider cloud:
Velocità di trasferimento e latenza
Quando utilizzi tunnel VPN gestiti, i dati seguono più o meno gli stessi percorsi internet che seguirebbero senza i tunnel VPN. La latenza osservata dovrebbe essere simile all'opzione precedente, con solo un piccolo overhead di latenza per i 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 tunnel aggiuntivi. Per ulteriori informazioni su come implementare una soluzione di questo tipo, consulta Topologie VPN ad alta disponibilità per aumentare la larghezza di banda.
Puoi testare la latenza e la larghezza di banda come descritto nell'ultima sezione, ma le condizioni potrebbero variare nel tempo e non ci sono garanzie in merito a latenza o larghezza di banda.
Sicurezza
Il traffico sui tunnel VPN IPsec viene criptato utilizzando cifrari accettati da entrambi i CSP. Per ulteriori informazioni, consulta Cifrari IKE supportati da Cloud VPN, Domande frequenti su AWS VPN e Parametri IPsec/IKE di Azure VPN.
Affidabilità e SLA
Cloud VPN offre un SLA. Altri CSP a volte offrono SLA per il loro prodotto VPN gestito, ad esempio SLA 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, pertanto non esiste uno SLA per la soluzione end-to-end.
Per aumentare l'affidabilità, valuta la possibilità di utilizzare gateway e tunnel VPN aggiuntivi su Google Cloud e sugli altri CSP.
Prezzi
Per il servizio VPN gestito, si applicano addebiti. Per Google Cloud, si applica una tariffa oraria. Consulta la pagina Prezzi di Cloud VPN. Per altri CSP, consulta i relativi listini prezzi, ad esempio Prezzi della connessione VPN Site-to-Site di AWS o Prezzi di Azure VPN Gateway.
Oltre ai prezzi orari per il servizio VPN, devi pagare per i dati trasferiti tramite i gateway VPN. Per Google Cloud e molti CSP, si applicano i costi standard di trasferimento dei dati su internet, come descritto in Trasferimento tramite indirizzi IP esterni su internet. In molti casi, i costi di trasferimento dei dati superano il costo fisso di questa soluzione.
Partner Interconnect con partner abilitati al multicloud
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 multicloud dirette. La connessione avviene tramite 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 che utilizza due connessioni Partner Interconnect.
Le route vengono scambiate tra Cloud Router e il gateway sul lato dell'altro CSP tramite un'istanza di routing virtuale gestita dal partner che fornisce l'interconnessione. Il traffico scorre 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 , configuri Partner Interconnect con un provider di servizi di interconnessione che serve le tue regioni Google Cloud e offre connettività multicloud all'altro CSP.
- Nell'altro CSP, devi utilizzare il prodotto di interconnessione per connetterti allo stesso partner. Ad esempio, su AWS puoi utilizzare Direct Connect e su Azure puoi utilizzare ExpressRoute.
- Dal lato del partner fornitore di servizi, devi configurare l'apparecchiatura di routing virtuale che fornisce le sessioni BGP a Google Cloud e all'altro CSP.
Puoi connetterti utilizzando Partner Interconnect da solo oppure puoi configurare Partner Interconnect come spoke ibrido di Network Connectivity Center. Network Connectivity Center ti consente di connettere località on-premise, reti VPC e altri cloud utilizzando la gestione centralizzata.
Se lo spazio degli indirizzi IP tra entrambi gli ambienti CSP si sovrappone, puoi abilitare Hybrid NAT sulla connessione.
Velocità di trasferimento e latenza
Questa soluzione offre una capacità dedicata tra Google Cloud e altri CSP. A seconda del partner e dell'altro CSP, la capacità degli allegati disponibili potrebbe variare. D'altra parte, Partner Interconnect è disponibile con una capacità di collegamento compresa tra 50 Mbps e 50 Gbps. Google Cloud
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 posizione di interconnessione in cui il partner si connette a Google Cloud.
- Latenza nella rete dei partner da, verso e attraverso l'istanza di routing virtuale verso l'altro CSP.
- Latenza dalla posizione perimetrale dell'altro CSP in cui avviene l'interconnessione con il partner alla regione in cui le risorse sono ospitate nel CSP.
Per 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 sia le regioni cloud del CSP sia il PoP edge e l'istanza di routing virtuale si trovano nell'area di Ashburn, Virginia.
Sebbene Google Cloud e molti altri CSP non offrano garanzie di latenza per il traffico verso il perimetro della loro rete, poiché esiste un percorso e una capacità dedicati tramite il partner, in genere la latenza in questa soluzione è meno variabile rispetto a quando utilizzi indirizzi IP esterni o una soluzione VPN.
Sicurezza
Il traffico su Partner Interconnect non è criptato per impostazione predefinita. Per proteggere il traffico, puoi eseguire il deployment di VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP ti consentono di utilizzare il loro servizio VPN gestito tramite un'interconnessione; ad esempio, AWS Site-to-Site VPN può essere utilizzata tramite AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico sul lato dell'altro CSP.
Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.
Affidabilità e SLA
Questa soluzione prevede tre SLA diversi: uno di Google, uno del partner di interconnessione e uno dell'altro CSP.
Quando utilizzi Partner Interconnect in modo ridondante, Google offre SLA mensili del 99,9% - 99,99% a seconda della topologia scelta. Non esiste alcun SLA per una singola connessione Partner Interconnect.
Consulta la documentazione dell'altro CSP per il contratto di servizio relativo al prodotto di interconnessione, ad esempio SLA di AWS Direct Connect o su Azure SLA per ExpressRoute.
Consulta la documentazione o i termini del fornitore di servizi partner per Partner Interconnect per il relativo SLA sulla disponibilità della connettività e dell'istanza di routing virtuale. Ad esempio, consulta l'Accordo sui 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 tramite 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 suo prodotto di interconnessione, ad esempio Prezzi di AWS Direct Connect o Prezzi di Azure ExpressRoute. In genere, i prezzi prevedono anche un addebito mensile per l'interconnessione e addebiti per il trasferimento di dati tramite l'interconnessione a una tariffa inferiore rispetto a quella su internet.
Il partner fornisce i servizi di interconnessione in base ai propri prezzi, che possono essere trovati sul suo sito web o consultando il suo team di vendita per un preventivo. In genere, se tutti i trasferimenti di dati avvengono nella stessa area metropolitana, i costi sono molto inferiori rispetto a quelli che si applicano se i dati devono percorrere una distanza maggiore su una rete partner.
Quando i dati vengono trasferiti regolarmente a volumi sufficientemente elevati, a seconda dei prezzi dell'altro CSP, questa soluzione può talvolta offrire il costo totale più basso grazie alle tariffe di uscita scontate. Anche aggiungendo i costi mensili per l'interconnessione per Partner Interconnect, l'altro CSP e il partner fornitore di servizi, l'utilizzo di questa soluzione può comportare un risparmio significativo. Poiché i prezzi dei partner e di altri CSP possono variare senza preavviso, esegui un confronto 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à della regione in cui si trovano le risorse.
Il seguente diagramma mostra una configurazione ridondante che utilizza due connessioni Dedicated Interconnect:
Le route vengono scambiate tra Cloud Router e il gateway sul lato dell'altro CSP tramite un router fisico che posizioni in una struttura di interconnessione comune. Il traffico passa attraverso questo router tra Google Cloud e l'altro CSP.
Implementazione
Questa soluzione richiede di ospitare e gestire 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 con la struttura: una verso Google Cloud utilizzando Dedicated Interconnect e una verso l'altro service provider utilizzando un prodotto equivalente, ad esempio AWS Direct Connect o Azure ExpressRoute. Sul dispositivo di routing, devi configurare BGP per consentire gli scambi di route tra i due ambienti cloud.
Controlla l'elenco delle sedi delle strutture di colocation di Google Cloud e del tuo altro CSP, ad esempio Sedi di AWS Direct Connect o Sedi di peering di Azure ExpressRoute, per identificare le sedi adatte a questa configurazione.
Puoi connetterti utilizzando Dedicated Interconnect da solo oppure puoi configurare Dedicated Interconnect come spoke ibrido di Network Connectivity Center. Network Connectivity Center ti consente di connettere località on-premise, reti VPC e altri cloud utilizzando la gestione centralizzata.
Se lo spazio degli indirizzi IP tra entrambi gli ambienti CSP si sovrappone, puoi abilitare Hybrid NAT sulla connessione.
Questa soluzione è efficace se utilizzi la connettività dedicata anche per connetterti al tuo ambiente on-premise, oltre alla connessione a un altro CSP.
In altri casi, questa soluzione è complessa perché richiede di possedere e gestire apparecchiature fisiche e di avere un contratto con una struttura di colocation. Consigliamo questa soluzione solo se almeno una delle seguenti condizioni è vera:
- Hai già attrezzature in una struttura adatta per un altro scopo e un contratto esistente con la struttura.
- Trasferisci regolarmente grandi quantità di dati, quindi questa è un'opzione conveniente o hai requisiti di larghezza di banda che i partner non possono soddisfare.
Velocità di trasferimento e latenza
Questa soluzione offre una capacità dedicata tra Google Cloud e un altro CSP. Sul lato Google Cloud , Dedicated Interconnect è disponibile utilizzando una o più connessioni fisiche da 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 posizione di interconnessione in cui ti connetti con Google Cloud.
- Latenza attraverso la struttura e le apparecchiature fisiche, che è di solito trascurabile rispetto a qualsiasi latenza dovuta alla lunghezza della fibra.
- Latenza dalla posizione di interconnessione attraverso la rete dell'altro CSP alla regione in cui le risorse sono ospitate nel CSP.
Sebbene non vengano offerte garanzie di latenza, questa soluzione in genere consente la latenza più bassa e le velocità di trasferimento più elevate tra Google Cloud e altri ambienti cloud tramite indirizzi IP privati.
Sicurezza
Il traffico su Dedicated Interconnect non è criptato per impostazione predefinita. Per proteggere il traffico, puoi eseguire il deployment di VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP ti consentono di utilizzare il loro servizio VPN gestito tramite un'interconnessione; ad esempio, AWS Site-to-Site VPN può essere utilizzata tramite AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico sul lato dell'altro CSP.
Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.
Affidabilità e SLA
Quando utilizzi Dedicated Interconnect in modo ridondante, Google offre SLA mensili del 99,9%-99,99% a seconda della topologia scelta. Non esiste un SLA per una singola connessione Dedicated Interconnect.
Per ulteriori informazioni, consulta la documentazione dell'altro CSP per lo SLA sul suo prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.
Il fornitore di hardware o della struttura di colocation per le apparecchiature di routing fisiche potrebbe anche offrire SLA sui propri servizi.
Prezzi
Sul lato Google Cloud , è previsto un costo mensile per ogni porta Dedicated Interconnect e per ogni collegamento VLAN che si connette a un ambiente VPC. Il traffico in uscita tramite 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 suo prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi prevedono anche un addebito mensile per l'interconnessione e addebiti per il trasferimento di dati tramite l'interconnessione a una tariffa inferiore rispetto a quella su internet.
Inoltre, devi tenere conto degli addebiti per i servizi della struttura di colocation che forniscono spazio, alimentazione elettrica e connessioni fisiche a entrambi gli ambienti cloud, nonché di eventuali costi e contratti di servizio in corso con il fornitore per le apparecchiature di routing fisiche. Se la connessione tra entrambi i CSP non può avvenire nella stessa struttura e devi procurarti la connettività tra le strutture, i prezzi potrebbero essere molto più elevati per questi servizi.
Connessioni gestite Cross-Cloud Interconnect
Puoi connettere le tue reti VPC alle tue reti virtuali in un altro CSP tramite il fabric di rete di Google. Google Cloud In un certo senso, questa configurazione funziona come Partner Interconnect, ma con lo SLA di Google che 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.
Le route vengono scambiate tra Cloud Router e il gateway dall'altro lato del CSP tramite il fabric di rete di Google. Il traffico scorre attraverso questo fabric tra Google Cloud e l'altro CSP.
Implementazione
Quando acquisti Cross-Cloud Interconnect, Google esegue il provisioning di 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) con una rete ospitata da un provider di servizi cloud supportato. Google Cloud
Dopo il provisioning della connessione, Google supporta la connessione fino al punto in cui raggiunge la rete dell'altro provider di servizi cloud. Google non garantisce l'uptime da parte dell'altro provider di servizi cloud. Tuttavia, Google rimane il punto di contatto principale per l'intero servizio e ti invierà una notifica se devi 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 di dove le due reti si interconnetteranno. Sono supportati solo determinati CSP.
Puoi connetterti utilizzando Cross-Cloud Interconnect da solo oppure puoi configurare Cross-Cloud Interconnect come spoke ibrido di Network Connectivity Center. Network Connectivity Center ti consente di connettere località on-premise, reti VPC e altri cloud utilizzando la gestione centralizzata.
Se lo spazio degli indirizzi IP tra entrambi gli ambienti CSP si sovrappone, puoi abilitare Hybrid NAT sulla connessione.
Velocità di trasferimento e latenza
Questa soluzione offre una capacità dedicata tra Google Cloud e un altro CSP. Sul lato Google Cloud , Dedicated Interconnect è disponibile utilizzando una o più coppie di connessioni fisiche da 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 la località perimetrale dell'altro CSP (spesso nella stessa struttura)
- Latenza dalla posizione perimetrale dell'altro CSP in cui è distribuito Cross-Cloud Interconnect alla regione in cui sono ospitate le risorse nel CSP.
Sebbene non vengano offerte garanzie di latenza, questa soluzione in genere consente la latenza più bassa possibile e le velocità di trasferimento più elevate possibili traGoogle Cloud e altri ambienti cloud tramite 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 presso i partner in Cloud Marketplace possono fornire soluzioni per criptare il traffico verso l'ambiente dell'altro CSP. Google Cloud
Affidabilità e SLA
Cross-Cloud Interconnect utilizza lo SLA di Cloud Interconnect. Per avere diritto allo SLA, la configurazione di Cross-Cloud Interconnect deve utilizzare una o più coppie di connessioni, come descritto nella sezione Accordo sul livello del servizio della panoramica di Cross-Cloud Interconnect.
L'SLA copre tutto ciò che riguarda Google fino al perimetro della rete dell'altro provider di servizi cloud. Non copre la rete dell'altro CSP. Per ulteriori informazioni, consulta la documentazione dell'altro CSP per lo SLA sul suo prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.
Prezzi
È prevista una tariffa oraria per ogni connessione Cross-Cloud Interconnect e per ogni collegamento VLAN che si connette a un ambiente VPC. Il traffico in uscita tramite Cross-Cloud Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per maggiori informazioni, consulta i prezzi di Cross-Cloud Interconnect.
Consulta la pagina dei prezzi dell'altro CSP per il suo prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, è previsto un addebito mensile per l'interconnessione. I costi per il trasferimento di dati tramite l'interconnessione sono in genere inferiori rispetto a quelli per il trasferimento di dati su internet.
Non sono previsti costi separati per le località di interconnessione o l'apparecchiatura.
Confronto delle opzioni
Le opzioni presentate variano in termini di velocità, disponibilità, complessità, sicurezza e prezzi. Valuta 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 diagramma di flusso.
In genere, possiamo consigliare le seguenti opzioni:
- In molti scenari in cui i dati vengono scambiati occasionalmente o a basso volume e i trasferimenti non sono critici, 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 utilizzando indirizzi IP privati, valuta la possibilità di utilizzare Cloud VPN e un servizio VPN gestito sul lato dell'altro CSP.
- Se trasferisci grandi quantità di dati, l'utilizzo di Partner Interconnect con un partner abilitato al multicloud offre diversi vantaggi: capacità dedicata, costi inferiori per i trasferimenti di dati e, a seconda della topologia, un contratto di servizio per ogni parte della soluzione. La capacità di Partner Interconnect è normalmente inferiore a 10 Gbps per connessione.
- Se connetti le tue apparecchiature on-premise a più cloud, l'utilizzo di Dedicated Interconnect tramite un PoP comune è un'opzione comune. Comporta la complessità aggiuntiva di gestire il proprio hardware e i rapporti con una struttura di colocation. A meno che tu non disponga già dell'infrastruttura, questa soluzione è riservata ai casi in cui le velocità di trasferimento dei dati tipiche sono pari o superiori a 10 Gbps.
- Se non vuoi l'overhead della gestione di interconnessioni e apparecchiature di routing in PoP remoti, Cross-Cloud Interconnect fornisce una soluzione gestita in cui Google gestisce tutto questo per te.
Passaggi successivi
- Consulta la serie su Modelli e procedure per ambienti ibridi e multi-cloud.
- Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.