Temps de lecture : 12 minutes

Bien des gens mythifient le service AWS Direct Connect (AWS DX), à tort.

Cet article n’a pas vocation à être un tutoriel complet sur la mise en œuvre et la configuration de Direct Connect, mais plutôt à le rendre plus accessible et peut-être même à éclairer les lecteurs curieux de comprendre le service sans pour autant mettre (trop) le nez dans ses détails.

Description

Si l’on devait résumer rapidement ce qu’est AWS Direct Connect, c’est le service AWS qui permet de se connecter physiquement à AWS, comme si l’on tirait un câble (réseau) jusqu’à AWS. Et finalement c’est presque ça.

Plus précisément, AWS Direct Connect est le moyen mis en place par AWS pour raccorder son infrastructure dite « on-premises » à AWS, sans passer par Internet. Concrètement, cela consiste à connecter physiquement son réseau à un équipement réseau appartenant à AWS (ou souvent l’un de ses partenaires), dans l’un de ses points de présence (aussi appelés PoP, Point of Presence) qui sont dans différents datacenters à travers le monde.

Cette interconnexion (dans le milieu, on parle de crossconnect) et son mode opératoire de mise en service ne sont pas bien différents de ce qui fait la base (et le nom) d’Internet (en anglais « interconnected networks », soit l’interconnexion de réseaux). La différence est que cette interconnexion n’est pas à tout Internet, mais seulement à AWS. On parle donc ici de mettre en place un peering privé.

Remarque : un PoP AWS sera toujours associé à une région AWS spécifique, qui peut ne pas être la région géographique où se trouve le PoP. Par exemple (au moment où cet article est écrit), le PoP Teraco JB1 situé à Johannesburg (Afrique du Sud) est raccordé à la région AWS eu-west-1 (Irlande). Pour une entreprise qui a son infrastructure AWS dans une région différente de celle associée au PoP, AWS facturera des frais de trafic inter-région.

Les avantages de Direct Connect sont multiples (liste non exhaustive) :

• avoir une connexion privée dédiée à AWS, et donc avoir une qualité de service réseau bien meilleure
• faire (selon les cas) des économies de frais de transferts AWS. En effet, AWS facture en général chaque Gigaoctet de données qui sort : avec Direct Connect, ce n’est pas différent, mais à un prix inférieur. Par exemple en Europe on trouve un prix aux alentours de $0.09/Go vers Internet, contre $0.02/Go vers Direct Connect. Pour une entreprise téléchargeant de gros volumes de données stockés sur AWS vers leur infrastructure, le coût total (prix réduit de transferts + connexion Direct Connect) sera en général bien inférieur à celui sans Direct Connect (en passant par Internet).

Si l’on devait trouver un inconvénient à ce service, ce serait peut-être son processus de mise en œuvre (qui peut durer plusieurs semaines), bien que selon les cas il y a des partenaires AWS facilitant énormément celui-ci. En ce qui concerne sa configuration technique, bien que nécessitant un minimum de compétences en réseaux, elle se résume simplement à comprendre le concept de peering réseau, et cet article a justement l’intention de l’expliquer.

Types de connexion

Il y a deux types de connexion AWS Direct Connect :

• dédiée (dedicated)
• hébergée (hosted)

Pour reprendre les mots de la FAQ Direct Connect :

• Une connexion dédiée passe par un port Ethernet de 1 Gb/s, 10 Gb/s ou 100 Gb/s dédié à un seul client.
• Les connexions hébergées proviennent d’un partenaire Direct Connect qui dispose d’une liaison réseau entre lui et AWS.

Autrement dit, une connexion dédiée sera une véritable interconnexion physique avec un équipement réseau AWS Direct Connect, et donc au débit de l’interface réseau (actuellement 1/10/100 Gbps), tandis qu’une connexion hébergée sera techniquement identique (une interconnexion physique), mais avec un partenaire d’AWS. C’est ce dernier qui dispose d’une ou plusieurs connexions Direct Connect dédiées, qui sont alors partagées avec d’autres clients Direct Connect (le partenaire fait office d’intermédiaire).

