Questo documento aiuta gli architetti del cloud e i professionisti delle operazioni a decidere come collegarsi Google Cloud ad altri provider di servizi cloud (CSP) come Amazon Web Services (AWS) e Microsoft Azure. In un design multicloud, le connessioni tra CSP consentono i trasferimenti di dati tra le tue reti virtuali. Questo documento fornisce anche informazioni su come implementare l'opzione che hai scelto.
Molte organizzazioni operano su più piattaforme cloud, come misura temporanea durante una migrazione o perché hanno una strategia multi-cloud a lungo termine.
Per lo scambio di dati tra Google Cloud e altri fornitori di servizi cloud, in questo documento sono descritte diverse opzioni:
- Trasferimento di dati tramite indirizzi IP pubblici su internet.
- Utilizzare un servizio VPN gestito tra Google Cloud e l'altro CSP.
- Utilizzare Partner Interconnect su Google Cloud per connettersi a un partner che può connettersi direttamente all'altro CSP.
- Utilizzare Dedicated Interconnect su Google Cloud per trasferire i dati all'altro CSP tramite un punto di presenza (PoP) comune.
- Utilizzare 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 termina con un confronto di tutte le opzioni.
Questo documento riguarda i trasferimenti di dati tra macchine virtuali che si trovano inGoogle Cloud e nelle reti virtuali di altri fornitori di servizi cloud. Per i dati archiviati in altri Google Cloud prodotti, 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 fornitori di servizi cloud, in base alle tue esigenze e alle tue funzionalità.
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ù provider cloud, 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 collegare i tuoi ambienti cloud, è importante esaminare le regioni che scegli in ogni ambiente e avere una strategia per trasferire i dati che non risiedono in ambienti di rete virtuali.
Scegli le regioni cloud
Se le risorse di Google Cloud e di altri fornitori di servizi cloud si trovano in regioni geograficamente vicine, si ottiene un vantaggio in termini di costi e latenza per i trasferimenti di dati tra i fornitori di servizi cloud.
Il seguente diagramma illustra il flusso di dati tra Google Cloud e altri fornitori di servizi cloud.
Indipendentemente dal metodo di trasferimento, i dati passano da Google Cloud all'altro fornitore di servizi cloud come segue:
- Dalla Google Cloud regione in cui sono ospitate le risorse al POP di confine 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 fornitore di servizi cloud 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 di entrambi i fornitori non si trovano nella stessa area metropolitana. I dettagli sono riportati nella sezione relativa ai prezzi di ciascuna soluzione.
Assicurati di scegliere regioni adatte in ogni cloud che possano ospitare i carichi di lavoro previsti. Visita la pagina Località per Google Cloud e pagine simili per altri CSP, come la tabella delle 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 dell'area geografica per Compute Engine.
Trasferimento dei dati in Cloud Storage e BigQuery
Per impostazione predefinita, solo i dati all'interno di un Google Cloud ambiente VPC passano un tunnel Cloud VPN o una connessione Cloud Interconnect.
Se vuoi trasferire dati da e verso altri servizi Google, puoi utilizzare Private Service Connect e Private Google Access per gli 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, controlla la documentazione per verificare se i dati possono passare attraverso il suo prodotto VPN gestito o di interconnessione. In caso contrario, potresti essere in grado di trasmettere questi dati tramite macchine virtuali proxy che hai configurato nell'ambiente del rispettivo fornitore di servizi cloud per farli passare attraverso la connessione che preferisci.
Per trasferire i dati in 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 fornitore di servizi cloud è utilizzare internet e trasferire i dati utilizzando indirizzi IP esterni.
Il seguente diagramma illustra gli elementi di questa soluzione.
Tra la rete perimetrale di Google e la rete perimetrale dell'altro fornitore di servizi cloud, i dati passano tramite internet o utilizzano un peering diretto tra Google Cloud e l'altro fornitore di servizi cloud. I dati possono essere trasmessi 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 di Google si connette ad altre reti che formano collettivamente 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 le route e l'infrastruttura 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 abbia già connettività con Google (AS15169). Questa opzione è in genere indicata come transito IP ed è simile a quella acquistata da consumatori e aziende dai fornitori di servizi di accesso nelle loro case e attività.
- Connettiti direttamente a Google (AS15169). Questa opzione, chiamata peering, consente a una rete di inviare e ricevere direttamente traffico verso 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, il che consente di ottimizzare le prestazioni e i costi. Il peering è un sistema volontario. Quando scelgono di eseguire il peering, gli operatori di rete decidono congiuntamente quali strutture collegare, la quantità di larghezza di banda da provisionare, come suddividere i costi dell'infrastruttura e qualsiasi altro dettaglio necessario per configurare le connessioni. L'AS15169 ha un criterio di peering aperto, il che significa che, a condizione che una rete soddisfi i requisiti tecnici, Google eseguirà il peering con essa.
Il peering è un accordo privato e reciprocamente vantaggioso tra due reti indipendenti e, in quanto tali, le reti in genere non divulgano pubblicamente con chi fanno peering in determinate località, la quantità di larghezza di banda disponibile e così via. Tuttavia, grazie alle sue dimensioni e a una politica aperta, Google ha un peering diretto con quasi tutti i principali ISP e fornitori di servizi cloud in più località e regioni. Il team della rete di Google collabora direttamente con le controparti di queste reti per fornire una capacità di peering sufficiente a soddisfare la domanda.
Per scoprire di più su come funziona il peering internet, consulta il Playbook sul peering internet.
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 sia garantita la velocità e la latenza sul percorso tramite internet, in genere i principali fornitori di servizi cloud 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 i due fornitori, 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 fornitori di servizi cloud 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. 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 i prodotti di fornitori diversi potrebbero avere caratteristiche di rendimento che potrebbero non essere sempre in linea. Ad esempio, la capacità VPN IPsec per tunnel può variare da fornitore a fornitore.
Sicurezza
Il traffico su internet non è criptato e potrebbe passare tramite 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 in genere ha più percorsi diversi per la connettività internet dalle regioni e sono presenti connessioni di peering diretto con altri importanti fornitori di servizi cloud in più località in tutto il mondo.
Tuttavia, Google Cloud non fornisce SLA per la connettività ad altri CSP tramite internet. Sebbene tu debba controllare gli SLA per gli altri tuoi fornitori di servizi cloud, tipicamente si riferiscono solo alla connettività a internet nel suo complesso e non a fornitori specifici.
I fornitori potrebbero avere criteri di routing diversi 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 basarsi su link in una singola località di peering, poiché il traffico in uscita Google Cloud può unicamente utilizzare questi link per raggiungere la destinazione. Questo è accettabile in condizioni di normale funzionamento con il traffico scambiato all'interno della regione, ma è consigliabile per i clienti progettare i deployment multiregionali in modo da tollerare i guasti regionali. Ciò potrebbe includere la configurazione di gateway aggiuntivi, VPN ad alta disponibilità, peering di reti virtuali o altre topologie multiregione nel cloud di terze parti.
Le applicazioni devono inoltre essere create in modo da "funzionare in caso di errore", come consigliato da Google SRE nel libro sulla SRE. Ad esempio, se crei un'applicazione che si basa sulla possibilità di raggiungere un servizio di terze parti utilizzando il routing di internet, assicurati che l'applicazione funzioni ancora o almeno restituisca all'utente messaggi di errore utili in caso di problemi di connettività.
In caso di problemi con il routing di internet, il team di rete di Google tenterà di ripristinare la connettività con la terza parte. Tuttavia, non tutti i problemi rientrano nel 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 dell'assistenza con tutti i fornitori e un piano per la riassegnazione dei problemi in caso di problemi. Esegui anche esercitazioni periodiche BCP (Business Continuity Process) per garantire la resilienza delle applicazioni progettate su multicloud.
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 Google Cloud. Se la latenza non è critica, l'utilizzo del livello di servizio di rete standard offre un livello di prezzo inferiore.
Gli altri fornitori di servizi cloud hanno i propri costi per i trasferimenti di dati. In molti casi, fanno pagare solo il traffico in uscita dalla loro rete. Consulta il listino prezzi del tuo CSP. Per 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 ti consente di trasferire dati utilizzando indirizzi IP privati. Si tratta di un'estensione della soluzione precedente di trasferimento tramite internet senza richiedere hardware o partner.
Il seguente diagramma illustra gli elementi di questa soluzione.
Con 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 fornitore di servizi cloud avviene tramite internet, come nella precedente soluzione.
Implementazione
Google offre Cloud VPN come servizio VPN gestito per i tunnel IPsec criptati, che possono essere utilizzati da Google. Altri fornitori di servizi cloud 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 reti virtuali tra gli ambienti utilizzando i tunnel VPN.
Gli indirizzi IP nei due ambienti non devono sovrapporsi perché in Cloud VPN non è disponibile la funzionalità di Network Address Translation (NAT). Su Cloud Router, le route sovrapposte potrebbero essere rimosse dallo scambio tra ambienti, ma non sarà possibile alcuna comunicazione tra i servizi che utilizzano questi indirizzi IP.
Con Cloud Router in modalità di routing dinamico globale, puoi raggiungere tutte le regioni di una rete VPC globale utilizzando solo i tunnel VPN per quella regione. Per altri fornitori di servizi cloud, potresti aver bisogno di tunnel VPN per regione. Se hai più reti virtuali in un ambiente cloud che non sono in peering, devi collegare tutte le reti virtuali che devono comunicare tra loro in modo indipendente utilizzando una VPN.
Google Cloud offre guide all'interoperabilità, che contengono istruzioni dettagliate per la configurazione di tunnel VPN con altri importanti provider cloud:
- Gateway VPN Alibaba Cloud senza ridondanza: supporta solo le route statiche.
- Gateway VPN Alibaba Cloud con ridondanza: supporta solo le route statiche.
- AWS: supporta il routing dinamico con il router Cloud.
- Microsoft Azure: supporta il routing dinamico con router Cloud.
Velocità di trasferimento e latenza
Quando utilizzi i tunnel VPN gestiti, i dati seguono comunque lo stesso percorso di internet come se fossero scambiati direttamente utilizzando indirizzi IP pubblici. La latenza osservata dovrebbe essere simile all'opzione precedente con solo un piccolo sovraccarico 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 dei tunnel degli altri fornitori di servizi cloud e dalla larghezza di banda disponibile sul percorso internet.
Per una maggiore larghezza di banda, puoi implementare più tunnel in parallelo. Per ulteriori informazioni su come implementare una soluzione di questo tipo, consulta Creare VPN a velocità effettiva elevata.
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 sulla latenza o sulla larghezza di banda.
Sicurezza
Il traffico attraverso i tunnel VPN IPsec viene criptato utilizzando le crittografie accettate da entrambi i fornitori di servizi cloud. Per ulteriori informazioni, consulta Cifrari IKE supportati da Cloud VPN, Domande frequenti sulla VPN AWS e Parametri IPsec/IKE di Azure VPN.
Affidabilità e SLA
Cloud VPN offre un SLA del 99,9%-99,99% a seconda che sia selezionata la VPN classica o la VPN ad alta disponibilità. Altri CSP a volte offrono SLA per il proprio prodotto VPN gestito, ad esempio AWS Site-to-Site VPN SLA e Azure SLA per VPN Gateway. Tuttavia, questi SLA coprono solo la disponibilità dei gateway VPN e non includono la connettività ad altri CSP tramite internet, pertanto non esiste uno SLA per la soluzione end-to-end.
Per aumentare l'affidabilità, valuta la possibilità di utilizzare più gateway e tunnel VPN su Google Cloud e sugli altri fornitori di servizi cloud.
Prezzi
Per il servizio VPN gestito si applicano degli addebiti. Per Google Cloud, si applica un addebito orario. Consulta i prezzi di Cloud VPN. Per altri fornitori di servizi cloud, consulta i relativi listini prezzi, ad esempio consulta Prezzi delle connessioni VPN Site-to-Site di AWS o Prezzi di Azure VPN Gateway.
Oltre al prezzo orario 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 su internet, come descritto in Trasferimento tramite indirizzi IP esterni su internet. In molti casi, gli addebiti per il trasferimento dei dati superano il costo fisso di questa soluzione.
Partner Interconnect con partner multicloud abilitati
Partner Interconnect ti consente di connettere un Virtual Private Cloud alle reti virtuali di un altro CSP tramite la rete di alcuni partner selezionati che offrono soluzioni multicloud dirette. Esegui il collegamento 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 il router Cloud e il gateway dell'altro fornitore di servizi cloud tramite un'istanza di routing virtuale gestita dal partner che fornisce l'interconnessione. Il traffico passa attraverso la rete del partner traGoogle Cloud e l'altro fornitore di servizi cloud.
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 relativo prodotto di interconnessione per collegarti allo stesso partner. Ad esempio, su AWS puoi utilizzare Direct Connect e su Azure puoi utilizzare ExpressRoute.
- Sul lato del partner del fornitore di servizi, devi configurare l'apparecchiatura di routing virtuale che fornisce le sessioni BGP a Google Cloud e all'altro CSP.
Se lo spazio degli indirizzi IP tra i due ambienti CSP si sovrappone, il tuo partner potrebbe offrire la funzionalità NAT per l'apparecchiatura di routing virtuale. Per maggiori dettagli, consulta la documentazione dei partner.
Velocità di trasferimento e latenza
Questa soluzione offre capacità dedicata tra Google Cloud e altri CSP. A seconda del partner e dell'altro fornitore di servizi cloud, la capacità di allegato disponibile potrebbe variare. Google Cloud D'altra parte, Partner Interconnect è disponibile con una capacità di collegamento tra 50 Mbps e 50 Gbps.
La latenza di questa soluzione è la somma di quanto segue:
- Latenza tra la regione in cui sono ospitate le risorse suGoogle Cloud e la località dell'interconnessione a cui si connette il partner Google Cloud.
- La latenza nella rete del partner verso, da e attraverso l'istanza di routing virtuale verso l'altro CSP.
- La 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 sedi di Google Cloud e l'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 fornitore di servizi cloud sia il POP di confine e l'istanza di routing virtuale si trovano nell'area di Ashburn, in Virginia.
Anche se Google Cloud e molti altri fornitori di servizi cloud non offrono garanzie sulla latenza per il traffico verso l'edge della rete, in quanto esiste un percorso e una capacità dedicati tramite il partner, in genere la latenza in questa soluzione è meno variabile rispetto all'utilizzo di indirizzi IP esterni o di una soluzione VPN.
Sicurezza
Il traffico su Partner Interconnect non è criptato per impostazione predefinita. Per contribuire a proteggere il traffico, puoi implementare la 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, la VPN site-to-site AWS può essere utilizzata tramite AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico lato dell'altro fornitore di servizi cloud.
Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.
Affidabilità e SLA
Questa soluzione prevede tre diversi SLA: 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 è previsto alcun SLA per una singola connessione Partner Interconnect.
Consulta la documentazione dell'altro CSP per lo SLA sul proprio prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o su Azure lo SLA per ExpressRoute.
Consulta la documentazione o i termini del fornitore di servizi partner per Partner Interconnect per conoscere lo SLA sulla disponibilità della connettività e dell'istanza di routing virtuale. Ad esempio, consulta il Megaport Global Services Agreement.
Prezzi
D'altra parte, è prevista una tariffa mensile per ogni collegamento Partner Interconnect, a seconda della larghezza di banda. Google Cloud 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 prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi includono anche un addebito mensile per l'interconnessione e i costi di trasferimento dei dati tramite l'interconnessione a una tariffa inferiore rispetto a quella di internet.
Il partner fornisce gli addebiti per i servizi di interconnessione in base ai propri prezzi, che puoi trovare sul suo sito web o consultando il suo team di vendita per richiedere un preventivo. In genere, se tutti i trasferimenti di dati avvengono nella stessa area metropolitana, i costi sono molto più bassi 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 degli altri CSP, a volte questa soluzione può offrire il costo totale più basso a causa delle tariffe di uscita scontate. Anche se vengono aggiunti i costi mensili per l'interconnessione per Partner Interconnect, l'altro CSP e il partner fornitore di servizi, l'utilizzo di questa soluzione può offrire risparmi significativi. Poiché i prezzi dei partner e di altri fornitori di servizi cloud possono variare senza preavviso, effettua il tuo confronto utilizzando le quotazioni aggiornate 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 collegare entrambi i provider cloud utilizzando Dedicated Interconnect sul latoGoogle Cloud e un prodotto equivalente nell'altro CSP. La località dell'interconnessione non è necessariamente la stessa della regione in cui si trovano le risorse.
Il seguente diagramma mostra una configurazione ridondante che utilizza due connessioni di Dedicated Interconnect:
Le route vengono scambiate tra router Cloud e il gateway sull'altro lato del CSP tramite un router fisico che inserisci in una struttura di interconnessione comune. Il traffico passa attraverso questo router tra Google Cloud e l'altro fornitore di servizi cloud.
Implementazione
Questa soluzione richiede di ospitare e gestire dispositivi di instradamento fisici in una struttura di colocation in cui sono presenti Google e il fornitore di servizi cloud 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 provider di servizi utilizzando un prodotto equivalente, ad esempio AWS Direct Connect o Azure ExpressRoute. Sul dispositivo di routing, devi configurare BGP per consentire lo scambio di route tra i due ambienti cloud.
Controlla l'elenco delle sedi dei centri di colocation di Google Cloud e del tuo altro fornitore di servizi cloud, ad esempio le località di AWS Direct Connect o le località di peering di Azure ExpressRoute, per identificare le località adatte per questa configurazione.
Gli intervalli di indirizzi IP tra le reti virtuali non devono sovrapporsi, a meno che il dispositivo di routing fisico non sia in grado di eseguire la NAT tra gli ambienti o che tu limiti alcuni scambi di route tra gli ambienti.
Questa soluzione è efficace se utilizzi la connettività dedicata per eseguire anche il collegamento al tuo ambiente on-premise, oltre alla connessione a un altro fornitore di servizi cloud.
In altri casi, questa soluzione è complessa perché richiede di possedere e manutenere l'attrezzatura fisica e di avere un contratto con una struttura di colocation. Ti consigliamo di utilizzare 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 economica oppure hai requisiti di larghezza di banda che i partner non possono soddisfare.
Velocità di trasferimento e latenza
Questa soluzione offre capacità dedicata tra Google Cloud e un altro CSP. Google Cloud D'altra parte, 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 sono ospitate le risorse suGoogle Cloud e la località di interconnessione in cui esegui l'interconnessione conGoogle Cloud.
- La latenza della struttura e delle apparecchiature fisiche, che solitamente è trascurabile rispetto alla latenza dovuta alla lunghezza della fibra.
- La latenza dalla posizione dell'interconnessione tramite la rete dell'altro fornitore di servizi cloud alla regione in cui le risorse sono ospitate nel fornitore di servizi cloud.
Sebbene non vengano offerte garanzie sulla latenza, in genere questa soluzione 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 contribuire a proteggere il traffico, puoi implementare la 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, la VPN site-to-site AWS può essere utilizzata tramite AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico lato dell'altro fornitore di servizi cloud.
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 è previsto alcun SLA per una singola connessione Dedicated Interconnect.
Per ulteriori informazioni, consulta la documentazione dell'altro fornitore di servizi cloud per lo SLA sul proprio prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.
La struttura di colocation o il fornitore di hardware per l'apparecchiatura di routing fisico potrebbe anche offrire SLA per i propri servizi.
Prezzi
D'altra parte, è prevista una tariffa mensile per ogni porta di Interconnect dedicata e per ogni collegamento VLAN che si connette a un ambiente VPC. Google Cloud 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 fornitore di servizi cloud per il suo prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi includono anche un addebito mensile per l'interconnessione e i costi di trasferimento dei dati tramite l'interconnessione a una tariffa inferiore rispetto a quella di internet.
Inoltre, devi tenere conto degli addebiti per i servizi della struttura di colocation che forniscono spazio, energia elettrica e connessioni fisiche a entrambi gli ambienti cloud, nonché eventuali costi e contratti di servizio in corso con il fornitore per l'apparecchiatura di instradamento fisico. Se la connessione tra i due 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 da Cross-Cloud Interconnect
Puoi connettere le tue Google Cloud reti VPC alle tue reti virtuali in un altro CSP tramite la struttura di rete di Google. In un certo senso, questa configurazione funziona come Partner Interconnect, ma con l'SLA di Google che copre sia le reti Google che le interconnessioni stesse.
Il seguente diagramma mostra una configurazione di Cross-Cloud Interconnect con il numero minimo di connessioni.
Le route vengono scambiate tra il router Cloud e il gateway sull'altro lato del fornitore di servizi cloud tramite la struttura di rete di Google. Il traffico passa attraverso questa infrastruttura tra Google Cloud e l'altro fornitore di servizi cloud.
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 Google Cloud rete VPC (Virtual Private Cloud) con una rete ospitata da un provider di servizi cloud supportato.
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 il servizio completo e ti informerà se dovrai aprire una richiesta di assistenza con l'altro fornitore di servizi cloud.
Questa soluzione richiede di seguire la procedura di configurazione per l'altro CSP, inclusa la scelta del punto di interconnessione delle due reti. Sono supportati solo alcuni CSP.
Velocità di trasferimento e latenza
Questa soluzione offre capacità dedicata tra Google Cloud e un altro CSP. Google Cloud D'altra parte, 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 sono ospitate le risorse Google Cloud e la località cross-cloud.
- Latenza tra la posizione perimetrale di Google e la posizione perimetrale dell'altro fornitore di servizi cloud (spesso nella stessa struttura)
- Latenza dalla località edge dell'altro CSP in cui è distribuito Cross-Cloud Interconnect alla regione in cui le risorse sono ospitate nel CSP.
Sebbene non vengano offerte garanzie sulla latenza, in genere questa soluzione consente la minima latenza possibile e le massime velocità di trasferimento traGoogle Cloud e altri ambienti cloud tramite indirizzi IP privati.
Sicurezza
Poiché il traffico su Cross-Cloud Interconnect non è criptato, consigliamo di utilizzare la crittografia a livello di applicazione per il traffico sensibile.
Se tutto il traffico deve essere criptato, le appliance virtuali disponibili dai Google Cloud partner in Cloud Marketplace possono fornire soluzioni per criptare il traffico nell'ambiente dell'altro fornitore di servizi cloud.
Affidabilità e SLA
Cross-Cloud Interconnect utilizza il SLA di Cloud Interconnect. Per poter usufruire dello 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.
Il contratto SLA copre tutto ciò che si trova sul lato di Google fino al perimetro della rete dell'altro fornitore di servizi cloud. Non copre la rete dell'altro fornitore di servizi cloud. Per ulteriori informazioni, consulta la documentazione dell'altro fornitore di servizi cloud per lo SLA sul proprio 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 ulteriori informazioni, consulta i prezzi di Cross-Cloud Interconnect.
Consulta la pagina dei prezzi dell'altro fornitore di servizi cloud 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 a quelli per il trasferimento di dati tramite internet.
Non sono previsti costi separati per le sedi o le attrezzature di interconnessione.
Confronto delle opzioni
Le opzioni presentate variano in termini di velocità, disponibilità, complessità, sicurezza e prezzo. Ti consigliamo di valutare attentamente tutte le opzioni in base alle tue esigenze.
Il seguente diagramma illustra la procedura per scegliere una delle soluzioni indicate in questo documento tramite un diagramma di flusso.
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 critici, il trasferimento di dati tramite internet è l'opzione più semplice e offre comunque una latenza relativamente bassa e una larghezza di banda elevata.
- Se è obbligatoria 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 fornitore di servizi cloud.
- Se trasferisci quantità maggiori di dati, l'utilizzo di Partner Interconnect con un partner multicloud consente di usufruire di diversi vantaggi: capacità dedicata, costi inferiori per i trasferimenti di dati e, a seconda della topologia, un SLA per ogni parte della soluzione. La capacità di Partner Interconnect è in genere inferiore a 10 Gbps per connessione.
- Se colleghi le tue apparecchiature on-premise a più cloud, l'utilizzo di Dedicated Interconnect tramite un POP comune è un'opzione comune. Inoltre, comporta una maggiore complessità nella gestione del tuo hardware e dei rapporti con una struttura di colocation. A meno che non abbiate già implementato l'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'oneroso compito di gestire i cross-connect e l'apparecchiatura di routing nei POP remoti, Cross-Cloud Interconnect offre una soluzione gestita in cui è Google a occuparsi di tutto.
Passaggi successivi
- Rivedi la serie su modelli e procedure per ambienti ibridi e multi-cloud.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.