Modèles pour la connexion d'autres fournisseurs de services cloud avec Google Cloud

Ce document aide les architectes cloud et les responsables d'exploitation à choisir une solution permettant de connecter Google Cloud à d'autres fournisseurs de services cloud tels qu'Amazon Web Services (AWS) et Microsoft Azure. Dans une conception multicloud, les connexions entre fournisseurs de services cloud permettent de transférer des données entre vos réseaux virtuels. Cet article fournit également des informations sur la mise en œuvre de la solution choisie.

De nombreuses organisations utilisent plusieurs plates-formes cloud, soit à titre de mesure temporaire lors d'une migration, soit parce qu'elles disposent d'une stratégie multicloud à long terme.

Ce document décrit plusieurs options permettant d'échanger des données entre Google Cloud et d'autres fournisseurs de services cloud :

• Transfert de données via des adresses IP publiques sur Internet
• Utiliser un service VPN géré entre Google Cloud et l'autre fournisseur de service cloud.
• Utiliser Partner Interconnect sur Google Cloud pour vous connecter à un partenaire pouvant se connecter directement à l'autre CSP.
• Utiliser Dedicated Interconnect sur Google Cloud pour transférer des données vers l'autre CSP via un point de présence commun (POP).
• Utiliser Cross-Cloud Interconnect sur Google Cloud pour une connexion gérée à un autre fournisseur de services cloud.

Ces options présentent des différences en termes de vitesse de transfert, de latence, de fiabilité, de contrat de niveau de service (SLA), de complexité et de coûts. Cet article décrit en détail chaque solution avec ses avantages et ses inconvénients, et fournit un comparatif des solutions.

Ce document couvre les transferts de données entre plusieurs machines virtuelles hébergées dans Google Cloud et dans les réseaux virtuels d'autres fournisseurs de services cloud. Pour les données stockées dans d'autres produits Google Cloud, tels que Cloud Storage et BigQuery, consultez la section concernant ces produits.

Cet article peut vous servir de guide pour évaluer les options de transfert de données entre Google Cloud et un ou plusieurs autres fournisseurs de services cloud, en fonction de vos besoins et de vos capacités.

Les concepts abordés dans ce document s'appliquent dans plusieurs cas :

• Si vous prévoyez de transférer de grandes quantités de données sur une courte période, par exemple pour un projet de migration de données.
• Si vous exécutez des transferts de données continus entre plusieurs fournisseurs Cloud. Par exemple, si vous exécutez vos charges de travail de calcul sur un autre fournisseur de services cloud, mais que vos charges de travail de big data utilisent Google Cloud.

Considérations initiales

Avant de choisir une solution pour connecter vos environnements cloud, il est important de savoir quelle région vous allez utiliser pour chaque environnement et d'établir une stratégie afin de transférer les données qui ne sont pas situées dans des environnements de réseaux virtuels.

Choisir des régions cloud

Si les ressources Google Cloud et celles d'autres fournisseurs de services cloud se situent dans des régions géographiquement proches les unes des autres, les transferts de données entre fournisseurs cloud présentent un avantage en termes de coût et de latence.

Le schéma suivant illustre la circulation de données entre Google Cloud et d'autres fournisseurs de services cloud.

Quelle que soit la méthode de transfert, les données circulent de Google Cloud vers l'autre fournisseur de services cloud comme suit :

• Depuis la région Google Cloud hébergeant les ressources vers le POP périphérique de Google.
• Via une installation tierce entre Google Cloud et l'autre fournisseur de services cloud.
• Depuis le POP périphérique de l'autre fournisseur de services cloud vers la région hébergeant les ressources au sein du réseau de ce dernier.

Les données qui circulent depuis l'autre fournisseur de services cloud vers Google Cloud passent par le même chemin, mais dans le sens opposé.

Le chemin de bout en bout détermine la latence du transfert de données. Pour certaines solutions, les frais de réseau augmentent également lorsque les POP périphériques des deux fournisseurs ne se situent pas dans la même zone métropolitaine. Vous trouverez plus de détails dans la section ci-dessous concernant les tarifs de chaque solution.

Pour chaque environnement cloud, veillez à choisir des régions adaptées pouvant héberger les charges de travail prévues. Consultez la page Emplacements pour Google Cloud, ainsi que les pages semblables pour les autres fournisseurs de services cloud, telles que le tableau des régions AWS ou les produits Azure par région. Si vous avez besoin d'aide pour choisir un ou plusieurs emplacements Google Cloud, reportez-vous à la page Bonnes pratiques pour la sélection des régions Compute Engine.

Transfert de données vers Cloud Storage et BigQuery

Par défaut, seules les données qui résident dans un environnement VPC Google Cloud transitent par un tunnel Cloud VPN ou une connexion Cloud Interconnect par défaut.

Si vous souhaitez transférer des données depuis et vers d'autres services Google, vous pouvez utiliser Private Service Connect et l'Accès privé à Google pour les hôtes sur site depuis l'environnement de l'autre fournisseur de services cloud.

