Opérations multicloud sans ruptures
AWS a annoncé le 14 avril la disponibilité générale d'AWS Interconnect - multicloud.
Le 14 avril, AWS a confirmé la disponibilité générale d’AWS Interconnect – multicloud, avec Google Cloud comme premier partenaire de lancement. Ce qui compte pour les architectes DACH : les opérations de charge de travail entre les deux clouds s’effectuent désormais via un pont natif chiffré MACsec – y compris Francfort et Londres comme régions au démarrage. Microsoft Azure et Oracle suivront plus tard dans l’année. Cela élimine une grande partie de la plomberie qui a jusqu’à présent défini les opérations multicloud.
Les points clés en bref
- Quoi de neuf : AWS Interconnect – multicloud est disponible depuis le 14 avril, Google Cross-Cloud Interconnect pour AWS est l’équivalent.
- Où ça démarre : Cinq régions AWS, dont Francfort et Londres – pertinentes pour les flux de données conformes à DACH sans relais aux États-Unis.
- Comment ça fonctionne : Une ressource de transport dans Google Cloud, une acceptation dans AWS, chiffrement MACsec toujours activé, temps de configuration en minutes au lieu de jours.
- Pourquoi c’est pertinent maintenant : Avec Transit Gateway ou Cloud WAN, le pont s’adapte à l’ensemble du réseau dorsal AWS – le véritable levier opérationnel.
- Ce qui reste ouvert : Microsoft Azure et Oracle Cloud sont annoncés, mais pas encore en ligne. Les questions d’identité et de FinOps restent des chantiers distincts.
Qu’est-ce qu’AWS Interconnect – multicloud ? AWS Interconnect – multicloud est une connexion privée native à haut débit entre les Amazon VPC et d’autres environnements de hyperscalers. Contrairement aux modèles de connexion croisée précédents, la solution ne nécessite pas de réseau dorsal tiers ni de câblage séparé de l’autre côté – la couche physique, BGP et les attachments VLAN sont abstraits. La bande passante évolue de 1 à 100 Gbit/s, le chiffrement MACsec est activé par défaut.
Ce que la disponibilité générale apporte réellement
Le véritable enjeu n’est pas la fibre optique, mais ce qui se passe à l’extrémité de la fibre optique. Jusqu’à présent, les « opérations multicloud » signifiaient pour la plupart des équipes DACH : Direct Connect chez AWS, Partner Interconnect chez Google, un fournisseur de colocation au milieu, BGP propre, propre chiffrement, propres tickets chez trois interlocuteurs différents en cas de problème. Cela fonctionne, mais c’est une plomberie qui n’a rien à voir avec la charge de travail qui s’exécute dessus.
Avec la disponibilité générale, AWS et Google réduisent cette pile à une seule ressource de transport. Selon le blog de Google Cloud, la ressource de transport est configurée dans Google, acceptée dans AWS, le reste – Cloud Router, attachments VLAN, interconnexions physiques – est abstrait. Temps de configuration : minutes au lieu de jours. Le chiffrement MACsec est toujours activé, la rotation des clés est gérée par les deux fournisseurs.
Avec l’annonce d’AWS du 14 avril vient le deuxième levier : Interconnect peut être connecté à Transit Gateway ou Cloud WAN. Ainsi, une connexion n’a pas une VPC, mais l’ensemble du réseau dorsal AWS comme portée. Celui qui prévoit un déplacement de charge de travail entre GKE et EKS ne voit soudainement plus une topologie en étoile cauchemardesque, mais un modèle de routage unique. C’est la différence entre la plomberie réseau et les opérations de charge de travail.
Chronologie : l’évolution des passerelles entre hyperscalers
Ce que cela signifie concrètement pour les configurations hybrides DACH
La plupart des configurations multicloud dans la région DACH ne résultent pas d’une stratégie, mais d’acquisitions, de piles SaaS développées et d’un monde SAP-on-AWS avec des annexes BigQuery. Ceux qui déplacent aujourd’hui des données ou des ressources de calcul entre les deux clouds exploitent généralement deux piles de réseau distinctes et un déclencheur Excel pour les tests de basculement. Ce n’est pas faux, mais cela coûte des heures que personne ne veut plus planifier dans les réunions d’exploitation.
La version GA répond précisément à cette friction opérationnelle. Francfort et Londres signifient que les workloads DACH n’ont pas besoin d’être routés via des régions américaines – il ne s’agit pas seulement de latence, mais également d’un argument de conformité au RGPD que les équipes de conformité peuvent présenter sans problème. La spécification ouverte sur GitHub suggère que Stackit, OVH ou d’autres fournisseurs de cloud locaux pourront mettre en œuvre le même mécanisme à moyen terme – cela est pertinent pour les architectes qui ne peuvent pas aujourd’hui miser à 100 % sur des hyperscalers américains pour des raisons réglementaires.
En complément : Google Cloud a déployé parallèlement la mise en cache inter-cloud pour les données lues d’AWS et Azure. Ceux qui combinent les deux disposent d’un pont d’exploitation et d’un pont de données – mais c’est une autre discussion avec ses propres compromis en matière de souveraineté des données.
Les arguments pour et contre
Les arguments pour
- Temps de configuration réduit de jours à minutes – le gain se situe dans les étapes de test et de développement, pas dans le tunnel de production.
- MACsec toujours activé, rotation des clés gérée – un point d’audit de moins par trimestre.
- Francfort et Londres en tant que régions permettent des flux de données conformes à la réglementation DACH sans relais aux États-Unis.
- Offre gratuite à 500 Mbit/s à partir de mai rend les véritables essais pilotes abordables – aucun dossier commercial interne n’est nécessaire.
- La connexion à Transit Gateway et Cloud WAN permet de faire évoluer une connexion vers l’ensemble du réseau fédérateur AWS.
Les arguments contre
- Azure et Oracle manquent encore – ceux qui exploitent trois clouds continuent d’utiliser l’ancienne pile.
- Le pont ne résout pas les problèmes d’identité, mais uniquement ceux liés au réseau. SCIM, fédération IAM et identité de charge de travail restent un sujet à part.
- Tarification en fonction de la bande passante et de la géographie – la modélisation doit être discutée dans les comités FinOps, sinon l’offre gratuite consommera plus qu’elle n’économise.
- Le verrouillage par le fournisseur devient plus subtil : deux clouds, un modèle de tissu – la sortie est possible, mais plus coûteuse que la simple coupure d’une configuration VPN.
Trois leviers pour les architectes dans les 60 prochains jours
Premièrement : l’inventaire. Quelles charges de travail sont exécutées aujourd’hui dans les deux clouds, quelles passerelles sont actives, lesquelles sont des rampes résiduelles d’anciennes migrations ? Ceux qui souhaitent travailler avec la GA doivent connaître la liste des véritables passerelles, et non la présentation de la dernière revue d’architecture. Cet inventaire est étroitement lié à l’inventaire de conformité multi-cloud sous NIS2 et C5, qui est de toute façon dû.
Deuxièmement : le modèle d’exploitation. Qui le contrôle ? Un pont d’exploitation nécessite une définition claire du propriétaire – sinon, il atterrit entre le réseau, la plateforme cloud et le SRE. Trois tickets par incident ne sont pas un état cible. Un entonnoir SRE multicloud qui achemine les tickets vers les deux consoles et offre une vue de bout en bout est judicieux.
Troisièmement : l’adaptation de l’IaC. Ceux qui planifient le déplacement de charges de travail devraient déjà intégrer le bloc de ressources de transport dans les modules Terraform – les mises à jour des fournisseurs arrivent dans les prochaines semaines, et le verrouillage de version détermine si le pilote démarre au troisième trimestre ou seulement après le prochain rafraîchissement.
Foire aux questions
Quand AWS Interconnect – multicloud sera-t-il généralement disponible ?
AWS a confirmé la disponibilité générale le 14 avril 2026. Google Cloud est le premier partenaire de lancement, Microsoft Azure et Oracle Cloud Infrastructure suivront plus tard dans l’année, selon les deux fournisseurs.
Quelles régions sont pertinentes pour la DACH ?
Francfort et Londres comptent parmi les cinq régions de démarrage, auxquelles s’ajoutent N. Virginie et Oregon. Cela permet de connecter les charges de travail DACH sans détour transatlantique – pertinent pour la latence et pour l’argumentation du RGPD.
En quoi cela diffère-t-il de la variante précédente de Cross-Cloud Interconnect ?
Jusqu’à présent, Cross-Cloud Interconnect était une construction spécifique à Google : Google établissait la connexion, et côté AWS, il fallait câbler comme pour Direct Connect. Avec la GA bilatérale, une ressource de transport dans Google et un accept dans AWS suffisent, la couche physique et le routage sont abstraits.
Combien coûte la connexion dans les premières semaines ?
À partir de mai 2026, un slot local de 500 Mbit/s par région est disponible gratuitement. Des bandes passantes plus élevées jusqu’à 100 Gbit/s seront facturées en fonction de la bande passante et de la portée géographique – le calcul appartient à la prochaine revue FinOps.
Quels services AWS peuvent être couplés à Interconnect ?
Selon AWS, Interconnect peut être connecté à AWS Transit Gateway et AWS Cloud WAN. Cela permet de faire évoluer une seule connexion multicloud vers plusieurs VPC et régions – le véritable levier d’exploitation.
L’encryption MACsec apporte-t-elle une différence mesurable pour la conformité ?
Oui, car le chiffrement sur la couche 2 est toujours activé et les deux fournisseurs assurent la rotation des clés. Les équipes d’audit n’ont ainsi plus besoin de vérifier si un tunnel a été configuré correctement – c’était jusqu’à présent un poste récurrent dans les revues C5 et ISO 27001.
Les lectures recommandées par la rédaction
Plus du réseau MBF Media
- MyBusinessFuture – Numérisation, IA et stratégie d’entreprise pour les PME de la région DACH
- SecurityToday – Cybersécurité, NIS2 et conformité sous l’angle des opérations
- Digital Chiefs – La perspective C-Level sur la stratégie, la direction et le conseil de surveillance
Crédit image de titre : Pexels / Brett Sayles (px:4373997)
Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.