En réalité, pour assurer un débit conforme à celui qui est contractualisé pour une connexion hébergée, le partenaire applique sur ses routeurs réseau du lissage de trafic (traffic policing), c’est-à-dire un système qui drop (supprime) tout le trafic dépassant le débit maximum autorisé. Cela permet d’avoir une vraie segmentation d’une connexion dédiée pour garantir une qualité de service aux différents clients du partenaire.

Ce système de partenariat AWS Direct Connect pour obtenir des connexions hébergées permet :

• d’avoir un plus grand nombre de PoP Direct Connect à travers le monde : les PoP AWS sont nombreux, mais ils ne peuvent pas être présents dans tous les datacenters du monde, tandis qu’en passant par un partenaire, il est possible de transiter par le réseau de celui-ci (via d’autres datacenters) avant de terminer l’interconnexion avec AWS dans l’un des PoP Direct Connect. Les PoP AWS sont en quelque sorte de gros hubs de connexions dédiées, et les clients n’ayant pas d’accès physique à ceux-ci peuvent passer par un partenaire qui s’occupe d’irriguer plus de datacenters reliés à ces PoP.
• d’avoir une connexion Direct Connect à des débits inférieurs à 1 Gbps, par exemple 50/100/200/500 Mbps, ce qui n’est pas permis par les connexions dédiées. Il est aussi possible de monter jusqu’à 1/10 Gbps. Malgré la marge de prix que prend le partenaire Direct Connect, il peut être plus intéressant pour une entreprise d’avoir un débit plus adapté à son besoin.

Mise en oeuvre d’une connexion

Connexion dédiée

Dans le cas d’une connexion dédiée, il faut d’abord, à partir de la console AWS (ou par CLI/API pour les plus téméraires), faire une demande de connexion à AWS, en sélectionnant le PoP parmi la liste disponible.

AWS va alors préparer une interface réseau (physique) sur l’un de ses équipements Direct Connect du PoP sélectionné, prête à l’emploi, et ensuite envoyer un document appelé LOA-CFA (Letter Of Authority – Customer Facility Assignment). Il s’agit d’un document contractualisant la connexion, détaillant très précisément toutes les informations relatives à l’interconnexion, y compris (et surtout) l’emplacement exact dans le PoP où il faut se raccorder (la baie, le numéro de port, etc.). Sur la console AWS, la connexion Direct Connect est également créée.

Il faut alors organiser le raccordement (par fibre optique) entre l’équipement Direct Connect et l’équipement du client Direct Connect. Cette étape est souvent gérée par l’entreprise partenaire qui gère le PoP, et qui a une pièce dédiée aux interconnexions appelée MMR (Meet-Me Room). Ce genre de pièce permet de pré-câbler tout le datacenter, et donc de ne faire des raccordements que dans cette pièce. L’interconnexion sera faite en suivant les données inscrites sur le LOA-CFA, et peut durer un certain temps.

Connexion hébergée

Dans le cas d’une connexion hébergée, la demande de connexion ne passe pas par AWS mais directement auprès du partenaire AWS Direct Connect. Il faudra donc demander une connexion à un débit au choix (50/100/200/500 Mbps, voire 1/10 Gbps) et indiquer le numéro de compte AWS sur lequel partager la connexion Direct Connect. D’un partenaire à l’autre, le processus sera différent, certains de manière plus automatisée que d’autres.

Une fois que le partenaire a réalisé les interconnexions, la connexion Direct Connect sera alors visible dans la console AWS, dans un état « en attente d’acceptation ». Il faut alors accepter la connexion pour que celle-ci devienne utilisable et sera facturée.

Quand la connexion est disponible

Lorsque la connexion Direct Connect est enfin disponible sur un compte AWS, il faut alors configurer au moins une VIF (Virtual Interface, ou Interface Virtuelle en Français).

VIF

Il existe 3 types de VIF :

• Private (privée)
• Transit (de transit)
• Public (publique)

On peut résumer ces 3 types de la manière suivante :

• Private VIF : permet de relier le Direct Connect à un VPC (ou plusieurs en utilisant une Direct Connect Gateway)
• Transit VIF : permet de relier le Direct Connect à une ou plusieurs Transit Gateways, et donc une multitude de VPC (sur un ou plusieurs comptes AWS)
• Public VIF : permet de relier le Direct Connect aux services AWS, par leurs accès publics tels qu’ils sont exposés sur Internet