Si vous souhaitez transférer le stockage d'objets, la base de données, l'entrepôt de données ou d'autres produits d'un fournisseur cloud tiers, consultez sa documentation pour savoir si les données peuvent transiter par son interconnexion ou sa solution VPN gérée. Si ce n'est pas le cas, vous pourrez peut-être transmettre ces données via des machines virtuelles proxy configurées dans l'environnement du fournisseur de services cloud respectif afin de les faire transiter via la connexion souhaitée.

Pour transférer des données vers Cloud Storage ou BigQuery, vous pouvez également utiliser le service de transfert de stockage ou le service de transfert BigQuery.

Transfert de données via des adresses IP externes sur Internet

Le moyen le plus simple de transférer des données entre Google Cloud et un autre fournisseur de services cloud consiste à utiliser Internet et à transmettre les données à l'aide d'adresses IP externes.

Le schéma suivant illustre les composants de cette solution :

Entre les périphéries du réseau de Google et de l'autre fournisseur de services cloud, les données transitent par Internet ou utilisent un appairage direct entre Google Cloud et l'autre fournisseur de services cloud. Les données ne peuvent être transmises qu'entre des ressources possédant des adresses IP publiques.

Comment Google se connecte à d'autres réseaux

Les POP périphériques de Google sont les endroits où le réseau de Google se connecte à d'autres réseaux qui forment collectivement Internet. Google est présent dans de nombreux emplacements à travers le monde.

Sur Internet, chaque réseau se voit attribuer un numéro de système autonome (ASN, autonomous system number) qui englobe l'infrastructure et les routes internes du réseau. Le numéro ASN principal de Google est 15169.

Un réseau peut envoyer ou recevoir du trafic vers ou depuis Google à l'aide de deux manières différentes :

• En achetant un service Internet auprès d'un fournisseur d'accès à Internet (FAI) ayant déjà une connectivité à Google (AS15169). Cette option, généralement appelée transit IP, est semblable à ce que les consommateurs et les entreprises achètent auprès des fournisseurs d'accès pour leur domicile et leur entreprise.
• En se connectant directement à Google (AS15169). Cette option, appelée appairage, permet à un réseau d'envoyer et de recevoir directement du trafic vers ou depuis Google (AS15169), sans passer par un réseau tiers. À grande échelle, l'appairage est généralement préférable au transit, car les opérateurs réseau ont davantage de contrôle sur la manière dont le trafic est échangé, ce qui permet l'optimisation des performances et des coûts. L'appairage est un système volontaire. Lorsque vous choisissez d'effectuer l'appairage, les opérateurs réseau déterminent conjointement les installations à connecter, la quantité de bande passante à provisionner, la répartition des coûts d'infrastructure et toute autre information nécessaire à la configuration des connexions. AS15169 dispose d'une politique ouverte d'appairage. Cela signifie qu'à partir du moment où un réseau répond aux exigences techniques, Google peut s'appairer avec lui.

L'appairage est un accord privé, mutuellement bénéfique, entre deux réseaux indépendants. Par conséquent, les réseaux ne divulguent généralement pas publiquement avec qui ils s'apparient à des emplacements spécifiques, la quantité de bande passante disponible, etc. Toutefois, en raison de l'ampleur et d'une politique ouverte, Google est directement associé à presque tous les principaux FAI et fournisseurs de services cloud dans plusieurs emplacements et régions. L'équipe chargée du réseau Google collabore directement avec ses homologues sur ces réseaux pour fournir une capacité d'appairage suffisante en fonction de la demande.

Pour en savoir plus sur le fonctionnement de l'appairage Internet, consultez le Guide sur l'appairage Internet.

Mise en œuvre

Dans cette configuration, toutes les machines virtuelles qui transfèrent des données entre Google Cloud et d'autres fournisseurs de services cloud doivent posséder une adresse IP publique. À une extrémité du réseau, le pare-feu doit être ouvert pour autoriser une connexion depuis l'adresse IP publique de l'autre fournisseur cloud. Aucune étape supplémentaire n'est requise, car l'échange de données s'effectue via la connectivité Internet existante.

Vitesse de transfert et latence

Généralement, bien qu'aucune vitesse ni aucune latence ne soit garantie sur le chemin Internet, les principaux fournisseurs de services cloud et Google échangent directement des données à plusieurs emplacements à travers le monde. La capacité est partagée avec d'autres clients et services, mais la latence est souvent comparable ou inférieure à celle des autres options, en raison de la connexion directe entre les deux fournisseurs.

Nous vous recommandons de tester la latence et la bande passante entre Google Cloud et les autres fournisseurs de services cloud dans les régions que vous avez choisies. Vous pouvez effectuer un test rapide à l'aide d'outils tels que iperf ou netperf, ou exécuter une analyse comparative personnalisée plus complète basée sur votre application. Bien que les conditions puissent varier au fil du temps, l'analyse comparative vous montre les performances auxquelles vous pouvez vous attendre et vous permet de déterminer si cette solution répond à vos besoins. Si vous avez besoin d'une bande passante dédiée entre les deux environnements, nous vous recommandons d'opter pour une autre solution.

