AWS et Google Cloud rendent le multicloud réel : ce que change l’accord d’interconnexion

Deux rivaux construisent un pont

Pendant une décennie, les trois grands fournisseurs cloud se sont concurrencés sur le verrouillage. Le réseau propriétaire, les API spécifiques et les frais de sortie punitifs maintenaient les charges de travail captives. Les entreprises qui voulaient exécuter des services sur AWS et Google Cloud devaient faire passer le trafic par des réseaux tiers, négocier des accords de colocation séparés et attendre des semaines pour le provisionnement des circuits.

Cela a changé fin 2025 quand AWS a dévoilé AWS Interconnect — multicloud lors de re:Invent, avec Google Cloud comme partenaire de lancement. Google a simultanément étendu son Cross-Cloud Interconnect pour supporter la même fonctionnalité de son côté. Le résultat : un lien réseau géré, privé et haut débit entre un Amazon VPC et un Google Cloud VPC que l’une ou l’autre partie peut provisionner en minutes via sa propre console.

Le service est entré en preview publique sur cinq paires de régions — US East (N. Virginia), US West (N. California), US West (Oregon), Europe (London) et Europe (Frankfurt) — chacune associée à une région Google Cloud correspondante. Pendant la preview, les clients peuvent créer une connexion de 1 Gbps par compte sans frais, avec une bande passante attendue allant jusqu’à 100 Gbps en disponibilité générale.

Ce qui rend cela plus qu’une fonctionnalité réseau est la spécification ouverte. AWS et Google ont publié l’API Connection Coordinator comme spécification OpenAPI 3.0 dans un dépôt GitHub public, invitant explicitement d’autres fournisseurs et partenaires à l’adopter. Microsoft Azure devrait rejoindre au second semestre 2026, transformant un accord bilatéral en standard industriel émergent.

Pourquoi maintenant — et pourquoi c’est important

Le timing n’est pas accidentel. Trois forces ont poussé les hyperscalers vers la collaboration.

Pression réglementaire. Le Data Act de l’UE, entré pleinement en vigueur fin 2025, exige des fournisseurs cloud qu’ils éliminent les barrières de changement et supportent l’interopérabilité. Google avait déjà supprimé les frais de sortie pour les clients qui migrent, et AWS a suivi. Construire une interconnexion native est l’étape logique suivante — cela signale la conformité et prévient toute action réglementaire supplémentaire.

Demande des entreprises. Selon le rapport Flexera State of the Cloud 2026, 89 % des organisations d’entreprise utilisent désormais une stratégie multicloud, la prévention du verrouillage fournisseur se classant systématiquement parmi les principales motivations — citée comme facteur principal par 42 % des répondants, et comme facteur contributif par jusqu’à 68 % dans les enquêtes plus larges. Pourtant la plupart des déploiements multicloud sont accidentels — différentes équipes choisissant différents fournisseurs — et non architecturés. Une interconnexion gérée donne aux entreprises un moyen de faire du multicloud intentionnel sans doctorat en réseau.

Distribution des charges de travail IA. À mesure que les entreprises déploient des pipelines d’inférence, des systèmes de génération augmentée par récupération et des tâches de fine-tuning, elles ont de plus en plus besoin de placer les charges de travail là où l’inventaire GPU, la tarification ou les services spécialisés adéquats existent. Un lien cross-cloud privé rend possible de diviser un pipeline entre fournisseurs sans faire transiter des données sensibles sur l’internet public.

Comment ça fonctionne sous le capot

L’architecture est délibérément simple. Côté AWS, un client crée une connexion Interconnect multicloud en spécifiant le fournisseur cible (Google Cloud), la région de destination et la bande passante souhaitée. AWS provisionne un circuit dédié sur son backbone vers un point de présence partagé avec Google Cloud. Le Cross-Cloud Interconnect de Google complète le lien de son côté. Le trafic ne touche jamais l’internet public.

Les deux côtés s’intègrent avec les constructions réseau existantes. Côté AWS, la connexion se branche sur Transit Gateway ou Cloud WAN. Côté Google Cloud, elle s’attache à un Cloud Router via un attachement VLAN. Les clients gèrent le routage, les groupes de sécurité et les règles de pare-feu exactement comme pour n’importe quel peering VPC — pas de nouvelles abstractions à apprendre.

L’API ouverte Connection Coordinator gère la poignée de main entre fournisseurs. Elle définit comment un cloud demande une connexion, comment le pair la confirme, comment la bande passante est allouée et comment le lien est démonté. Parce que la spécification est publique, des fournisseurs de réseau-as-a-service tiers comme Megaport ou Equinix pourraient l’implémenter pour offrir des chemins de transport alternatifs.

