Le coût masqué de l’exécution du SD-WAN hébergé dans le cloud pour IaaS

Dans un secteur porté par le SD-WAN, il existe trois moyens courants de connecter vos succursales au cloud. Nous exposons les avantages et les limites de chacun d’entre eux.

De nombreuses entreprises mettent d’abord en œuvre une stratégie de migration cloud avant de moderniser leurs applications – et le SD-WAN en fait partie. Le passage à une architecture cloud native utilisant la conteneurisation, les microservices ou les architectures sans serveur comme le SD-WAN permet de réduire les coûts au fil du temps, d’augmenter l’évolutivité, de réduire les cycles de développement et d’accélérer la commercialisation.

Toutefois, le prochain défi consiste à veiller à ce que les succursales puissent accéder à cette application publique désormais modernisée et basée sur le cloud. Et s’il y a encore des applications existantes hébergées dans le cloud privé ou des services hébergés chez un deuxième ou un troisième fournisseur de cloud public ?

Avec la popularité grandissante du SD-WAN et un nombre croissant de migrations de WAN d’entreprise du MPLS vers des réseaux sous-jacents à haut débit, le trafic critique passe désormais par des connexions basées sur l’Internet public de type best effort. Il ne fait aucun doute que cette transition vers des succursales alimentées par le cloud exige de repenser l’architecture de l’entreprise.

Lisez notre article de blog pour évaluer les points communs, les différences et les avantages du SD-WAN et du MPLS.

Une option consiste à acheminer le trafic lié au cloud depuis les succursales vers le centre de données puis vers l’extérieur dans le cloud, idéalement via une connectivité privée. Cette méthode peut fonctionner, mais selon l’emplacement géographique du centre de données de l’entreprise, elle peut également introduire du hairpinning, ce qui augmente considérablement la latence et réduit les performances des applications. La deuxième option est de permettre aux succursales de communiquer directement avec le cloud. Il existe plusieurs méthodes à cet effet, dont les suivantes :

• Passerelles VPN des fournisseurs de services cloud (VPG AWS, VNG Azure, VPN Google Cloud)
• SD-WAN basé sur le cloud (dont VPC de transit AWS, WAN virtuel Azure, NCC Google Cloud)
• NaaS (Megaport Virtual Edge)

Approche standard de la succursale au cloud avec des tunnels VPN

Prenons l’exemple d’une société de distribution de taille moyenne comptant environ 40 succursales aux États-Unis, qui a besoin d’un accès à un point de vente/une plateforme de gestion des stocks hébergé(e) dans le cloud. Une solution rapide et simple serait d’utiliser la passerelle VPN de site à site standard proposée par les fournisseurs cloud.

Dans un environnement AWS, cela supposerait de créer des tunnels IPsec sur l’Internet public vers une passerelle privée virtuelle connectée à un seul cloud privé virtuel (VPC). L’inconvénient de cette méthode est la règle un à un qui s’applique également à Azure, puisque son équivalent (la passerelle VPN) ne peut être lié qu’à un seul VNet. Comme un réseau virtuel est limité à une seule passerelle, cela signifie que si l’entreprise établit un deuxième réseau virtuel, cela nécessiterait une deuxième VGW et de nouveaux tunnels IPsec vers les 40 succursales. Les fournisseurs cloud ont un nombre maximum de tunnels de succursales liés à une seule passerelle VPN. Ce nombre s’élève à 30 pour Azure et à 10 pour AWS (mais il peut être augmenté sur demande).

Il existe également un plafond limitant les vitesses réseau. On croit souvent à tort que les tunnels IPsec vers le cloud sont limités à 1,25 Gbit/s — il s’agit en réalité du débit total de la passerelle. Ainsi, si vous configurez 40 succursales, elles se partageront ce débit de 1,25 Gbit/s, résultant en un débit d’environ 30 Mbits/s par site. Par ailleurs, ces 30 Mbits/s par succursale circuleront exclusivement par l’Internet public et seront confrontés à des niveaux imprévisibles de gigue, de perte de paquets et de latence. Enfin, comme le trafic du cloud à la succursale passe par l’Internet public, il sera soumis aux frais de transfert de données sortant (DTO) et de sortie des fournisseurs cloud standard, qui s’élèvent à environ 10 centimes par gigabit sortant de votre réseau virtuel.