Notez que les produits issus de fournisseurs différents peuvent avoir des caractéristiques de performances susceptibles de ne pas toujours correspondre. Par exemple, la capacité VPN IPsec par tunnel peut varier d'un fournisseur à l'autre.

Sécurité

Le trafic sur Internet n'est pas chiffré et peut transiter par des fournisseurs d'accès à Internet (FAI), des installations et des systèmes autonomes tiers. Par conséquent, vous devez chiffrer le trafic sensible au niveau de la couche d'application ou choisir une autre solution.

Fiabilité et contrat de niveau de service

Google Cloud propose généralement des chemins variés pour la connectivité Internet depuis les régions, et des connexions d'appairage direct avec d'autres grands fournisseurs de services cloud sont disponibles à plusieurs emplacements à travers le monde.

Toutefois, Google Cloud ne fournit aucun contrat de niveau de service pour la connectivité à d'autres fournisseurs de services cloud sur Internet. Bien que nous vous recommandions de vérifier les contrats de niveau de service offerts par vos autres fournisseurs cloud, ces contrats ne se réfèrent habituellement qu'à la connectivité Internet dans son ensemble et non à des fournisseurs spécifiques.

Les fournisseurs peuvent disposer de différentes règles de routage, ce qui est susceptible d'avoir une incidence sur la disponibilité. Par exemple, sur la page peeringdb, Amazon explique que de nombreuses régions AWS n'annoncent que des routes locales, car les VPC AWS sont régionaux seulement (alors que les VPC Google Cloud sont mondiaux). Cela signifie que les clients peuvent se reposer sur des liens présents sur un emplacement d'appairage unique, car le trafic quittant Google Cloud ne peut atteindre la destination qu'à l'aide de ces liens. Ce n'est pas un problème dans le cadre d'un fonctionnement normal, lorsque le trafic est échangé au sein de la région. Toutefois, il est conseillé aux clients de concevoir l'architecture des déploiements multirégionaux de manière à ce qu'ils tolèrent les défaillances régionales. Cela peut inclure la configuration de passerelles supplémentaires, de VPN haute disponibilité, d'appairages de réseaux virtuels ou d'autres topologies multirégionales dans le cloud tiers.

La configuration des applications doit également être de type "fail open", comme recommandé dans le livre sur l'ingénierie SRE de Google. Par exemple, si vous créez une application qui repose sur la capacité à accéder à un service tiers à l'aide du routage Internet, assurez-vous que cette application fonctionne toujours, ou qu'elle renvoie au moins des messages d'erreur utiles à l'utilisateur en cas de problèmes de connectivité.

Lorsque des problèmes de routage Internet surviennent, l'équipe chargée du réseau Google tente de restaurer la connectivité avec le tiers. Cependant, tous les problèmes ne seront pas sous le contrôle de Google. Par conséquent, dans certains cas, la réparation pourrait dépendre des actions d'un tiers (FAI ou fournisseur cloud). Les clients ont le plus d'influence sur la manière dont les opérateurs répondent aux pannes. Par conséquent, assurez-vous de disposer d'une couverture d'assistance applicable à tous les fournisseurs et d'un plan pour faire remonter les problèmes le cas échéant. Effectuez également des simulations PCA (plan de continuité d’activité) régulièrement pour garantir la résilience des applications conçues sur le multicloud.

Tarifs

Pour les transferts de données via Internet, les tarifs de sortie Internet normaux s'appliquent au trafic quittant Google Cloud. Dans les scénarios où la latence n'est pas critique, le niveau de service réseau standard vous permet de bénéficier de tarifs réduits.

Les autres fournisseurs de services cloud appliquent leurs propres frais aux transferts de données. Dans la plupart des cas, ils ne facturent que le trafic quittant leur réseau. Reportez-vous à la grille tarifaire de votre fournisseur de services cloud pour en savoir plus. Par exemple, vous pouvez consulter la tarification des transferts de données EC2 pour AWS ou les détails de la tarification de la bande passante pour Azure.

VPN géré entre les fournisseurs cloud

Vous pouvez utiliser les services VPN gérés des deux fournisseurs cloud, ce qui présente deux avantages. Cela fournit un canal chiffré entre les réseaux virtuels dans les deux environnements cloud et vous permet de transférer des données à l'aide d'adresses IP privées. Il s'agit d'une extension de la solution précédente qui consiste à transférer des données sur Internet. Par ailleurs, elle ne nécessite aucun équipement ni partenaire.

Le schéma suivant illustre les composants de cette solution :

Grâce à cette solution, les données sont chiffrées sur Google Cloud à l'aide de Cloud VPN et d'une solution VPN pour l'autre fournisseur de services cloud. Le transfert de données entre Google Cloud et les autres fournisseurs de services utilise Internet comme dans la solution précédente.

Implémentation

Google propose Cloud VPN, qui est utilisable côté Google en tant que service VPN géré pour les tunnels IPsec chiffrés. D'autres fournisseurs de services cloud possèdent leurs propres produits VPN gérés, qui permettent de créer des tunnels VPN IPsec entre les deux environnements. Par exemple, AWS propose AWS Site-to-Site VPN et Azure la passerelle VPN Azure. Vous pouvez connecter vos réseaux virtuels entre les environnements à l'aide de tunnels VPN.

