Trois moyens de connecter vos environnements AWS et Microsoft Azure

Comme les architectures multicloud et de cloud hybride deviennent la norme pour les réseaux d’entreprise, nous examinons trois moyens de connecter les charges de travail dans les VPC AWS aux VNets Microsoft Azure.

Les architectures multicloud et de cloud hybride sont devenues courantes pour les services informatiques d’entreprise à la recherche d’une fiabilité réseau, d’une sécurité et d’une rentabilité accrues contribuant à atteindre des performances d’application optimales. Étant donné que de plus en plus de charges de travail d’entreprise migrent vers le cloud, il est tout naturel que les entreprises recherchent des moyens de connecter AWS et Microsoft Azure, les deux principaux hyperscalers, à la fois à des fins de pérennité et pour garantir la latence la plus faible possible entre les charges de travail.

 

Disons que vous êtes comme l’un de nos clients – une société de distribution mondiale – dont les services d’e-commerce sont hébergés sur AWS et Azure, avec des applications miroir déployées dans les deux clouds. Afin d’être conforme à votre politique de sécurité, vous réalisez un backhaul d’une partie de votre trafic vers votre centre de données où la politique est appliquée. Mais tout votre trafic ne doit pas être soumis à la politique de sécurité. Afin d’économiser des ressources réseau dans votre centre de données, vous voulez conserver le trafic restant à la périphérie de chaque cloud, faisant diminuer la latence entre AWS et Azure.

Dans ce cas, il existe trois moyens de connecter un environnement AWS à un environnement Microsoft Azure, chacun ayant ses avantages et ses inconvénients. Une méthode, le tunnel VPN, est de loin la plus courante, mais comme vous avez pu le deviner si vous lisez ce blog régulièrement, ce n’est pas la meilleure.

1. Configurer les tunnels VPN

Il existe quantité de ressources en ligne sur la manière de configurer un tunnel VPN via une connexion Internet publique entre AWS et Microsoft Azure. Il s’agit de la méthode de connexion classique et éprouvée pour connecter deux clouds. Le problème est que ce mode de connexion de vos environnements cloud présente de nombreux inconvénients. En voici un aperçu :

Inconvénient : débit limité

Pour les charges de travail à la puissance de calcul élevée, vous devez créer de nombreux tunnels pour prendre en charge le débit requis. Vous devez probablement consacrer beaucoup de temps à la gestion du routage ECMP (Equal-Cost Multi-Path Routing) ou de la répartition de la charge pour vous assurer que la bande passante requise reste disponible et éviter l’encombrement et la défaillance des tunnels VPN. 

Inconvénient : routage imprévisible via l’Internet public

Quiconque s’est déjà connecté à sa station de travail avec un jeton VPN sait par expérience que le transfert de données via l’Internet public ou via un tunnel VPN peut être délicat. Ceci est dû au fait que les protocoles de routage sur Internet se comportent de manière complexe et incohérente. Vous n’avez qu’un contrôle limité des routes que parcourent vos paquets de données. Un routage imprévisible signifie une latence accrue, ce qui réduit les performances de l’application.

J’ai écrit un article à ce sujet par le passé pour ONUG traitant du routage virtuel à la périphérie. 

Inconvénient : sécurité compromise en raison du détournement des routes BGP

D’année en année, la fréquence des cyberattaques ne cesse de croître. Aujourd’hui plus que jamais, les questions de cybersécurité préoccupent les CIO jour et nuit.

La même nature de confiance du Border Gateway Protocol (BGP) qui garantit l’évolutivité d’Internet rend également le web vulnérable aux attaques de détournement de routes par les auteurs des menaces. BGP se base sur des systèmes autonomes tels que les ISP pour annoncer des routes vers des blocs d’adresses IP. Des acteurs suspects peuvent pirater ces annonces et générer une redirection du trafic vers des « trous noirs » ou, dans le cas d’une attaque russe menée en 2018 à l’encontre du site de cryptomonnaie MyEtherWallet, vers un site d’hameçonnage collectant des données de compte, conduisant au détournement de 152 000 USD.

Inconvénient : frais de transfert de données AWS et Azure 

L’inconvénient majeur de la connexion des environnements cloud via des tunnels VPN est probablement le coût des données provenant de chaque environnement et revenant vers vos serveurs au sein d’un centre de données ou sur site en passant par l’Internet public. Ceci vaut également pour le routage des données entre vos environnements privés dans le cloud public, lorsque le trafic est acheminé d’un cloud à l’autre. Ces frais sont appliqués par Go par les fournisseurs cloud à la sortie. 

Les détails de tarification du transfert de données pour AWS et Azure sont disponibles ici et ici. AWS propose même un Cost Explorer pratique permettant d’analyser vos coûts de transfert de données.