Dans le cas d’une connexion dédiée, il est parfaitement possible de créer plusieurs VIF sur une même connexion Direct Connect, et donc potentiellement cumuler les 3 types de VIF. On peut donc imaginer un scénario dans lequel la connexion Direct Connect permet d’atteindre des buckets S3 (hors VPC) depuis le datacenter on-premises via une Public VIF, tout en permettant d’atteindre des instances EC2 situées dans plusieurs VPC via une Transit VIF, ou bien même avec autant de Private VIF qu’il y a de VPC (moins recommandé).

Attention tout de même aux quotas, Direct Connect n’autorise au maximum qu’une Transit VIF et 50 Private/Public VIF par connexion dédiée. Ces quotas restent tout de même très difficiles à atteindre, car 1 public VIF peut suffire pour se raccorder aux services d’AWS, et si un client Direct Connect a plus de 49 VPC à raccorder, il lui sera recommandé de passer par une ou plusieurs Transit Gateways, qui seront alors raccordable à une unique Transit VIF, par l’intermédiaire d’une Direct Connect Gateway.

Dans le cas d‘une connexion hébergée, et c’est là l’un des gros points d’attention à avoir lorsque l’on investit dans Direct Connect, il ne peut y avoir qu’une seule VIF (peu importe le type) pour la connexion.

Cette limitation du nombre de VIF est due au fait qu’au niveau réseau, une VIF sera sur un VLAN (Virtual Local Area Network) dédié, c’est-à-dire un réseau « virtuel » (logique et non physique) entre l’équipement Direct Connect AWS et celui du client Direct Connect. Concrètement, cela veut dire que sur une connexion dédiée (qui dispose d’une interface réseau physique dédiée), on peut découper l’interconnexion réseau en une multitude de VLAN, et donc une multitude de VIF, tandis que sur une connexion hébergée, le partenaire d’AWS Direct Connect réalise déjà ce découpage entre ses clients Direct Connect, chaque connexion hébergée étant alors sur un VLAN. Un client de connexion hébergée voulant à la fois un accès aux services AWS (avec une Public VIF) et à un VPC (avec une Private ou Transit VIF) devra donc investir dans 2 connexions hébergées.

Lors de la configuration d’une VIF, il faut préciser un numéro de VLAN sur lequel elle sera configurée : sur une connexion dédiée, il faut alors choisir un nombre (1-4094) unique par VIF, tandis que sur une connexion hébergée, le numéro sera imposé par le partenaire d’AWS, car ce sera celui utilisé pour la connexion.

Peering BGP

Avant toute chose, il faut expliquer (ou rappeler) ce qui fait la base des réseaux informatiques : le routage. Il s’agit du mécanisme permettant aux systèmes connectés à un réseau (un PC, smartphone, etc.) de sortir de celui-ci et de communiquer avec des systèmes présents sur d’autres réseaux (un serveur web, etc.), a travers un processus de décision d’orientation du trafic. On peut comparer ce mécanisme à celui des services postaux : les 2 systèmes qui communiquent sont l’expéditeur d’un courrier dans une ville A et son destinataire situé dans une ville B. Les services postaux lisent l’adresse de destination du courrier (l’adresse IP de destination), et vont le mettre dans le camion qui va à destination de la ville B, ou bien si ce n’est pas possible dans un camion qui va dans une autre ville dans laquelle il y aura des correspondances possibles vers la ville B (ou d’autres correspondances, et ainsi de suite). Chaque fois que le courrier est mis dans un camion, c’est à la suite d’une décision prise par les services postaux. Il en va de même pour les réseaux informatiques : des routeurs orientent les données communiquées entre 2 systèmes pour atteindre la bonne destination, et de préférence le plus rapidement et efficacement possible. Ces décisions de routage sont prises en consultant la table de routage, que l’on peut voir comme un registre en 2 colonnes : IP de destination (une IP unique ou bien un bloc d’IP, aussi appelé préfixe, sous-réseaux ou encore CIDR) et “next hop”, qui correspond à l’adresse IP vers laquelle envoyer le trafic.