Les adresses IP des deux environnements ne doivent pas se chevaucher, car aucune fonctionnalité de traduction d'adresse réseau (NAT, network address translation) n'est disponible dans Cloud VPN. Sur Cloud Router, les routes se chevauchant pourraient ne plus pouvoir être échangées entre les environnements, mais cela empêcherait alors toute communication entre les services utilisant ces adresses IP.

Avec Cloud Router en mode de routage dynamique global, vous pouvez d'atteindre toutes les régions d'un réseau VPC mondial en n'utilisant que des tunnels VPN vers cette région. Pour les autres fournisseurs de services cloud, vous aurez peut-être besoin de tunnels VPN par région. Si vous disposez de plusieurs réseaux virtuels dans un environnement cloud qui ne sont pas appairés, vous devez connecter tous les réseaux virtuels devant communiquer entre eux indépendamment à l'aide d'un VPN.

Google Cloud propose des guides d'interopérabilité qui fournissent des instructions détaillées sur la configuration de tunnels VPN vers d'autres grands fournisseurs cloud :

• Alibaba – Passerelle Cloud VPN sans redondance : n'accepte que les routes statiques.
• Alibaba – Passerelle Cloud VPN avec redondance : n'accepte que les routes statiques.
• AWS : accepte le routage dynamique avec Cloud Router.
• Microsoft Azure : accepte le routage dynamique avec Cloud Router.

Vitesse de transfert et latence

Lorsque vous utilisez des tunnels VPN gérés, les données suivent le même chemin Internet que si elles étaient échangées directement à l'aide d'adresses IP publiques. La latence constatée est comparable à celle à l'option précédente, avec seulement une légère hausse de latence liée au tunnel VPN. La bande passante disponible est limitée par la bande passante maximale par tunnel VPN sur Google Cloud, par la bande passante maximale des tunnels de l'autre fournisseur de services cloud et par la bande passante disponible sur le chemin Internet.

Pour profiter d'une meilleure bande passante, vous pouvez déployer plusieurs tunnels en parallèle. Consultez la page Créer des VPN à haut débit pour en savoir plus sur le déploiement de ce type de solution.

Vous pouvez tester la latence et la bande passante comme décrit dans la section précédente, mais les conditions peuvent varier au fil du temps, et aucune garantie n'est fournie en termes de latence ou de bande passante.

Sécurité

Le trafic via les tunnels VPN IPsec est chiffré à l'aide d'algorithmes de chiffrement acceptés par les deux fournisseurs de services cloud. Pour en savoir plus, consultez les algorithmes de chiffrement IKE compatibles avec Cloud VPN, les questions fréquentes concernant les VPN AWS et les paramètres IPsec/IKE pour les VPN Azure.

Fiabilité et contrat de niveau de service

Cloud VPN fournit un contrat de niveau de service garantissant une disponibilité de 99,9 à 99,99 %, selon que vous avez choisi un VPN standard ou un VPN haute disponibilité. D'autres fournisseurs cloud proposent parfois des contrats de niveau de service pour leur produit VPN géré, tels que le contrat de niveau de service d'AWS Site-to-Site VPN ou le SLA pour la passerelle VPN d'Azure. Toutefois, ces contrats de niveau de service ne couvrent que la disponibilité des passerelles VPN et n'incluent pas la connectivité à d'autres fournisseurs cloud sur Internet. Il n'existe donc aucun contrat de niveau de service s'appliquant à la solution de bout en bout.

Pour améliorer la fiabilité, envisagez d'utiliser plusieurs passerelles et tunnels VPN sur Google Cloud et sur les autres fournisseurs de services cloud.

Tarifs

Des frais s'appliquent au service VPN géré. Dans le cas de Google Cloud, un tarif horaire est facturé. Reportez-vous aux tarifs de Cloud VPN pour en savoir plus. Consultez également les grilles tarifaires des autres fournisseurs de services cloud pour connaître leurs tarifs. Par exemple, consultez les tarifs de connexion d'AWS Site-to-Site VPN ou la tarification de la passerelle VPN Azure.

En plus du tarif horaire qui s'applique au service VPN, des frais liés aux données transférées via les passerelles VPN vous sont facturés. Pour Google Cloud et de nombreux fournisseurs de services cloud, les frais standards de transfert de données Internet s'appliquent, comme indiqué dans la section Transfert de données via des adresses IP externes sur Internet. Dans la plupart des cas, les frais de transfert de données dépassent le coût fixe de cette solution.

Partner Interconnect avec des partenaires offrant des solutions multicloud

Partner Interconnect vous permet de connecter un cloud privé virtuel aux réseaux virtuels d'un autre fournisseur de services cloud via le réseau de partenaires proposant des solutions multicloud directes. Vous vous connectez en déployant une ou plusieurs instances de routage virtuel qui se chargent de la configuration nécessaire du protocole BGP (Border Gateway Protocol).