Périphérie SD-WAN hébergée dans le cloud

Afin de relever les défis mentionnés précédemment que pose l’infrastructure basée sur un VPN standard, les fournisseurs cloud et les fournisseurs de matériel réseau traditionnels (tels que les partenaires Megaport Cisco et Fortinet) ont mis au point des solutions qui peuvent être intégrées à un SD-WAN d’entreprise.

Fortinet Secure SD-WAN est désormais activé sur Megaport Virtual Edge (MVE). Lire l’article de blog ici.

Le SD-WAN est une architecture WAN virtualisée basée sur une variété de méthodes de transport sous-jacentes telles que le MPLS, le haut débit et le LTE afin de connecter des succursales aux applications hébergées dans le cloud privé et public. L’un des avantages clés du SD-WAN est la centralisation des fonctions de contrôle et de routage qui dirigent les chemins du trafic via le WAN superposé.

S’il existe plusieurs variantes, cette architecture étend en principe la structure SD-WAN au cloud public à l’aide d’une Infrastructure as a Service (IaaS), chargeant ensuite le logiciel du fournisseur SD-WAN depuis la place de marché du fournisseur cloud (BYOL ou Bring Your Own License). Cela permet un déploiement très rapide, des niveaux d’automatisation élevés et des opérations simplifiées en utilisant la console de gestion du fournisseur SD-WAN.

Tout d’abord, penchons-nous sur une solution basée sur IaaS dans AWS et sur ses éléments clés. Le premier élément est le VPC de transit, qui agit comme hub central pour tout le trafic à destination et en provenance des succursales, et comme canal vers les clouds privés virtuels (VPC) des applications.

Deux machines virtuelles sont créées dans le VPC de transit et une image du fournisseur SD-WAN est ensuite chargée pour créer deux routeurs virtuels qui peuvent être gérés par Cisco vManage, FortiManager ou une solution équivalente. Les frais horaires pour les VM AWS sous-jacentes dépendront des spécifications sélectionnées lors de la conception.

Sur le diagramme ci-dessus, vous voyez que les routeurs virtuels ont des connexions de tunnel IPsec vers le nord en direction des VPC de production, de développement et de test via leurs passerelles privées virtuelles (VPG) respectives. Les deux routeurs virtuels ont également des connexions IPsec basées sur Internet vers le sud en direction de chaque succursale dans le SD-WAN. Pour la redondance, il est recommandé que chaque succursale crée un tunnel vers chaque routeur virtuel. À l’aide d’un protocole de routage de type BGP, les sous-réseaux privés dans le VPC de l’application seront annoncés aux routeurs virtuels, qui annonceront à leur tour ces sous-réseaux aux 40 succursales (par souci de clarté, le diagramme ne montre que cinq succursales).

Besoin d’établir la connectivité de la succursale à Azure sur Cisco SD-WAN ? Regardez notre tutoriel vidéo ici.

Si le nombre de succursales SD-WAN augmente, des machines virtuelles supplémentaires (routeurs) peuvent être requises car il existe des limites de bande passante et de CPU en raison du volume requis de chiffrement/déchiffrement de tunnel IPsec.

Cette solution SD-WAN utilise toujours l’Internet public ; ainsi, les frais de sortie standard s’appliquent, mais il existe un risque de les voir être multipliés par deux. Comme les connexions vers le nord utilisent des tunnels IPsec Internet, des frais seront facturés pour chaque gigaoctet sortant des VPC de l’application à destination du VPC de transit. Si le trafic est destiné à une succursale, des frais par gigaoctet supplémentaires s’appliqueront lors de la sortie du VPC de transit vers le sud. En réalité, le client se voit facturer des frais de sortie en double pour chaque gigaoctet parvenant à une succursale.

