AWS et Google Cloud : l’interconnexion multi-cloud est désormais disponible – les décisions urgentes des architectes d’entreprise

7 min de lecture · Mise à jour : 21.04.2026

Après cinq mois de preview, le Partner Cross-Cloud Interconnect pour AWS avec le VPC Network Peering dans Google Cloud est Generally Available depuis le 16.04.2026. Pour les architectes d’entreprise, cela signifie que le premier chemin multi-cloud construit nativement par deux hyperscalers est désormais utilisable en production, sans qu’un tiers comme Megaport ou Equinix ne s’interpose. Cela ne change pas la question fondamentale de savoir pourquoi les entreprises adoptent le multi-cloud. En revanche, cela modifie les coûts d’exécution des deux prochains trimestres, car le transfert de données, la latence et les chemins de souveraineté peuvent désormais être calculés différemment qu’au quatrième trimestre 2025.

À lire aussiFinOps : évaluation de la maturité 2026  /  Platform Engineering 2026 avec Backstage et Golden Paths

Ce qu’est GA, ce qui reste en Preview et comment Azure se prépare en coulisses

Qu’est-ce que Partner Cross-Cloud Interconnect ? Partner Cross-Cloud Interconnect est un chemin réseau construit conjointement par Google Cloud et AWS, où une passerelle AWS Direct Connect est directement connectée à un VPC GCP via un routeur partenaire certifié. Le trafic ne transite pas par l’Internet public et ne nécessite pas de contrat de colocation propre auprès d’un opérateur d’échange. Depuis le 16.04.2026, la variante avec VPC Network Peering dans Google Cloud est GA, tandis que l’intégration avec Network Connectivity Center reste en Preview.

L’annonce du 01.12.2025 était un signal. La mise en disponibilité générale le 16.04.2026 en est la réalité opérationnelle. Ce que Google Cloud a concrètement élevé au statut GA dans les Release Notes, c’est Partner Cross-Cloud Interconnect pour AWS avec VPC Network Peering. Concrètement, cela signifie qu’une passerelle AWS Direct Connect dans votre propre compte peut désormais être directement connectée à un VPC GCP via un nœud réseau partenaire certifié par Google, sans que le trafic ne passe par le chemin Internet public ni qu’un contrat de colocation propre auprès d’un opérateur d’échange soit nécessaire.

Ce qui n’est délibérément pas encore GA, c’est l’intégration avec Google Cloud Network Connectivity Center. NCC est le service qui permet à Google de représenter une topologie hub-and-spoke à travers plusieurs clouds, sites et frontières de VPC. La variante Spoke de NCC pour Partner Cross-Cloud Interconnect reste en Preview. Pour les équipes qui souhaitent exploiter un plan de routage multicloud centralisé, cela signifie qu’une utilisation en production n’est réaliste qu’à partir du troisième trimestre 2026, plus probablement avec la vague de GA de l’automne.

Le troisième niveau est la spécification ouverte d’interopérabilité réseau. AWS et Google ont présenté conjointement en décembre 2025 une architecture qui n’est pas conçue comme un protocole d’interconnexion propriétaire, mais comme un blueprint. Microsoft Azure a été explicitement mentionné comme candidat à l’adhésion pour 2026. Microsoft n’a jusqu’à présent publié aucune donnée concrète sur sa feuille de route. Pour les équipes d’architecture, cela signifie que l’option deux clouds est désormais productive, tandis que l’option trois clouds reste une planification stratégique.

Pourquoi le calcul du multi-cloud networking change désormais

L’obstacle classique aux configurations multi-cloud productives ne résidait pas dans les décisions d’architecture, mais dans les coûts de transfert de données entre les hyperscalers. AWS Egress vers Google, Google Egress vers AWS : selon la région, cela varie entre 0,08 et 0,12 USD par Go. Pour des volumes d’entreprise atteignant plusieurs pétaoctets par mois, ces frais s’accumulent rapidement en postes significatifs. Le Cross-Cloud Interconnect des partenaires modifie structurellement cette facturation. Le trafic basé sur Direct Connect bénéficie de tarifs de sortie réduits, généralement compris entre 0,02 et 0,05 USD par Go selon la région et le volume engagé. Pour un workload de données sérieux entre AWS Analytics et Google BigQuery, cela peut signifier une réduction de moitié des coûts opérationnels réseau.

La latence constitue le deuxième levier qui évolue. Un trajet AWS vers GCP via l’internet public affiche, selon la région, entre 12 et 40 millisecondes en aller-retour. Avec le Partner Cross-Cloud Interconnect, ce délai chute à 2-8 millisecondes, car les paquets circulent directement entre les routeurs d’interconnexion. Pour les couplages sensibles à la latence, par exemple entre des systèmes transactionnels basés sur AWS et des pipelines d’analytics sur Google, cela ouvre la porte à des architectures auparavant difficiles à opérer.