Le schéma suivant montre une configuration redondante qui utilise deux connexions Partner Interconnect :

Les routes sont échangées entre Cloud Router et la passerelle du côté de l'autre fournisseur de services cloud via une instance de routage virtuel gérée par le partenaire fournissant l'interconnexion. Le trafic circule sur le réseau partenaire entre Google Cloud et l'autre fournisseur cloud.

Mise en œuvre

Cette solution nécessite la configuration de plusieurs composants :

• Du côté de Google Cloud, configurez l'interconnexion partenaire avec un fournisseur de services d'interconnexion desservant vos régions Google Cloud et offrant une connectivité multicloud à l'autre fournisseur de services cloud.
• Du côté de l'autre fournisseur de services cloud, vous devez utiliser son produit d'interconnexion pour vous connecter au même partenaire. Par exemple, vous pouvez utiliser Direct Connect pour AWS et ExpressRoute pour Azure.
• Du côté du fournisseur de services partenaire, vous devez configurer l'équipement de routage virtuel qui établit les sessions BGP vers Google Cloud et l'autre fournisseur cloud.

Si l'espace d'adresses IP entre les deux environnements des fournisseurs cloud se chevauche, votre partenaire peut proposer la fonctionnalité NAT pour l'équipement de routage virtuel. Consultez la documentation des partenaires pour plus de détails.

Vitesse de transfert et latence

Cette solution fournit une capacité dédiée entre Google Cloud et d'autres fournisseurs de services cloud. Selon le partenaire et l'autre fournisseur cloud, la capacité du rattachement disponible peut varier. Du côté de Google Cloud, Partner Interconnect est disponible avec une capacité de rattachement comprise entre 50 Mbit/s et 50 Gbit/s.

La latence pour cette solution correspond à la somme des éléments suivants :

• Latence entre la région hébergeant vos ressources sur Google Cloud et l'emplacement d'interconnexion depuis lequel le partenaire se connecte à Google Cloud.
• Latence dans le réseau du partenaire depuis, vers et via l'instance de routage virtuel jusqu'à l'autre fournisseur de services cloud.
• Latence depuis l'emplacement périphérique de l'autre fournisseur cloud où se produit l'interconnexion avec le partenaire jusqu'à la région qui héberge les ressources dans le fournisseur cloud.

Pour minimiser la latence, les emplacements périphériques de Google Cloud et de l'autre fournisseur de services cloud doivent se trouver dans la même zone métropolitaine, tout comme l'instance de routage virtuel. Par exemple, vous pouvez bénéficier d'une connexion à faible latence si les deux régions cloud des fournisseurs de services cloud, le POP périphérique et l'instance de routage virtuel se situent tous dans la zone d'Ashburn, en Virginie.

Bien que Google Cloud et de nombreux autres fournisseurs de services cloud n'offrent aucune garantie de latence pour le trafic vers leur périphérie de réseau, car le partenaire dispose d'un chemin et d'une capacité dédiés, la latence de cette solution est généralement moins variable que si vous utilisiez des adresses IP externes ou une solution VPN.

Sécurité

Le trafic sur Partner Interconnect n'est pas chiffré par défaut. Pour sécuriser votre trafic, vous pouvez déployer un VPN haute disponibilité sur Cloud Interconnect sur le côté Google Cloud de la connexion. Certains autres fournisseurs de services cloud vous permettent d'exploiter leur service VPN géré sur une interconnexion. Par exemple, AWS Site-to-Site VPN peut être utilisé sur AWS Direct Interconnect. Vous pouvez également employer un dispositif virtuel qui chiffre le trafic du côté de l'autre fournisseur de services cloud.

Une autre option consiste à chiffrer votre trafic au niveau de la couche d'application plutôt que d'utiliser un VPN.

Fiabilité et contrat de niveau de service

Cette solution implique trois contrats de niveau de service différents : un de Google, un autre du partenaire d'interconnexion, et un autre de l'autre fournisseur de services cloud.

Lorsque vous utilisez Partner Interconnect de manière redondante, Google fournit des contrats de niveau de service garantissant une disponibilité mensuelle de 99,9 à 99,99 % en fonction de la topologie choisie. Les connexions qui n'exploitent qu'une interconnexion partenaire ne sont pas couvertes par un contrat de niveau de service.

Consultez la documentation de l'autre fournisseur de services cloud pour connaître le contrat de niveau de service qui s'applique à son produit d'interconnexion. Reportez-vous par exemple au contrat de niveau de service d'AWS Direct Connect ou au SLA pour ExpressRoute d'Azure.

Consultez la documentation ou les conditions du fournisseur de services Partner Interconnect pour découvrir la disponibilité de la connectivité et de l'instance de routage virtuel garantie par son contrat de niveau de service. Par exemple, reportez-vous au contrat de service global Megaport.

Tarifs

Du côté de Google Cloud, des frais mensuels sont facturés pour chaque rattachement Partner Interconnect, en fonction de la bande passante. Le trafic sortant via Partner Interconnect est facturé à un tarif inférieur au trafic Internet. Pour en savoir plus, consultez les tarifs de l'interconnexion partenaire.