En fonction des charges de travail et du flux de trafic, la solution SD-WAN basée sur IaaS peut être très bien adaptée à de nombreuses entreprises. Observons ce qui se passe lorsqu’un deuxième fournisseur cloud est introduit pour éviter la dépendance à un fournisseur, assurer la continuité opérationnelle ou utiliser une nouvelle application interne qui fonctionne mieux, comme Microsoft Azure. L’architecture devient alors nettement plus complexe, car désormais toutes les 40 succursales ont besoin d’accéder à la fois aux VPC AWS et aux nouveaux VNets Azure.

Dans un environnement Azure, un WAN virtuel est déployé et un hub virtuel VNet est créé (très similaire à un VPC de transit AWS). De même, des VM doubles sont créées dans ce hub et le logiciel SD-WAN est chargé en plus pour créer une appliance réseau virtuelle (NVA). Une succursale existante se connecte alors aux deux NVA via des tunnels IPsec dans le hub virtuel Azure (en plus des deux tunnels existants vers AWS). Comme le montre le diagramme, cela signifie qu’il y a maintenant des centaines de tunnels IPsec.

Jusqu’à présent, nous avons uniquement envisagé le multicloud dans le flux de succursale à cloud, mais une connectivité cloud à cloud peut également être requise, par exemple lors de la réplication des données entre les clouds. Il y a alors deux options : procéder à un hairpinning du trafic vers le centre de données sur site (ce qui génère une latence plus élevée), ou créer de nouveaux tunnels IPsec entre le hub virtuel Azure et le VPC de transit AWS, ce qui va de pair avec des frais de sortie Internet et des limites de débit imposées aux tunnels.

Megaport Virtual Edge (MVE)

Megaport Virtual Edge (MVE), en combinaison avec une solution de connectivité cloud privée de couche 2 telle que AWS Direct Connect, Azure ExpressRoute ou Google Cloud Interconnect, permet de résoudre de nombreux problèmes rencontrés avec les deux solutions ci-dessus.

MVE améliore votre plateforme SD-WAN d’entreprise existante en vous permettant de créer de façon stratégique des chemins optimaux vers les applications critiques, où qu’elles se trouvent. En réalité, MVE donne aux entreprises la possibilité de créer leurs propres PoP régionaux en quelques minutes et d’étendre la portée de leur WAN en utilisant le réseau à définition logicielle (SDN) mondial de Megaport. Il existe actuellement 22 zones métropolitaines MVE dans le monde, chacune comptant au moins deux centres de données et des fournisseurs de services de transit Internet prenant en charge les zones de disponibilité MVE pour garantir une résilience WAN de bout en bout.

Penchons-nous de plus près sur MVE afin de comprendre ses éléments clés et ses fonctionnalités.

MVE est un périphérique SD-WAN virtualisé à la demande qui est disponible en trois tailles en fonction des combinaisons de vCPU, de transit IP et du nombre de succursales reliées. Le logiciel du fournisseur SD-WAN peut être choisi par le client ; MVE prend actuellement en charge Cisco et Fortinet, auxquels s’ajouteront d’autres fournisseurs au cours de l’année 2021. Dès lors, le MVE est géré en réalité comme une appliance SD-WAN standard au sein de la structure WAN d’entreprise et peut être configuré depuis Cisco vManage, FortiManager ou une solution équivalente.

Le trafic des succursales arrive au MVE via l’Internet local du premier kilomètre, généralement en moins de 10 ms environ en fonction de la proximité. À partir de là, le MVE a accès à la structure mondiale de Megaport, qui comprend plus de 235 on-ramps de cloud public permettant des connexions privées de couche 2 (telles que AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, etc.).

Fonctionnement

Les succursales SD-WAN peuvent créer des rattachements IPsec au MVE via le transit IP redondant de niveau 1 inclus avec les adresses IP publiques fournies par Megaport. Une fois que le trafic des succursales arrive au MVE, les entreprises peuvent regrouper le trafic de leurs succursales à un emplacement MVE centralisé, le faire passer rapidement par les tunnels IPsec de l’Internet public et rediriger ce trafic vers les fournisseurs cloud majeurs via la dorsale Megaport, ce qui offre plusieurs avantages.