Le troisième point concerne la souveraineté. Les entreprises allemandes et européennes adoptent souvent le multi-cloud non pas pour des raisons architecturales, mais pour des motifs contractuels et de conformité. Les institutions régulées par la BaFin ont besoin de voies de sortie vérifiables, tandis que le Data Act européen exige une portabilité documentée. Le Partner Cross-Cloud Interconnect simplifie cette documentation, car le chemin réseau entre les clouds est clairement défini contractuellement et apparaît dans la piste d’audit des deux hyperscalers. La simple existence d’une interconnexion native entre AWS et Google devient ainsi un argument en matière de conformité, là où une solution tierce était auparavant nécessaire.

Cinq décisions que les architectes d’entreprise doivent prendre cette semaine

Cette annonce n’est pas à prendre à la légère. Toutes les architectures d’entreprise n’en profiteront pas immédiatement. Toutes les équipes d’architecture n’ont pas la capacité de planifier une réévaluation. D’après les échanges avec des architectes DACH ces deux dernières semaines, cinq moments décisionnels concrets se dégagent, où Partner Cross-Cloud Interconnect modifie le modèle de calcul.

La première décision concerne les configurations multi-cloud existantes avec un chemin via un tiers. Ceux qui utilisent aujourd’hui Megaport, Equinix Fabric ou PCCW Console Connect entre AWS et GCP en production devraient prévoir une comparaison technique des coûts au deuxième trimestre. La couche fournisseur tiers reste souvent pertinente pour des raisons organisationnelles (contrats existants, processus de support établis), mais l’hypothèse par défaut s’inverse. Pour les nouvelles installations, le chemin natif devient l’option par défaut. Pour les comités d’architecture, cela signifie concrètement : chaque nouveau projet multi-cloud commence par la question de savoir si Partner Cross-Cloud Interconnect répond aux exigences. Ce n’est qu’ensuite que l’option fournisseur tiers entre en jeu, en tant que variante complémentaire ou de remplacement, selon le contexte réglementaire et opérationnel du projet.

La deuxième décision concerne les migrations prévues de Data Analytics. Les équipes qui planifient actuellement un passage d’AWS Redshift à Google BigQuery, ou inversement, peuvent désormais calculer la composante réseau avec des chiffres fiables. Les modèles de coûts dans les business cases, qui devaient encore travailler avec des hypothèses conservatrices de sortie au quatrième trimestre 2025, obtiennent une nouvelle baseline. Pour la décision d’approbation dans deux ou trois semaines, cela peut améliorer significativement le retour sur investissement. Cela devient particulièrement pertinent si l’équipe de migration considérait jusqu’à présent le poste réseau comme une friction fixe. Dès que ce chiffre devient variable, des scénarios auparavant mis de côté pour des raisons de coûts de sortie reviennent sur le devant de la scène.

« La partie intéressante n’est pas la réduction des coûts de sortie, mais ce qu’elle rend possible ensuite. Lorsque le trafic cross-cloud ne pèse plus financièrement, des architectures auparavant évitées pour de bonnes raisons deviennent réalisables. » Lee Sustar, Forrester, dans le contexte de la conférence de presse Kyndryl, avril 2026

La troisième décision concerne les topologies de reprise après sinistre. Jusqu’en 2025, la reprise cross-cloud était l’une des variantes les plus coûteuses, car le chemin de reprise passait généralement par une sortie publique. Avec l’interconnexion native, une configuration active-active entre une région AWS et une région Google devient réaliste sur le plan calculatoire. Les équipes disposant de configurations DR mono-cloud existantes devraient au moins esquisser une architecture montrant à quoi ressemblerait une DR cross-cloud avec les nouvelles hypothèses de coûts. Le résultat doit être intégré à la prochaine évaluation des risques.

La quatrième décision concerne les workloads d’IA et de ML. Google Cloud a misé ces derniers trimestres sur les TPU v6 et le matériel d’inférence spécialisé, tandis qu’AWS a misé sur Trainium2 et ses propres intégrations Bedrock. Pour les équipes travaillant sur les deux stacks, la question du réseau n’est pas triviale : les modèles s’entraînent sur GCP, l’inférence s’exécute sur le edge AWS. L’interconnexion native réduit les coûts de déplacement des données au point que de telles architectures split passent de la zone de faisabilité à la zone par défaut. Pour les équipes de plateformes ML, c’est le changement le plus important des douze derniers mois, car le split entre stack d’entraînement et stack d’inférence échouait auparavant à cause de la facturation réseau, et non à cause de l’idée architecturale elle-même.