Consultez la page de tarification de l'autre fournisseur de services cloud pour connaître les tarifs de son produit d'interconnexion. Reportez-vous par exemple à la tarification d'AWS Direct Connect ou à la tarification d'Azure ExpressRoute. En règle générale, le modèle de tarification inclut également des frais mensuels liés à l'interconnexion, ainsi que des frais de transfert de données via l'interconnexion à un tarif inférieur au transfert via Internet.

Le partenaire applique des frais de services d'interconnexion en fonction de sa propre tarification. Pour connaître ces frais, vous pouvez consulter son site Web ou demander un devis auprès de son équipe commerciale. Habituellement, si tous les transferts de données se produisent dans la même région métropolitaine, les frais sont bien moins élevés que si les données devaient parcourir une grande distance sur un réseau partenaire.

Si vous transférez régulièrement des volumes des données suffisamment élevés, cette solution peut parfois être la plus abordable en raison des tarifs de sortie réduits, selon les tarifs des autres fournisseurs de services cloud. Même en incluant les coûts mensuels liés à l'interconnexion fournie par l'interconnexion partenaire, par l'autre fournisseur de services cloud et par le fournisseur de services partenaire, cette solution peut vous permettre de réaliser des économies considérables. Comme les tarifs des partenaires et des autres fournisseurs de services cloud peuvent changer sans préavis, comparez vous-même les prix en vous basant sur des devis actualisés de toutes les parties concernées.

Interconnexion dédiée via un point de présence commun

En utilisant un ou plusieurs appareils de routage physiques dans une installation d'interconnexion commune entre Google Cloud et l'autre fournisseur de services cloud, vous pouvez connecter les deux environnements cloud à l'aide de l'interconnexion dédiée côté Google Cloud et d'un produit équivalent du côté de l'autre fournisseur cloud. L'emplacement d'interconnexion ne doit pas nécessairement correspondre à l'emplacement de la région hébergeant vos ressources.

Le schéma suivant montre une configuration redondante qui utilise deux connexions Dedicated Interconnect :

Les routes sont échangées entre Cloud Router et la passerelle du côté de l'autre fournisseur de services cloud via un routeur physique que vous placez dans une installation d'interconnexion commune. Le trafic circule par ce routeur entre Google Cloud et l'autre fournisseur de services cloud.

Mise en œuvre

Cette solution implique l'hébergement et la gestion d'appareils de routage physiques dans une installation hébergée en colocation réunissant à la fois Google et le fournisseur cloud que vous souhaitez connecter. Depuis cet appareil de routage, vous commandez deux connexions physiques avec l'installation : une connexion vers Google Cloud via Dedicated Interconnect, et une connexion vers l'autre fournisseur de services cloud via un produit équivalent tel qu'AWS Direct Connect ou Azure ExpressRoute. Sur votre appareil de routage, vous devez configurer BGP pour permettre les échanges de routes entre les deux environnements cloud.

Consultez la liste des emplacements des installations hébergées en colocation fournie par Google Cloud et par votre autre fournisseur de services cloud, par exemple des emplacements AWS Direct Connect ou des emplacements d'appairage d'Azure ExpressRoute pour identifier les emplacements adaptés à cette configuration.

Les plages d'adresses IP entre vos réseaux virtuels ne doivent pas se chevaucher, sauf si votre appareil de routage physique est capable de traduire les adresses réseau entre les environnements, ou si vous limitez certains échanges de routes entre les environnements.

Cette solution est efficace si vous utilisez la connectivité dédiée non seulement pour vous connecter à un autre fournisseur de services cloud, mais aussi pour vous reconnecter à votre environnement sur site.

Pour d'autres scénarios, cette solution est complexe à mettre en œuvre, car elle exige l'obtention et la gestion d'un équipement physique, ainsi que la signature d'un contrat avec une installation hébergée en colocation. Nous ne recommandons cette solution que si vous répondez au moins à l'un des critères suivants :

• Vous possédez déjà du matériel dans une installation adaptée que vous utilisez à d'autres fins, et avez déjà conclu un contrat avec l'installation.
• Vous transférez régulièrement de grandes quantités de données et il s'agit donc pour vous d'une option économique, ou vous avez des besoins en bande passante que vos partenaires ne peuvent pas satisfaire.

Vitesse de transfert et latence

Cette solution fournit une capacité dédiée entre Google Cloud et l'autre fournisseur de services cloud. Du côté de Google Cloud, l'interconnexion dédiée est disponible avec une ou plusieurs connexions physiques de 10 ou 100 Gbit/s.

La latence pour cette solution correspond à la somme des éléments suivants :

• Latence entre la région hébergeant vos ressources sur Google Cloud et l'emplacement d'interconnexion depuis lequel vous établissez l'interconnexion avec Google Cloud.
• Latence via l'installation et votre équipement physique, qui est généralement négligeable par rapport à la latence liée à la longueur de la fibre.
• Latence depuis l'emplacement d'interconnexion via le réseau de l'autre fournisseur cloud jusqu'à la région hébergeant les ressources dans le fournisseur cloud.