Ainsi, pour faire communiquer des réseaux du client Direct Connect avec des réseaux AWS, quel que soit le type de VIF à créer, il va falloir mettre en place ce qu’on appelle un peering BGP.

Si l’on devait résumer BGP (Border Gateway Protocol) en quelques mots, il s’agit d’un protocole d’échange de routes (réseau), qui consiste à faire discuter 2 « peers », identifiables par un numéro d’AS (Autonomous System) pour s’identifier. Ce protocole est utilisé pour créer le réseau maillé qu’est devenu Internet, par tous ses acteurs.

Ce dialogue entre les 2 peers est bidirectionnel, et donc chacun des peers peut envoyer des routes connues. L’idée est de communiquer à son peer “si tu veux joindre l’IP X, alors tu peux passer par moi”. Ces échanges permettent alors à chacun des peers de mettre à jour leur table de routage respective pour prendre les décisions de routage qui conviennent et ainsi permettre la communication de réseaux entre eux.

Dans le cas d’un Direct Connect, quel que soit le type de VIF ou le type de connexion, il va falloir configurer une session BGP (un peering) entre l’équipement du client Direct Connect (routeur ou autre équipement avec des fonctionnalités de routage) situé à l’extrémité de la connexion, et celui d’AWS, situé à l’autre extrémité, les 2 peers étant sur le même VLAN dédié à la VIF.

Ainsi, l’équipement du client Direct Connect pourra communiquer à son peer d’AWS une liste de sous-réseaux (par exemples les IP de son datacenter), tandis que le routeur AWS enverra une liste de réseaux AWS, à savoir :

• Public VIF : la liste de toutes les IP (publiques) des services d’AWS, de toutes les régions. Si besoin, il est possible de les filtrer facilement pour, par exemple, ne prendre en compte que les adresses de la région AWS de la connexion Direct Connect, et ainsi éviter d’avoir une liste de centaines d’IP dans la table de routage de l’équipement du client Direct Connect.
• Private VIF : la liste des blocs d’IP du VPC auquel la VIF est attachée
• Transit VIF : une liste de bloc d’IP, par exemple ceux de plusieurs VPC rattachés à la Transit Gateway

Note: dans le cas d’une Public VIF, il faut savoir que le peering se fait uniquement sur des adresses IP publiques (routables sur Internet), c’est-à-dire que le VLAN de la VIF sera sur un adressage public (il est possible de demander à AWS d’en fournir un, car tout le monde ne possède pas des IP publiques), et les IP échangées devront également être publiques. AWS annoncera les adresses IP publiques de ses services, le client Direct Connect devra alors annoncer des adresses IP publiques consommatrices de ces services AWS, et qui lui appartiennent (AWS va contrôler cela auprès des registres publics). Ces IP sont également demandées par AWS lors de la création de la Public VIF, car seuls celles qui sont déclarées passeront le filtrage de routes mis en place par AWS et seront donc acceptés par leurs équipements.

Une fois le peering BGP en place (la connexion est établie, et les annonces de d’IP sont correctement réalisées), la connexion Direct Connect est alors exploitable, et le client Direct Connect a ainsi une liaison réseau dédiée avec AWS. Il reste alors, côté client, à configurer correctement son routage réseau pour que son trafic à destination d’AWS passe bien par la connexion Direct Connect et non par un autre chemin (connexion Internet ou autre).

Conclusion

AWS Direct Connect est l’un des services qui est rapidement indispensable pour les entreprises qui ont besoin de liens résilients et de qualité entre leurs infrastructures et AWS.

Les possibilités d’architecture réseau comprenant Direct Connect sont nombreuses : on peut très bien dédoubler les connexions pour la redondance, ou bien en agréger pour des débits plus élevés, ou encore créer une redondance avec un VPN Site-to-Site d’AWS au travers d’une connexion Internet en parallèle.

Que l’on ait une connexion dédiée ou hébergée, AWS a su simplifier la mise en œuvre de la connectivité avec ses services, facilitant encore plus le passage au cloud.