AWS Interconnect connecte Azure en preview, plafonné à 1 Gbps sans SLA
Le 31 août 2026, AWS Interconnect multicloud s’ouvre à Azure en preview publique : un VPC et un VNet reliés sur le backbone privé d’AWS, sans opérateur tiers, mais plafonné à 1 Gbps et sans engagement de disponibilité. Testez-le pour vos charges partagées AWS-Azure, mais gardez vos circuits existants jusqu’à la disponibilité générale.
31 août 2026. AWS ouvre AWS Interconnect — multicloud à Microsoft Azure en preview publique. 14 avril 2026. Le même produit atteignait la disponibilité générale avec Google Cloud, à 100 Gbps et avec SLA. 29 juillet 2026. Oracle Cloud rejoignait à son tour la boucle. Pourquoi c’est important : pour la première fois, une équipe peut relier un VPC AWS à un VNet Azure en privé sans négocier avec un opérateur — mais la preview arrive avec un plafond de 1 Gbps et aucun SLA, ce qui en fait un terrain de test, pas encore un remplaçant de circuit de production.
Ce qui a été livré
AWS Interconnect — multicloud connecte un Amazon VPC à un Azure Virtual Network sur le backbone privé d’AWS, jamais sur l’Internet public. La preview couvre quatre paires de régions : Virginie du Nord, Californie du Nord, Sydney et Francfort, chacune mappée à une région Azure correspondante. C’est plus étroit que le lancement Google Cloud, parti avec cinq paires de régions entre les États-Unis et l’Europe.
Microsoft a publié en parallèle son propre pendant, Azure Multicloud Interconnect, appuyé sur ExpressRoute. Le discours est identique des deux côtés : une ressource logique unique, provisionnée depuis la console de chaque cloud, qui remplace les cross-connects, les VPN et les circuits tiers négociés au fil des mois.
Le produit n’est pas une abstraction marketing. AWS et le cloud partenaire gèrent ensemble les liaisons physiques, et aucun client ne configure de peering BGP, d’adressage IP ou d’annonces de routes. L’interconnexion apparaît comme une pièce jointe à attacher, à la manière d’un peering de VPC ou d’une attache Transit Gateway.
Le plafond de 1 Gbps et l’absence de SLA
C’est ici que la preview Azure s’écarte nettement de ce qu’AWS a déjà livré pour Google Cloud et Oracle. Le plafond est fixé à 1 Gbps par interconnexion — le plus petit palier proposé par AWS. La disponibilité générale « visera » 100 Gbps, comme pour Google Cloud, mais AWS n’a pas annoncé de date, seulement « plus tard en 2026 ».
Il n’y a aucun engagement de service pendant la preview. AWS vise 99,99 % de disponibilité à la disponibilité générale, mais ce chiffre est un objectif, pas un contrat. À titre de comparaison, le lien Google Cloud a reçu un SLA formel le 16 avril 2026, deux jours après sa disponibilité générale. Une entreprise qui évalue le lien Azure aujourd’hui teste donc un produit qu’AWS ne s’est pas encore engagé à maintenir à une disponibilité donnée.
La tarification suit la même logique. Côté AWS, le tarif horaire est le même que pour Google Cloud et Oracle : en Amérique du Nord et en Europe, 3,50 $/h pour 1 Gbps, jusqu’à 146,60 $/h pour 100 Gbps. Côté Azure, Microsoft ne facture encore ni frais de service ni transfert de données — un vide qui ressemble moins à une preview « gratuite et généreuse » qu’à une grille pas encore finalisée.
MACsec et le modèle de sécurité
Chaque lien AWS Interconnect — multicloud, quel que soit le partenaire, chiffre la couche physique en IEEE 802.1AE MACsec entre les routeurs de bord d’AWS et ceux du cloud partenaire. Le chiffrement est appliqué avant que le trafic n’atteigne un réseau virtuel client, et AWS traite une session MACsec active comme une condition préalable au flux : si la session chiffrée tombe, la connectivité tombe avec elle, sans bascule vers un transport en clair.
L’architecture repose aussi sur des paires de routeurs redondants et plusieurs chemins de backbone par région, mais AWS n’a pas publié les délais de basculement exacts. Pour la preview Azure, cette redondance existe sans les garanties de compensation d’un SLA — une distinction à signaler à quiconque voudrait bâtir une dépendance de production avant la disponibilité générale.
Pourquoi Google est arrivé en premier
Le calendrier donne la mesure de la course. AWS a annoncé le concept à re:Invent fin novembre 2025, avec Google Cloud comme seul partenaire de lancement. Google a franchi la disponibilité générale le 14 avril 2026, à 100 Gbps. Oracle a suivi le 29 juillet 2026, sur une seule paire de régions au départ. Azure arrive le 31 août 2026, avec moins de régions et un plafond plus bas que ses deux prédécesseurs au même stade.
L’écart a une explication simple : AWS et Google ont commencé dix mois plus tôt, et la preview Azure reflète un rapprochement plus prudent — ou un alignement technique plus long. Peu importe la cause, la conséquence opérationnelle est la même : le chemin AWS↔Google est aujourd’hui un produit fini, quand le chemin AWS↔Azure reste un chantier.
Ce qu’il faut mettre en place
Trois décisions à prendre selon votre situation :
- Si vous exploitez des charges réparties entre AWS et Azure — bases de données d’un côté, couches applicatives de l’autre, ou Azure AD adossé à du calcul AWS — évaluez la preview dès maintenant pour mesurer la latence et la simplicité réelles, mais sur un environnement de test.
- Ne remplacez pas encore vos circuits Megaport, PacketFabric ou Equinix. Le plafond de 1 Gbps et l’absence de SLA interdisent d’en faire une dépendance de production ; votre contrat actuel reste le plan de continuité.
- Surveillez la disponibilité générale. Dès qu’AWS publie un SLA et les paliers supérieurs, la bascule devient une équation tarifaire simple contre votre opérateur — le produit facture à l’heure, sans frais de port, et AWS ne facture aucun egress sur le lien Google Cloud, un signal fort sur sa stratégie multicloud.
Verdict
Si vous êtes déjà en multicloud AWS-Azure et que vous payez un opérateur tiers pour relier les deux, ouvrez la preview et chiffrez ce que coûterait le remplacement à disponibilité générale — mais ne migrez rien en production tant que le plafond de 1 Gbps et l’absence de SLA tiennent. Si vous ne faites que du AWS↔Google Cloud ou AWS↔Oracle, vous avez déjà un produit fini à 100 Gbps avec SLA : aucune raison d’attendre Azure. Si vous débutez en multicloud, notez que le rapport de force s’inverse : le multicloud, longtemps assemblé à la main, devient une fonctionnalité facturée à l’heure par les hyperscalers eux-mêmes — et le coût de sortie de votre cloud actuel n’a jamais été aussi bas.