AWS et Google Cloud à Francfort : Interconnect multicloud DACH
Le 1er décembre 2025, AWS et Google Cloud ont accompli quelque chose qui n’avait jamais été fait auparavant : présenter un produit réseau co-développé. Des connexions privées chiffrées par MACsec entre les …
Le 1er décembre 2025, AWS et Google Cloud ont accompli quelque chose qui n’avait jamais été fait auparavant : présenter un produit réseau co-développé. Des connexions privées chiffrées par MACsec entre les deux nuages, provisionnées via une API en quelques minutes plutôt que sur plusieurs semaines via des fournisseurs tiers. Francfort est l’une des cinq régions de lancement. Pour les architectures multicloud en DACH, il s’agit d’un tournant décisif.
L’essentiel
- 🔗 AWS Interconnect (multicloud) et Google Cross-Cloud Interconnect relient pour la première fois nativement les deux nuages (AWS/Google, 01.12.2025).
- 🇩🇪 Francfort (eu-central-1 / europe-west3) est l’une des cinq régions de lancement en version préliminaire (Preview) (Documentation AWS).
- ⚡ Provisionnement en quelques minutes via une API. Jusqu’à présent, la mise en place de connexions privées entre nuages prenait des semaines voire des mois (InfoQ).
- 🔒 Chiffrement par MACsec (IEEE 802.1AE) sur la ligne physique. Aucun trafic ne transite par Internet public (AWS).
- 📊 À l’échelle mondiale, 89 % des entreprises utilisent plusieurs fournisseurs de services cloud (Flexera State of the Cloud, 2024).
Ce qu’AWS et Google Cloud ont construit
L’annonce a eu lieu le 1er décembre 2025, soit un jour avant le lancement de la conférence AWS re:Invent à Las Vegas. Pour la première fois, deux hyperscalers ont conjointement développé une infrastructure réseau reliant directement leurs nuages. Sur le plan technique, il s’agit de deux produits distincts : AWS Interconnect – multicloud côté AWS et Cross-Cloud Interconnect côté Google Cloud. Les deux reposent sur une spécification d’API co-développée.
Le résultat : les clients peuvent désormais établir des connexions privées et dédiées entre leurs VPC AWS et leurs réseaux VPC Google Cloud. Le trafic circule via des lignes physiques dédiées entre les routeurs Edge des deux fournisseurs, avec chiffrement MACsec (IEEE 802.1AE). Aucun paquet ne traverse Internet public.
En pratique, cela signifie ceci : une entreprise exploitant une base de données sur Google Cloud et sa logique applicative sur AWS peut désormais relier ces deux charges de travail avec des latences faibles et une bande passante maximale. Sans tunnel VPN, sans fournisseur de transit, sans provisionnement manuel.
Pourquoi Francfort, en tant que région de lancement, est déterminante
Les cinq régions de lancement de la version préliminaire sont US-East (Northern Virginia), US-West (Oregon), US-West (N. California), Europe (Londres) et Europe (Francfort). Le fait que Francfort soit incluse dès le départ n’est pas le fruit du hasard. La région eu-central-1 (AWS) ou europe-west3 (Google Cloud) constitue le principal site cloud d’Europe continentale.
Pour les entreprises de la région DACH, cela élimine l’un des principaux points de friction dans les architectures multicloud : la latence réseau entre les nuages. Jusqu’à présent, les entreprises souhaitant répartir leurs charges de travail entre AWS et Google Cloud devaient soit les router via Internet public (avec tous les risques liés à la sécurité et aux performances), soit intercaler un fournisseur tiers tel que Megaport ou Equinix Fabric. Cette démarche prenait des semaines, engendrait des coûts supplémentaires et offrait souvent une bande passante limitée.
Avec cet Interconnect natif, l’intermédiaire disparaît. Le provisionnement se fait via une API, la connexion est opérationnelle en quelques minutes, et le chiffrement est intégré par défaut. Pour les secteurs réglementés en Allemagne, qui doivent pouvoir justifier un traitement des données conforme au Règlement général sur la protection des données (RGPD), la garantie qu’aucun trafic ne transite par Internet public constitue un avantage concret en matière de conformité.
La spécification ouverte : un standard industriel en devenir
Un détail facile à sous-estimer : AWS a publié sur GitHub la spécification sous-jacente de l’API Connection Coordinator au format OpenAPI 3.0. Il ne s’agit pas d’un protocole propriétaire, mais bien d’une spécification ouverte que d’autres fournisseurs de services cloud peuvent implémenter.
Selon InfoQ, Microsoft Azure devrait être le prochain fournisseur à être intégré. AWS a annoncé son intention d’intégrer d’autres fournisseurs cloud. Si Azure suit effectivement en 2026, un Interconnect natif sera alors disponible entre les trois grands hyperscalers. Ce serait une évolution fondamentale : le réseau multicloud passerait d’un projet complexe d’infrastructure à un simple appel d’API.
Pour les architectes cloud, la balance coût/avantage des décisions multicloud change radicalement. Jusqu’à présent, la complexité réseau constituait l’un des arguments les plus puissants contre le multicloud. Une fois cette complexité levée, d’autres facteurs prennent le relais : les services « best-of-breed », la comparaison des prix, la disponibilité des zones et les exigences réglementaires.
Ce que l’Interconnect permet techniquement – et ce qu’il ne permet pas
L’Interconnect résout le problème du réseau. Or le multicloud comporte davantage de dimensions que la simple connectivité.
Ce qu’il permet : Des connexions privées et chiffrées de niveau 3 (Layer-3) entre les VPC AWS et les réseaux VPC Google Cloud. Provisionnement via API avec des débits définis (10 Gbps, 100 Gbps). Routage automatique via BGP. Surveillance depuis les consoles respectives des deux nuages.
Ce qu’il ne permet pas : Une facturation unifiée entre nuages. Des politiques IAM unifiées. Une observabilité transverse aux nuages depuis une seule console. Une migration automatique des charges de travail. L’Interconnect est une ligne réseau, pas un système d’exploitation multicloud.
Cela signifie que les équipes continuent d’avoir besoin d’outils de gestion transverse aux nuages : Terraform ou Pulumi pour l’Infrastructure as Code, Datadog ou Grafana pour la surveillance, ainsi que des processus organisationnels pour la gouvernance sur plusieurs comptes cloud. L’Interconnect supprime la complexité réseau, mais non la complexité opérationnelle.
Sécurité et conformité : ce que l’Interconnect implique pour les secteurs réglementés
Pour les prestataires de services financiers, les entreprises du secteur de la santé et autres secteurs réglementés en DACH, l’Interconnect représente bien plus qu’une amélioration des performances. La garantie qu’aucun trafic ne transite par Internet public simplifie considérablement la documentation RGPD. Les délégués à la protection des données peuvent démontrer que les données à caractère personnel sont transférées exclusivement via des lignes dédiées et chiffrées entre deux fournisseurs de services cloud.
Dans le contexte de la directive NIS2, cela revêt également une importance particulière. Les entreprises relevant de la loi de transposition de la directive NIS2 doivent documenter la sécurité de leur infrastructure réseau. Un Interconnect natif avec chiffrement MACsec est plus facile à documenter qu’un tunnel VPN transitant par Internet public. Les responsabilités sont clairement définies : AWS chiffre d’un côté, Google Cloud de l’autre, tandis que la ligne physique entre les deux est dédiée.
Une question toutefois demeure ouverte : comment l’Interconnect s’articule-t-il avec la souveraineté des données ? Les lignes physiques entre les routeurs Edge empruntent une infrastructure qui n’appartient ni à AWS ni à Google Cloud. Qui exploite cette infrastructure, et où exactement les données circulent-elles entre Francfort (AWS) et Francfort (Google Cloud), n’est pas entièrement documenté de façon transparente.
Conséquences pour les configurations multicloud existantes
À l’échelle mondiale, 89 % des entreprises utilisent plusieurs fournisseurs de services cloud, selon le Flexera State of the Cloud Report 2024. La plupart d’entre elles ne le font pas par conviction stratégique, mais parce que différentes équipes ont choisi des nuages différents. La connexion entre ces nuages était jusqu’à présent souvent improvisée : tunnels VPN, points de terminaison publics avec listes blanches d’adresses IP ou connexions directes coûteuses via des fournisseurs de colocation.
L’Interconnect natif change les règles du jeu pour trois scénarios :
Scénario 1 : Pipeline de données. Une entreprise utilise BigQuery sur Google Cloud pour ses analyses et S3 sur AWS pour le stockage de ses données. Jusqu’à présent, les données devaient transiter par Internet ou via un fournisseur de transit. Désormais, elles circulent via une ligne dédiée et chiffrée. Plus rapide, plus sûr, moins coûteux en termes de trafic sortant (egress).
Scénario 2 : Reprise après sinistre (Disaster Recovery). Charges de travail principales sur AWS, basculement (failover) sur Google Cloud. L’Interconnect permet une réplication synchrone ou asynchrone avec une latence garantie. Rien à voir avec la réplication basée sur VPN jusqu’alors pratiquée.
Scénario 3 : Best-of-Breed. Kubernetes sur GKE (Google), inférence IA sur SageMaker (AWS), base de données sur Cloud SQL (Google). Plutôt que de faire des compromis architecturaux, chaque équipe peut utiliser le meilleur service disponible, en laissant à l’Interconnect la gestion de l’intégration réseau.
Ce que les fournisseurs tiers comme Megaport et Equinix doivent faire maintenant
Pour des entreprises telles que Megaport, Equinix Fabric et PacketFabric, l’Interconnect natif constitue une menace stratégique. Leur modèle économique repose sur la création de connexions entre des nuages incapables jusqu’ici de se relier eux-mêmes. Si AWS et Google Cloud proposent cette fonctionnalité nativement, et si Azure suit, le marché adressable se rétrécit fortement.
Ces fournisseurs tiers devront désormais se concentrer sur des valeurs ajoutées : gestion multicloud, visibilité, rapports de conformité et interconnexion avec des fournisseurs de services cloud plus petits, qui ne font pas partie de l’Interconnect natif. Pour les entreprises qui misent sur des fournisseurs cloud européens tels qu’IONOS, OVHcloud ou STACKIT, les fournisseurs tiers restent, pour l’instant, la seule option pour établir des connexions privées.
Conclusion
L’Interconnect AWS-Google Cloud est bien plus qu’un nouveau produit réseau. C’est un signal fort : les hyperscalers ont pris acte du fait que le multicloud est devenu une réalité, et commencent à ouvrir leurs infrastructures. Le choix de Francfort comme région de lancement rend immédiatement pertinent cet offre pour les entreprises de la région DACH.
Les architectes cloud devraient évaluer dès maintenant la version préliminaire. Pas pour migrer immédiatement, mais pour comprendre comment la balance coût/avantage des architectures multicloud évolue. Si Azure suit en 2026 et que la spécification ouverte devient un standard industriel, la complexité réseau cessera d’être un argument contre le multicloud.
La question ne sera alors plus « multicloud ou non ? », mais « quelle combinaison de fournisseurs et de services permet de concevoir l’architecture la plus adaptée à mon entreprise ? ».
Questions fréquentes
L’Interconnect AWS-Google Cloud est-il déjà prêt pour la production ?
L’Interconnect se trouve actuellement en version préliminaire (Preview) (état au mars 2026). Il est fonctionnel et peut être testé, mais AWS et Google Cloud recommandent de ne pas encore l’utiliser pour des charges de travail critiques en production. La disponibilité générale (General Availability, GA) est prévue pour 2026.
Quel est le coût de l’Interconnect ?
La tarification n’est pas encore définitive pendant la phase Preview. Les deux fournisseurs appliquent généralement des frais par port (dépendant de la bande passante) ainsi que des frais de trafic sortant (egress) pour les données transférées. Ces frais d’egress devraient être inférieurs à ceux appliqués lors d’un transfert via Internet public.
Puis-je combiner l’Interconnect avec mes configurations existantes de Direct Connect ou de Partner Interconnect ?
Oui. L’Interconnect complète les connexions existantes (AWS Direct Connect, Google Partner Interconnect). Il ne les remplace pas, mais ajoute une nouvelle option spécifique au trafic entre nuages.
Azure sera-t-il également intégré ?
AWS a annoncé son intention d’intégrer d’autres fournisseurs de services cloud, notamment Microsoft Azure. Aucune date précise n’a encore été communiquée, mais la spécification API ouverte rend techniquement possible cette intégration. La communauté s’attend à une mise en œuvre en 2026.
Ai-je encore besoin de Megaport ou d’Equinix Fabric ?
Pour la connexion directe entre AWS et Google Cloud dans les régions Preview, non. En revanche, pour les connexions vers Azure, vers des fournisseurs cloud européens ou vers des centres de données sur site (on-premises), les fournisseurs tiers restent pleinement pertinents.
Articles complémentaires
- Sovereignty-Washing – Pourquoi un centre de données européen ne garantit pas la souveraineté des données (cloudmagazin)
- Le piège des coûts VMware en 2026 – Pourquoi les équipes IT doivent choisir dès maintenant des alternatives (cloudmagazin)
- Les coûts de l’IA dans le cloud hors de contrôle – Pourquoi les charges de travail GPU feront exploser les budgets IT en 2026 (cloudmagazin)
Plus d’articles du réseau média MBF Media
- Edge Computing – Pourquoi le cloud ne suffit pas toujours aux PME (MyBusinessFuture)
- Repatriation cloud en 2026 – Pourquoi les DSI ramènent des charges de travail en interne (Digital Chiefs)
Source de l’image : Brett Sayles / Pexels
Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.