Bien qu'aucune garantie de latence ne soit fournie, cette solution permet généralement d'obtenir la plus faible latence et les meilleures vitesses de transfert entre Google Cloud et d'autres environnements cloud via des adresses IP privées.

Sécurité

Le trafic sur Dedicated Interconnect n'est pas chiffré par défaut. Pour sécuriser votre trafic, vous pouvez déployer un VPN haute disponibilité sur Cloud Interconnect sur le côté Google Cloud de la connexion. Certains autres fournisseurs de services cloud vous permettent d'exploiter leur service VPN géré sur une interconnexion. Par exemple, AWS Site-to-Site VPN peut être utilisé sur AWS Direct Interconnect. Vous pouvez également employer un dispositif virtuel chiffrant le trafic du côté de l'autre fournisseur de services cloud.

Une autre option consiste à chiffrer votre trafic au niveau de la couche d'application plutôt que d'utiliser un VPN.

Fiabilité et contrat de niveau de service

Lorsque vous utilisez Dedicated Interconnect de manière redondante, Google fournit des contrats de niveau de service garantissant une disponibilité mensuelle de 99,9 à 99,99 % en fonction de la topologie choisie. Les connexions qui n'exploitent qu'une connexion Dedicated Interconnect ne sont pas couvertes par un contrat de niveau de service.

Consultez la documentation de l'autre fournisseur de services cloud pour connaître le contrat de niveau de service qui s'applique à son produit d'interconnexion. Reportez-vous par exemple au contrat de niveau de service d'AWS Direct Connect ou au SLA pour ExpressRoute d'Azure.

L'installation hébergée en colocation ou le fournisseur de l'équipement de routage physique peut également proposer des contrats de niveau de service sur ses services.

Tarifs

Du côté de Google Cloud, des frais mensuels sont facturés pour chaque port Dedicated Interconnect, ainsi que pour chaque rattachement de VLAN connecté à un environnement VPC. Le trafic sortant via Dedicated Interconnect est facturé à un tarif inférieur au trafic Internet. Pour en savoir plus, consultez les tarifs de Dedicated Interconnect.

Consultez la page de tarification de l'autre fournisseur de services cloud pour connaître les tarifs de son produit d'interconnexion. Reportez-vous par exemple à la tarification d'AWS Direct Connect ou à la tarification d'Azure ExpressRoute. En règle générale, le modèle de tarification inclut également des frais mensuels liés à l'interconnexion, ainsi que des frais de transfert de données via l'interconnexion à un tarif inférieur au transfert via Internet.

En outre, vous devez tenir compte des frais liés aux services de l'installation hébergée en colocation fournissant l'espace, l'alimentation électrique et les connexions physiques vers les environnements cloud, ainsi que des coûts et des contrats de service en cours avec le fournisseur de l'équipement de routage physique. Si la connexion entre les deux fournisseurs de services cloud ne peut pas être mise en place dans une même installation et que vous devez établir une connectivité entre plusieurs installations, le coût de ces services peut se révéler considérablement plus élevé.

Connexions gérées Cross-Cloud Interconnect

Vous pouvez connecter vos réseaux VPC Google Cloud à vos réseaux virtuels auprès d'un autre fournisseur de services cloud via la structure réseau de Google. En un sens, cette configuration fonctionne comme une interconnexion partenaire, mais le contrat de niveau de service Google couvre les réseaux Google et les interconnexions elles-mêmes.

Le schéma suivant illustre une configuration Cross-Cloud Interconnect avec le nombre minimal de connexions.

Les routes sont échangées entre Cloud Router et la passerelle du côté de l'autre fournisseur de services cloud sur la structure réseau de Google. Le trafic circule par cette structure entre Google Cloud et l'autre fournisseur de services cloud.

Implémentation

Lorsque vous achetez une interconnexion Cross-Cloud Interconnect, Google provisionne une connexion physique dédiée entre le réseau Google et celui d'un autre fournisseur de services cloud. Vous pouvez utiliser cette connexion pour appairer votre réseau cloud privé virtuel (VPC) Google Cloud à un réseau qui est hébergé par un fournisseur de services cloud compatible.

Une fois que vous avez provisionné la connexion, Google la gère jusqu'à ce qu'elle atteigne le réseau de l'autre fournisseur de services cloud. Google ne garantit pas le temps d'activité de l'autre fournisseur de services cloud. Toutefois, Google reste le point de contact principal pour le service complet et vous avertit si vous devez ouvrir une demande d'assistance auprès de l'autre fournisseur de services cloud.

Cette solution nécessite de suivre le processus de configuration de l'autre fournisseur de services cloud, y compris le choix de l'emplacement de l'interconnexion des deux réseaux. Seuls certains fournisseurs de services cloud sont acceptés.

Vitesse de transfert et latence

Cette solution fournit une capacité dédiée entre Google Cloud et l'autre fournisseur de services cloud. Du côté de Google Cloud, l'interconnexion dédiée est disponible avec une ou plusieurs paires de connexions physiques de 10 Gbit/s ou 100 Gbit/s.

