En bref

  • AWS a annoncé fin avril 2026 la disponibilité générale d'AWS Interconnect Multicloud, un service de raccordement privé direct entre VPC Amazon et autres fournisseurs cloud.
  • Google Cloud est le premier partenaire de lancement ; Microsoft Azure et Oracle Cloud Infrastructure rejoindront le programme dans le courant 2026.
  • La solution apporte chiffrement MACsec edge-to-edge, bande passante dédiée jusqu'à 100 Gbit/s et publication d'une spécification ouverte sous Apache 2.0 sur GitHub pour standardiser le multicloud.

Ce qui s'est passé

AWS a basculé en disponibilité générale son service AWS Interconnect Multicloud, qui permet d'établir une connexion privée à très haut débit entre un Amazon VPC et un autre fournisseur cloud sans transiter par Internet ni par un opérateur tiers. Le service était en preview depuis re:Invent 2025 et couvrait alors quatre régions : Northern Virginia, Oregon, Londres et Francfort. La mise en production étend la couverture aux régions Tokyo, Sydney, São Paulo et Paris, avec une feuille de route qui annonce dix régions supplémentaires d'ici la fin 2026.

Le partenaire de lancement est Google Cloud, choisi pour son maillage Cross-Cloud Interconnect déjà éprouvé. Concrètement, un client AWS peut désormais provisionner depuis sa console une liaison directe vers un VPC Google Cloud existant, en quelques minutes et sans passer par un porteur télécom. La latence inter-cloud constatée en preview tombe sous la barre des 2 millisecondes pour les régions colocalisées, contre 8 à 15 millisecondes via Internet public ou via une interconnexion classique chez un opérateur d'interconnect.

Microsoft Azure et Oracle Cloud Infrastructure rejoindront le dispositif dans le courant 2026. Selon AWS, les négociations techniques sont déjà bien engagées avec Microsoft, mais l'alignement des modèles de facturation egress entre les deux acteurs reste l'obstacle principal. Oracle, lui, a annoncé qu'il ouvrirait son OCI FastConnect au protocole AWS Interconnect dès le second semestre, dans le prolongement du partenariat Oracle Database@AWS noué en 2024.

Sur le plan technique, la solution s'appuie sur du chiffrement MACsec entre les routeurs edge des deux fournisseurs, ce qui garantit une intégrité et une confidentialité de la couche 2 sans nécessiter de tunnel IPsec applicatif. La bande passante est dédiée et provisionnée par paliers : 1 Gbit/s, 10 Gbit/s, 40 Gbit/s et 100 Gbit/s, avec un mécanisme de burst pour absorber les pics. L'intégration s'effectue via les Transit Gateway côté AWS et via Network Connectivity Center côté Google, exposant un même plan de contrôle à l'opérateur réseau.

L'annonce la plus structurante n'est pas le service lui-même mais la publication, sous licence Apache 2.0 sur GitHub, de la spécification d'interopérabilité sous-jacente. AWS positionne explicitement cette spécification comme un standard ouvert pour la connectivité multicloud, à la manière dont Kubernetes a structuré l'orchestration de conteneurs. Le dépôt aws/multicloud-interconnect-spec compte déjà des contributions de Google, mais aussi d'Equinix, Megaport et Cloudflare. Forrester y voit une tentative de fixer un standard de fait avant que Microsoft n'impose son propre protocole.

Côté tarification, AWS rompt avec la pratique historique des « egress fees » punitifs sur les flux sortants vers d'autres clouds. Sur AWS Interconnect Multicloud, les flux entre VPC AWS et le cloud partenaire sont facturés selon un barème dégressif qui descend jusqu'à 0,008 USD/Go pour les volumes supérieurs à 100 To/mois, soit environ dix fois moins cher qu'un transfert via Internet public. Google Cloud applique la même grille de son côté. Cette nouvelle politique d'égalisation tarifaire répond directement aux pressions exercées par la Commission européenne et la CMA britannique sur les egress fees, jugés anticoncurrentiels en juillet 2025.