Ces frais peuvent être prohibitifs. Pour l’un de nos clients, les frais de sortie potentiels s’élevaient à un total de 43 000 USD par mois avant Megaport !

2. Créer des lignes privées

Le deuxième moyen de connecter vos environnements AWS et Azure est de créer des lignes privées vers les deux hyperscalers en achetant des circuits dédiés à votre opérateur télécom. Ces circuits vous fourniront une connexion privée vers les fournisseurs cloud avec du trafic qui n’est pas acheminé via l’Internet public, si imprévisible et vulnérable. 

Toutefois, cette approche présente également de nombreux inconvénients :

Inconvénient : coût élevé avec des contrats à long terme

 

Vous serez probablement lié à votre opérateur télécom par des contrats de 18-24 mois pour vos circuits dédiés, avec des fenêtres d’installation de 45-90 jours. Ainsi, l’augmentation de la capacité de bande passante pourrait vous prendre des mois. Si vous cherchez à diminuer la capacité de bande passante, vous aurez des circuits inutilisés en raison de ces contrats à long terme. 

À terme, la création de lignes privées est probablement l’option la plus onéreuse de connexion entre AWS et Microsoft Azure.

Inconvénient : la latence restera un problème en raison du backhaul de trafic

Même avec des circuits privés vers chaque cloud, vous devrez toujours réaliser un backhaul du trafic vers votre centre de données ou votre équipement de routage sur site. En d’autres termes, vos données devront toujours sortir d’AWS via votre connexion privée pour revenir vers votre environnement sur site ou de colocation, pour seulement être renvoyées via votre autre connexion privée vers votre environnement Microsoft Azure si vous voulez que les charges de travail dans les deux environnements échangent des données. En conséquence, la latence restera un problème même si vos circuits privés vers AWS et Microsoft Azure vous offriront probablement une meilleure fiabilité qu’un tunnel VPN.

Inconvénient : dépenses d’investissement supplémentaires pour la capacité WAN

Même avec vos propres connexions privées vers les hyperscalers, vous aurez toujours besoin d’une infrastructure sur site ou d’une présence importante en termes de colocations. Bien sûr, cela implique une hausse des dépenses d’investissement à prendre en compte dans votre budget annuel.

3. Configurer une connectivité privée avec un routeur virtuel (comme Megaport Cloud Router)

Alors que le moyen le plus courant de connecter des charges de travail à différents environnements cloud est d’utiliser un tunnel VPN, une autre méthode de plus en plus répandue est de configurer une connectivité privée avec un routeur virtuel comme Megaport Cloud Router (MCR).

Avec un MCR, vous bénéficiez d’une connectivité privée et de la sécurité, la fiabilité et la réduction des coûts liées au fait de ne pas devoir envoyer des données via l’Internet public. Vous évitez par ailleurs les démarches suivantes : 

• Hairpinning du trafic vers votre environnement sur site
• Signature de contrats à long terme avec votre opérateur télécom
• Ajout d’équipements supplémentaires pour augmenter la connectivité
• Paiement de frais élevés de transfert de données AWS et Azure pour les données de sortie circulant via Internet
  
  

Si vous voulez adapter vos besoins de bande passante, vous pouvez le faire en quelques clics sur le réseau à définition logicielle (SDN) mondial et à la demande de Megaport ou en automatisant les modifications de vos besoins de capacité via notre API. Le MCR est configuré à l’emplacement physique où se situe la périphérie AWS et Microsoft Azure. Dans certains cas, le MCR et les deux fournisseurs de services cloud sont disponibles sur le même campus de centre de données. 

Disons que vous êtes à nouveau notre client, la société de distribution mondiale. Votre boutique d’e-commerce est hébergée avec AWS US-East (Virginie du Nord) avec des applications dans la zone US-East avec Azure. Vous voulez effectuer un routage direct entre les deux clouds tout en conservant la possibilité de gérer un pair primaire et secondaire vers votre centre de données dans la zone Washington DC afin de gérer votre politique de sécurité. 

Le MCR simplifie ce routage du trafic vers le centre de données pour la vérification de sécurité. Vous êtes en mesure de gérer un seul pair entre votre centre de données et le MCR. Lorsque des liens cloud supplémentaires sont ajoutés, aucun autre pair n’est requis dans le centre de données car vous pouvez facilement gérer ces pairs sur vos MCR.

En outre, la latence entre les deux environnements cloud connectés en privé via notre routeur virtuel correspond à un aller-retour de seulement trois à quatre millisecondes. Ce chemin à faible latence entre AWS et Azure résultant de la connexion directe du MCR garantit des performances d’application optimales.

En savoir plus

Pour savoir en détail comment le Megaport Cloud Router peut vous aider à connecter AWS et Azure, cliquez ici.