La cinquième décision concerne l’aspect gouvernance. La connectivité cross-cloud était, dans de nombreux contextes d’entreprise allemands, le point où gouvernance et sécurité réseau disaient conjointement non, car le flux de trafic entre les domaines cloud était difficile à documenter. Avec un chemin natif apparaissant dans les deux consoles d’hyperscalers, l’effort de documentation diminue sensiblement. Ceux qui ont déjà formalisé une stratégie multi-cloud dans une politique devraient actualiser les passages relatifs à la gouvernance en mai. Pour la révision interne, cela signifie : un chemin multi-cloud apparaissant dans les deux pistes d’audit est vérifiable, tandis qu’un chemin passant par un tiers nécessite des preuves supplémentaires. Cette distinction avait peu de poids dans les discussions sur la gouvernance jusqu’à présent, faute d’alternative. Maintenant, il y en a une.

Parallèlement à ces cinq décisions, une sixième réflexion, moins opérationnelle et plus stratégique, subsiste : comment évolue la position de négociation face aux hyperscalers lorsque le passage entre AWS et GCP devient techniquement plus simple ? Les acheteurs d’entreprise qui renégocient leurs contrats cloud dans les douze prochains mois disposent d’un argument supplémentaire dans les discussions tarifaires, car les coûts de sortie diminuent de manière mesurable. Ce n’est pas un argument qui prend effet dès le premier jour après la GA, mais il deviendra visible lors du prochain cycle de renouvellement contractuel.

Ce que toutes ces décisions ont en commun : ce ne sont pas des sujets à traiter en un seul sprint. Un recalcul des coûts de sortie sur deux comptes cloud prend généralement deux à trois semaines, car il faut consolider la télémétrie des deux côtés. Une réévaluation de la DR peut prendre un trimestre entier. Le pari que font AWS et Google avec la GA du 16 avril n’est pas une adoption en quatre semaines, mais un déplacement des hypothèses par défaut dans deux à trois trimestres. Pour les équipes d’architecture qui travaillent de manière planifiée, c’est le bon moment pour examiner leurs propres hypothèses. Pour celles qui agissent de manière réactive, la pression viendra des côtés finance et conformité au plus tard à l’automne.

Questions fréquentes

Qu’est-ce qui est devenu GA le 16 avril 2026 exactement ?

Le Partner Cross-Cloud Interconnect pour AWS avec le VPC Network Peering dans Google Cloud. Il s’agit du chemin via un routeur partenaire certifié d’une passerelle AWS Direct Connect vers un VPC GCP. L’intégration avec Google Network Connectivity Center (NCC) en tant que Spoke reste en Preview. Pour les scénarios à deux clouds AWS-GCP, la GA est utilisable en production. Pour les architectures Hub-and-Spoke sur plusieurs clouds, une mise en œuvre est prévue au plus tôt au troisième trimestre 2026.

Quelle réduction des coûts est réaliste ?

Pour un transfert de données pur entre AWS et GCP, une division par deux des coûts d’Egress est typique, selon la région et le volume d’engagement. L’Egress via Internet public se situe entre 0,08 et 0,12 USD par Go, tandis que l’Egress via Direct Connect est réduit à 0,02 à 0,05 USD par Go. L’économie réelle dépend du profil de trafic. L’effet de levier est plus important pour les charges analytiques en rafales, et moindre pour les connexions de streaming continues.

Megaport ou Equinix restent-ils pertinents en tant que tiers fournisseurs ?

Oui, pour les configurations Multi-Cloud couvrant plus qu’AWS et GCP. Pour les liaisons AWS-GCP pures, l’Interconnect natif devient l’option par défaut pour les nouvelles installations. Les contrats existants avec Megaport ou Equinix, incluant une intégration de support en cours, restent souvent pertinents, car un changement génère un travail opérationnel. Il convient toutefois de réévaluer le calcul de comparaison des coûts.

Quand Microsoft Azure suivra-t-il ?

Microsoft a été explicitement cité comme candidat à l’adhésion à la spécification ouverte d’interopérabilité réseau dans l’annonce conjointe AWS-Google du 1er décembre 2025. Microsoft n’a jusqu’à présent communiqué aucune date concrète sur sa feuille de route. Pour les architectures à trois clouds avec un chemin natif inter-hyperscalers, la planification stratégique est le bon format, et non l’implémentation en production.

Qu’est-ce qui change concrètement pour les équipes conformité DACH ?

Le chemin réseau entre AWS et GCP est désormais documentable de manière claire dans les journaux d’audit des deux hyperscalers, sans qu’un contrat avec un tiers fournisseur doive être intégré séparément dans la collecte des preuves. Cela simplifie la démonstration de conformité pour les audits BaFin, les preuves de résilience DORA ou les exigences de portabilité du Data Act européen. Si vous avez déjà rédigé une politique Multi-Cloud, il est conseillé de mettre à jour les passages relatifs au réseau d’ici mai.

Plus d’actualités du réseau MBF Media

Source image de titre : Pexels / Brett Sayles (px:4330787)