Avantages

1. Performance des applications : les succursales qui accédaient auparavant aux applications cloud via l’Internet public verront leurs performances s’améliorer. Désormais, seul le « premier kilomètre » passera par Internet tandis que la majorité du trajet sera effectuée via la dorsale Megaport, réduisant la gigue, la latence et la perte de paquets.

2. Accès à la structure Megaport : MVE permet d’accéder à l’écosystème Megaport composé de plus de 360 fournisseurs de services et de plus de 700 centres de données agréés dans le monde incluant plus de 235 on-ramps cloud – soit l’un des meilleurs fournisseurs neutres de NaaS (Réseau en tant que Service).

3. Réduction des frais opérationnels : l’utilisation de la connexion privée des hyperscalers au lieu des tunnels IPsec Internet peut réduire les frais de sortie de 70 à 80 %. En Amérique du Nord, cela signifie un passage de 10 centimes par gigaoctet à 2 centimes par gigaoctet en moyenne. Outre les frais de sortie, si nous comparons MVE à une solution de transit SD-WAN IaaS en utilisant notre base de 40 succursales, avec des VM AWS doubles (taille C5) transmettant 10 To par mois du cloud aux succursales, la solution MVE coûterait 15 % de moins par mois.

4. Simplification du réseau : avec la solution IaaS, en reprenant l’exemple des 40 sites, au moins quatre tunnels IPsec par site seraient nécessaires – soit un minimum de 160 tunnels au total. Chacun d’entre eux nécessite des adresses IP /30 et des notifications sur l’état des liaisons, et consomme des ressources CPU précieuses à la fois au niveau de la succursale et des routeurs virtuels basés sur le cloud. En optant pour MVE, une entreprise peut réduire massivement la complexité de son architecture réseau.

5. Efficacité du SD-WAN : l’intégration de votre plateforme SD-WAN avec MVE vous permet d’établir des trajets intermédiaires stratégiques sur votre WAN en utilisant les connexions transversales virtuelles (VXC) de Megaport. Les services de régulation du trafic du SD-WAN exploiteront immédiatement ces chemins plus efficaces pour des flux d’application de bout en bout.

6. À la demande : il n’y a aucun équipement à acheter ou à installer dans un centre de données, ni aucune connexion transversale à exécuter. MVE (comme les solutions IaaS) peut être provisionné en temps réel et être opérationnel en quelques minutes.

7. Cloud à cloud : comme le MVE dispose d’une connectivité privée de couche 2 vers AWS et Azure, tout trafic cloud à cloud peut également utiliser ces connexions et ainsi éviter de passer par un tunnel IPsec onéreux ou de réaliser un hairpinning du trafic vers votre routeur sur site.

De nombreux déploiements SD-WAN initiaux sont motivés par un objectif à long terme visant à remplacer les connexions MPLS de succursales onéreuses par des solutions plus rentables comme le haut débit ou le LTE. En parallèle, ces mêmes entreprises mettent en œuvre des stratégies de migration cloud et de modernisation des applications. Megaport Virtual Edge permet de réaliser tous ces objectifs en faisant office de passerelle entre le SD-WAN et le cloud (dont le cloud privé, public, hybride et le multicloud).

Découvrez comment le SD-WAN peut optimiser la mise en réseau de votre entreprise.

La technologie SD-WAN est extrêmement performante. Son atout principal est sa capacité à façonner le trafic des applications et à l’orienter vers plusieurs voies de transport WAN. En intégrant Megaport Virtual Edge dans leur structure WAN, les entreprises bénéficient d’une flexibilité et d’un contrôle accrus de leur WAN afin d’optimiser leurs applications (ce qui n’est pas toujours possible avec une périphérie SD-WAN hébergée dans le cloud). MVE peut également réduire considérablement vos frais de sortie tout en simplifiant nettement votre réseau.

Megaport Virtual Edge peut héberger des instances virtuelles de vos routeurs périphériques SD-WAN dans 22 emplacements en Amérique du Nord, Asie-Pacifique et Europe. Pour en savoir plus, cliquez ici.