Ce que cela signifie pour le verrouillage fournisseur

Il serait naïf de déclarer la mort du verrouillage fournisseur. L’interconnexion résout la couche réseau — elle ne porte pas vos tables DynamoDB vers Bigtable et ne traduit pas les fonctions Lambda en Cloud Functions. Les services managés propriétaires restent la source la plus profonde de verrouillage, et ni AWS ni Google n’ont intérêt à les commoditiser.

Ce qui change, c’est le coût de l’optionalité. Avant, même évaluer un second cloud nécessitait des mois de mise en place réseau. Maintenant, une entreprise peut démarrer un lien cross-cloud en minutes pendant la preview et tester si diviser une charge de travail entre fournisseurs apporte de vrais gains. La friction de l’expérimentation tombe à presque zéro.

Cela compte pour plusieurs scénarios stratégiques :

• Piles IA best-of-breed. Une entreprise pourrait entraîner des modèles sur les pods TPU de Google Cloud et servir l’inférence sur AWS Inferentia — et le lien cross-cloud rend le pipeline de données entre eux privé et rapide.
• Résidence des données pour conformité. Quand une région ou un fournisseur spécifique dispose des certifications de conformité requises, l’interconnexion permet aux entreprises de placer les données où la réglementation l’exige tout en gardant la couche applicative sur leur cloud principal.
• Reprise après sinistre sans duplication. La DR active-passive entre deux clouds devient architecturalement plus propre quand les fournisseurs offrent un lien privé géré plutôt qu’un VPN sur l’internet public.

La question des prix que personne ne peut encore résoudre

Le détail le plus important manque encore : la tarification en disponibilité générale. Pendant la preview, la connexion 1 Gbps est gratuite. Mais les architectures multicloud d’entreprise nécessiteront 10-100 Gbps de bande passante soutenue, et les frais de transfert de données par Go des deux côtés détermineront si c’est véritablement transformateur ou simplement un projet scientifique bien commercialisé.

Pour contexte, le transfert de données cross-cloud coûte aujourd’hui entre 0,01 $ et 0,09 $ par Go selon le fournisseur et la région. Les organisations rapportent systématiquement que les coûts d’intégration et de transfert de données représentent une part significative de leurs dépenses cloud totales, rivalisant souvent avec les coûts principaux de calcul et de stockage. Si l’interconnexion gérée porte une prime par rapport aux options de fabric tiers existantes, les grandes entreprises pourraient rester avec Megaport, Equinix ou PacketFabric pour l’avantage de coût.

La question des frais de sortie n’est pas non plus résolue. Google a supprimé les frais de sortie pour le changement sous la pression du Data Act de l’UE, mais les frais de transfert de données opérationnelles persistent. Si le trafic d’interconnexion bénéficie de tarifs de sortie réduits — et à quel point — façonnera l’adoption plus que toute fonctionnalité technique.

Azure rejoint ensuite — et après ?

Microsoft Azure devrait s’intégrer avec AWS Interconnect au second semestre 2026, ce qui compléterait le triangle des trois grands. Une fois que les trois hyperscalers supporteront la même API ouverte Connection Coordinator, la couche réseau du multicloud deviendra un problème résolu — du moins en théorie.

Le vrai test sera de savoir si la spécification ouverte attire une participation au-delà des trois grands. Oracle Cloud Infrastructure, Alibaba Cloud et les fournisseurs régionaux pourraient l’adopter pour se connecter au même fabric. S’ils le font, la spécification devient un véritable standard d’interopérabilité. S’ils ne le font pas, elle reste une commodité bilatérale entre les acteurs dominants.

Pour les architectes d’entreprise, le calcul stratégique évolue. La question n’est plus de savoir si le multicloud est techniquement faisable mais quelles charges de travail justifient la surcharge opérationnelle de l’exécution multi-fournisseurs. Avec une interconnexion gérée, l’ensemble des réponses vient de s’élargir considérablement.

Questions Fréquemment Posées

Sources et lectures complémentaires

• AWS and Google Cloud collaborate on multicloud networking — Google Cloud Blog
• AWS and Google Cloud Preview Secure Multicloud Networking — InfoQ
• AWS finally moves to simplify multicloud operations with Google — Network World
• Build resilient and scalable multicloud connectivity architectures with AWS Interconnect — AWS Blog
• Azure follows Google in joining AWS multicloud initiative — Intercept Cloud
• AWS, Google link up to ease multicloud deployments — CIO Dive