La latence pour cette solution correspond à la somme des éléments suivants :

• Latence entre la région hébergeant vos ressources sur Google Cloud et l'emplacement cross-cloud.
• Latence entre l'emplacement périphérique de Google et l'emplacement périphérique de l'autre fournisseur de services cloud (souvent dans la même installation).
• Latence entre l'emplacement périphérique de l'autre fournisseur de services cloud où Cross-Cloud Interconnect est déployé et la région où les ressources sont hébergées dans le fournisseur de services cloud.

Bien qu'aucune garantie de latence ne soit fournie, cette solution permet généralement d'obtenir la plus faible latence possible et les meilleures vitesses de transfert possibles entre Google Cloud et d'autres environnements cloud via des adresses IP privées.

Sécurité

Comme le trafic sur Cross-Cloud Interconnect n'est pas chiffré, nous vous recommandons de chiffrer le trafic sensible au niveau de la couche d'application.

Si tout le trafic doit être chiffré, les dispositifs virtuels disponibles auprès des partenaires Google Cloud dans Cloud Marketplace peuvent fournir des solutions pour chiffrer le trafic vers l'environnement de l'autre fournisseur de services cloud.

Fiabilité et contrat de niveau de service

Cross-Cloud Interconnect utilise le contrat de niveau de service de Cloud Interconnect. Pour être éligible au contrat de niveau de service, votre configuration Cross-Cloud Interconnect doit utiliser une ou plusieurs paires de connexions, comme décrit dans la section Contrat de niveau de service de la présentation de Cross-Cloud Interconnect

Le contrat de niveau de service couvre tous les éléments côté Google jusqu'à la périphérie du réseau de l'autre fournisseur cloud. Il ne couvre pas le réseau de l'autre fournisseur de services cloud. Pour en savoir plus, consultez la documentation de l'autre fournisseur de services cloud pour connaître le contrat de niveau de service qui s'applique à son produit d'interconnexion. Reportez-vous par exemple au contrat de niveau de service d'AWS Direct Connect ou au contrat de niveau de service d'Azure pour ExpressRoute.

Tarifs

Un tarif horaire est facturé pour chaque connexion Cross-Cloud Interconnect, ainsi que pour chaque rattachement de VLAN connecté à un environnement VPC. Le trafic sortant via Cross-Cloud Interconnect est facturé à un tarif inférieur à celui du trafic Internet. Pour en savoir plus, consultez la section sur les tarifs de Cross-Cloud Interconnect.

Consultez la page de tarification de l'autre fournisseur de services cloud pour connaître les tarifs de son produit d'interconnexion. Reportez-vous par exemple à la tarification d'AWS Direct Connect ou à la tarification d'Azure ExpressRoute. Généralement, des frais mensuels sont facturés pour l'interconnexion. Les frais de transfert de données via l'interconnexion sont généralement inférieurs à ceux des transferts de données via Internet.

Il n'y a pas de coûts distincts pour les emplacements ou l'équipement d'interconnexion.

Comparatif des solutions

Les solutions présentées varient en termes de vitesse, de disponibilité, de complexité, de sécurité et de tarification. Vous devez évaluer toutes les options de manière approfondie en fonction de vos besoins.

Le schéma suivant vous aide à choisir l'une des solutions mentionnées dans ce document à l'aide d'un organigramme.

En règle générale, nous recommandons les choix suivants :

• Pour de nombreux scénarios dans lesquels vous n'échangez des données qu'occasionnellement ou en faible quantité et dans lesquels les transferts ne sont pas critiques, l'option la plus simple consiste à transférer les données via Internet. Cette solution fournit à la fois une latence relativement faible et un haut débit.
• Si vous avez besoin de chiffrer ou de transférer de petites quantités de données à l'aide d'adresses IP privées, envisagez d'utiliser Cloud VPN ainsi qu'un service VPN géré du côté de l'autre fournisseur de services cloud.
• Si vous transférez de plus grandes quantités de données, l'utilisation de Partner Interconnect avec un partenaire offrant des solutions multicloud présente plusieurs avantages : capacité dédiée, coût du transfert de données réduit et, en fonction de la topologie, un contrat de niveau de service pour chaque composant de la solution. La capacité de Partner Interconnect est généralement inférieure à 10 Gbit/s par connexion.
• Si vous connectez votre équipement sur site à plusieurs clouds, l'utilisation de Dedicated Interconnect via un POP commun est une option courante. Elle implique néanmoins une complexité accrue liée à la gestion de votre propre matériel et à l'établissement de relations avec une installation hébergée en colocation. À moins que vous n'ayez déjà l'infrastructure en place, cette solution est réservée aux scénarios dans lesquels vous avez besoin d'un taux de transfert de données de 10 Gbit/s ou plus.
• Si vous ne souhaitez pas avoir à gérer de connexions croisées ni d'équipements de routage dans des POP distants, Cross-Cloud Interconnect fournit une solution gérée dans laquelle Google s'en charge à votre place.

Étapes suivantes

• Consultez la série sur les modèles et pratiques hybrides et multicloud.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.