Plusieurs cas d'usage sont mis en avant par AWS dans ses keynotes techniques. Le premier est l'entraînement distribué de modèles d'IA : pouvoir consommer du calcul Trainium chez AWS et du calcul TPU chez Google sans payer de pénalité réseau ouvre la voie à des architectures hybrides multi-accélérateurs. Le second est la résilience régulatoire : les entreprises soumises à NIS2 ou DORA peuvent répartir leurs charges critiques entre deux clouds pour respecter l'exigence d'absence de dépendance à un fournisseur unique. Le troisième concerne les flux de données médicales, où la séparation entre cloud de stockage et cloud de traitement devient une exigence des autorités de santé européennes.

Les premiers retours utilisateurs en preview sont globalement positifs. Snowflake, Databricks et Stripe ont publié des études de cas démontrant des gains de latence de 30 à 60 % sur leurs pipelines analytiques cross-cloud. La société française Doctolib a confirmé migrer une partie de ses traitements vers une architecture multicloud AWS-Google s'appuyant sur Interconnect, dans le cadre de sa mise en conformité avec le HDS et le Cloud Act bypass.

Pourquoi c'est important

La généralisation d'AWS Interconnect Multicloud signe un tournant idéologique chez Amazon. Pendant plus d'une décennie, AWS a tenu une position frontale anti-multicloud, accusant la stratégie « best-of-breed » d'ajouter inutilement de la complexité opérationnelle sans valeur métier. Le fait que le leader du marché reconnaisse désormais la légitimité du multicloud — et y mette en plus son sceau standardisant — banalise définitivement cette approche. Les architectes cloud qui plaidaient depuis des années pour une stratégie multicloud structurée gagnent un argument décisif auprès de leurs comités d'architecture.

Pour les directions infrastructure françaises, l'annonce arrive à point nommé. La pression réglementaire sur la dépendance à un fournisseur unique — qu'elle vienne de NIS2, de DORA ou des autorités sectorielles comme l'ACPR pour la finance ou l'ANS pour la santé — pousse à l'hybridation. Jusqu'ici, le coût opérationnel d'un raccordement entre AWS et Azure ou entre AWS et Google passait par un opérateur d'interconnect tiers (Equinix, Megaport, Console Connect), avec un délai de provisionnement de plusieurs semaines et une facture mensuelle à cinq chiffres. AWS Interconnect Multicloud ramène ce délai à quelques minutes et réduit le coût d'un facteur cinq à dix.

Le risque corollaire est moins commercial que stratégique. En publiant la spécification d'interopérabilité, AWS se positionne comme l'arbitre de fait du multicloud, ce qui crée une asymétrie de gouvernance : celui qui définit le standard maîtrise l'agenda d'évolution. Microsoft pourrait répliquer en proposant une spécification concurrente, ce qui fragmenterait l'écosystème. Les acheteurs publics européens — et la DGNum en particulier — devraient se saisir de cette spécification dès maintenant pour évaluer son alignement avec les exigences SecNumCloud et avec la stratégie souveraine européenne portée par Gaia-X.

Enfin, la baisse drastique des egress fees prépare une recomposition du marché des opérateurs d'interconnect. Les acteurs comme Equinix Fabric et Megaport Cloud Router voient leur proposition de valeur érodée : si les hyperscalers s'interconnectent directement à un coût marginal, l'intermédiaire ne se justifie plus que pour des cas très spécifiques (latence sub-milliseconde, multi-régions complexes). Une consolidation du secteur est anticipée par les analystes financiers d'ici 2027.

Ce qu'il faut retenir

  • AWS Interconnect Multicloud est en GA avec Google Cloud en premier partenaire ; Azure et OCI suivront en 2026.
  • Spécification ouverte sous Apache 2.0 sur GitHub : un standard de fait du multicloud porté par AWS.
  • Pour les architectes : ré-évaluer les architectures cross-cloud pour conformité NIS2/DORA et économies sur les egress fees.

AWS Interconnect Multicloud remplace-t-il Direct Connect ?

Non. Direct Connect reste le service de raccordement privé entre un site on-premise et AWS via un opérateur partenaire ou une colocation. AWS Interconnect Multicloud cible spécifiquement les liaisons entre VPC AWS et un autre fournisseur cloud public ; il ne se substitue ni à Direct Connect, ni au Site-to-Site VPN, ni à AWS Cloud WAN. Les trois services peuvent coexister dans une même architecture hybride pour gérer respectivement on-premise, multi-cloud et inter-régions AWS.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact