AWS & Google Cloud : CCI GA – Architectes à décider

Après cinq mois de phase de prévisualisation, le Partner Cross-Cloud Interconnect pour AWS avec le VPC Network Peering dans Google Cloud est désormais 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 dans la chaîne. 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 pour les 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.

En lienFinOps : évaluation de la maturité en 2026  /  Platform Engineering en 2026 : Backstage et Golden Paths pour les DSI

Ce qu’est la disponibilité générale, ce qui reste en préversion 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 co-construit par Google Cloud et AWS, où une passerelle AWS Direct Connect est connectée directement à un VPC GCP via un routeur partenaire certifié. Le trafic ne transite pas par l’internet public et ne nécessite aucun contrat de colocation propre auprès d’un opérateur d’échange. Depuis le 16.04.2026, la variante avec le peering de réseau VPC dans Google Cloud est en disponibilité générale (GA), tandis que l’intégration avec Network Connectivity Center reste en préversion.

L’annonce du 01.12.2025 avait valeur de signal. La mise en production le 16.04.2026 en est la concrétisation opérationnelle. Ce que Google Cloud a officiellement élevé au statut de GA dans ses notes de version, c’est Partner Cross-Cloud Interconnect pour AWS avec le peering de réseau VPC. Concrètement, cela signifie qu’une passerelle AWS Direct Connect dans votre propre compte peut désormais être connectée directement à un VPC GCP via un nœud réseau partenaire certifié par Google, sans que le trafic n’emprunte le chemin de l’internet public ni qu’un contrat de colocation auprès d’un opérateur d’échange soit nécessaire.

Ce qui reste délibérément en dehors de la GA, c’est l’intégration avec Google Cloud Network Connectivity Center (NCC). NCC est le service qui permet à Google de mettre en place une topologie hub-and-spoke à travers plusieurs clouds, sites et frontières de VPC. La variante « spoke » de Partner Cross-Cloud Interconnect pour NCC demeure en préversion. Pour les équipes qui souhaitent exploiter une couche de routage multi-cloud centralisée, 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 concerne la spécification ouverte d’interopérabilité réseau. En décembre 2025, AWS et Google ont présenté conjointement une architecture conçue non pas comme un protocole d’interconnexion propriétaire, mais comme un modèle de référence. Microsoft Azure a été explicitement cité comme candidat à l’adhésion pour 2026. À ce jour, Microsoft n’a pas communiqué de feuille de route concrète. Pour les équipes d’architectes, cela signifie que l’option deux clouds est désormais opérationnelle, tandis que l’option trois clouds reste une planification stratégique.

Pourquoi le calcul du coût du réseau multi-cloud change désormais

L’obstacle traditionnel aux déploiements multi-cloud en production ne résidait pas dans les décisions d’architecture, mais bien dans les coûts de transfert de données entre les hyperscalers. AWS Egress vers Google, Google Egress vers AWS : selon la région, ces frais oscillent entre environ 0,07 et 0,10 d’euros par Go. Pour des volumes d’entreprise atteignant plusieurs pétaoctets par mois, ces coûts s’accumulent rapidement pour former des postes budgétaires significatifs. Le service Partner Cross-Cloud Interconnect modifie radicalement cette équation tarifaire. Le trafic basé sur Direct Connect bénéficie désormais de tarifs de sortie réduits, généralement compris entre environ 0,02 et 0,04 d’euros par Go, selon la région et le volume engagé. Pour un workload sérieux entre AWS Analytics et Google BigQuery, cela peut se traduire par une division par deux des dépenses opérationnelles réseau (OpEx).

La latence constitue le deuxième levier qui évolue. Un trajet AWS vers GCP via l’Internet public affiche, selon la région, un temps d’aller-retour (round-trip) compris entre 12 et 40 millisecondes. Avec Partner Cross-Cloud Interconnect, ce délai chute à 2-8 millisecondes, car les paquets transitent 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 – cette amélioration ouvre la porte à des architectures auparavant difficiles à opérer.

Troisième point clé : la souveraineté des données. 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 (l’Autorité fédérale de supervision financière allemande) doivent disposer de voies de sortie vérifiables, tandis que le Data Act de l’UE exige une portabilité documentée. 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. L’existence même d’une interconnexion native entre AWS et Google devient ainsi un argument en matière de conformité, là où ce rôle revenait auparavant à des solutions tierces.

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 bénéficieront pas immédiatement. Toutes les équipes d’architecture n’ont pas la capacité de planifier une réévaluation. Au cours des deux dernières semaines, les échanges avec des architectes du DACH (Allemagne, Autriche, Suisse) ont fait émerger cinq moments décisionnels concrets 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 tiers. Ceux qui utilisent aujourd’hui Megaport, Equinix Fabric ou PCCW Console Connect pour interconnecter AWS et GCP en production devraient programmer une comparaison technique des coûts au deuxième trimestre. La couche 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. Concrètement, pour les comités d’architecture, cela signifie que chaque nouveau projet multi-cloud commence par la question suivante : Partner Cross-Cloud Interconnect répond-il aux exigences ? Ce n’est qu’ensuite que l’option 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 données analytiques. 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 (egress) au quatrième trimestre 2025, bénéficient d’une nouvelle base de référence. 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 troisième décision concerne les topologies de reprise après sinistre (Disaster Recovery, DR). Jusqu’en 2025, le DR 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 financièrement réaliste. Les équipes disposant de configurations DR mono-cloud existantes devraient au moins esquisser une architecture montrant à quoi ressemblerait un DR cross-cloud avec les nouvelles hypothèses de coûts. Ce résultat doit être intégré à la prochaine évaluation des risques.

La quatrième décision concerne les charges de travail d’IA et de ML (Machine Learning). Google Cloud a misé ces derniers trimestres sur les TPU v6 et du matériel d’inférence spécialisé, tandis qu’AWS a développé Trainium2 et ses propres intégrations Bedrock. Pour les équipes travaillant sur les deux stacks, la question du réseau n’est pas anodine : les modèles sont entraînés sur GCP, mais l’inférence s’exécute en périphérie sur AWS. L’interconnexion native réduit les coûts de déplacement des données au point que de telles architectures divisées passent de la zone de faisabilité à la zone par défaut. Pour les équipes en charge des plateformes ML, il s’agit du changement le plus important des douze derniers mois, car auparavant, la séparation entre stack d’entraînement et stack d’inférence achoppait sur la facturation réseau, et non sur l’idée architecturale elle-même.

La cinquième décision concerne la gouvernance. Dans de nombreux contextes d’entreprise en Allemagne, la connectivité cross-cloud était 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 des hyperscalers, l’effort de documentation diminue sensiblement. Ceux qui ont déjà formalisé une stratégie multi-cloud dans une politique devraient mettre à jour les passages relatifs à la gouvernance en mai. Pour la révision interne, cela signifie qu’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. Désormais, il en existe 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 mesurables diminuent. Ce n’est pas un argument qui prend effet dès le premier jour suivant la disponibilité générale (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 du DR peut prendre un trimestre entier. Le pari d’AWS et Google avec la GA du 16 avril n’est pas l’adoption en quatre semaines, mais le déplacement des hypothèses par défaut sur 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 services financiers et de conformité au plus tard à l’automne.

Questions fréquentes

Plus d’articles du réseau média MBF

Source de l’image : générée par IA (Juli 2026)