Problématique de l’interconnexion de plusieurs VPC/comptes AWS

Sur AWS, les bonnes pratiques nous encouragent à séparer nos environnements : production, pré-production, et développement doivent être séparés. De même, il est conseillé de séparer les environnements de différentes équipes. Depuis quelques années, AWS a engagé beaucoup d’efforts sur le développement des fonctionnalités d’AWS Organizations, favorisant ainsi une séparation en différents comptes AWS. Il est aujourd’hui courant que les entreprises, même d’une taille modeste, gèrent plusieurs dizaines de comptes AWS… et au moins autant de VPC !

La question de l’interconnexion de tous ces VPCs, entre eux et avec le réseau d’entreprise, est donc très vite devenue centrale lors de la définition d’une infrastructure AWS.

Le “avant” coûteux du modèle Transit VPC

Le peering de VPC était rapidement exclu car les peering ne sont pas transitifs et on se retrouvait vite aux limites de la feature, avec un plat de spaghetti en guise de réseau.

De fait, pendant très longtemps, le seul modèle qui fonctionnait à grande échelle était celui du Transit VPC. Ce n’est pas notre sujet, mais un rapide rappel permet de mieux réaliser d’où on vient. Le concept était “simple” : dans un VPC dédié (le Transit VPC), on instancie deux grosses c4.8xlarge avec l’AMI d’appliance routeur/firewall de notre éditeur préféré, puis on configure ces appliances pour créer des connexions VPN vers chacun de nos autres VPC.

On s’assure que le Transit VPC ait la connectivité avec notre réseau local et, en gérant bien la configuration, ça y est, on a un réseau d’entreprise étendu dans AWS, plus ou moins hautement disponible et permettant d’atteindre des milliers de VPC. 

Bien sûr, la solution n’était pas parfaite: d’abord, entre les instances, les licences et les connexions VPN, son coût était exorbitant ; ensuite, il y avait les difficultés à gérer correctement la redondance entre les appliances et plus généralement à maintenir la configuration de l’ensemble à jour au fur et à mesure de l’ajout de nouveaux VPCs.

Pour l’anecdote, j’ai connu une entreprise qui utilisait cette solution à grande échelle (des milliers de VPC), on parlait de centaines de milliers de dollars.
Mensuels.
Et l’ajout de nouveaux VPCs passait par une demande à l’équipe réseau sous forme de fichier Excel.
Et ça prenait une semaine si on était chanceux.

Bref, vous l’aurez compris, ce n’était pas hyper DevSecOps agilo-compatible, mais on n’avait pas le choix.

L’horizon s’est enfin éclairci en Novembre 2018, à Las Vegas, avec l’annonce de l’arrivée d’AWS Transit Gateway au re:invent.

Présentation de Transit Gateway

AWS Transit Gateway remplace tout simplement toute cette histoire de Transit VPC par un seul service managé, scalable, redondant et automatisable.

Comparé à ce qu’il fait pour nous, j’affirmerais volontiers que le service est simple à gérer. Mais quand on met le nez dedans pour la première fois on peut se sentir un peu perdu, surtout si on ne vient pas du monde du réseau. Voyons tout d’abord les différents composants du service et leurs relations, pas à pas.

Transit Gateway

En plus d’être le nom du service, c’est également le nom du composant central. Une “Transit Gateway” est un élément régional : on en crée normalement une par région, peu importe le nombre de comptes AWS.

En général, on la crée dans un compte AWS dédié (appelons le “network”) et on la partage avec tout le reste de notre organization via AWS Resource Access Manager (RAM). Ainsi elle est visible et utilisable depuis tous nos comptes.

Attachment

Pour connecter un VPC avec une Transit Gateway, on crée un “Attachment”. La création se fait depuis le compte du VPC. Le compte “network”, hébergeant la Transit Gateway, doit ensuite accepter la création de l’attachment. Alternativement, on peut configurer la Transit Gateway pour accepter automatiquement les nouveaux attachments (attention dans ce cas à ce que la Transit Gateway n’utilise pas de table de routage par défaut, sinon c’est un potentiel problème de sécurité).

Par défaut une Transit Gateway peut avoir jusqu’à 5000 attachment (soft-limit).

Une fois l’attachment créé, les tables de routage du VPC peuvent utiliser une nouvelle cible: la Transit Gateway. On décide ainsi quel(s) subnet(s) du VPC peuvent communiquer avec elle. En général, on route tout le trafic “privé” (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) vers la Transit Gateway, voire on fait de la Transit Gateway la cible par défaut, mais cela dépend bien entendu de ce qu’on vise à accomplir.

La Transit Gateway étant un élément régional, elle ne peut être attachée qu’à des VPC de la même région. Si vous avez des VPCs dans plusieurs régions, il est possible d’établir un Peering entre des Transit Gateway de deux régions différentes, permettant ainsi la création d’un réseau multi-régions.

Néanmoins, ce sujet est hors du scope de cette série d’articles et nous allons seulement considérer le cas d’une région unique. Si vous êtes intéressé par un article sur les Transit Gateway dans un contexte multi-régions, contactez moi pour le dire, ça m’encouragera à l’écrire !

Petite précision : un attachment n’est pas forcément une liaison entre une Transit Gateway et un VPC. Un attachment peut également être un Transit Gateway Peering, une connexion VPN ou même une liaison Direct Connect (techniquement ça change de nom dans le cas Direct Connect).

Transit Gateway Route Table

Lorsqu’on utilise une Transit Gateway, on doit ensuite pouvoir contrôler le routage des flux réseaux. Les Transit Gateway Route Table (TGWRT) permettent ce contrôle. Chaque Transit Gateway peut avoir jusqu’à 20 TGWRT contenant en tout 10 000 routes (ce sont des soft-limits).

Chaque route est composée d’un CIDR block et d’une cible. La cible est un attachment.

Si on oublie les limites bien plus élevées et les cibles différentes, une Transit Gateway Route Table fonctionne de la même manière que les VPC Route Table dont nous avons l’habitude. 

Notamment, elles prennent en compte le “closest match” : la route utilisée pour prendre une décision de routage sera la plus précise parmi celles correspondant à la destination du paquet. Et tout comme pour les VPCRT, on ne peux pas utiliser deux fois le même CIDRBlock dans la même TGWRT : il n’y a donc jamais d’ambiguïté.

Association, propagation & routes

Chaque attachment est associé avec une seule TGWRT et c’est elle qui décidera du routage des paquets IP en provenance de l’attachment. La décision est prise en fonction de l’IP de destination du paquet et de la table de routage associée à l’attachment. Notez que si un attachment ne peut être associé qu’à une seule TGWRT, une même TGWRT peut en revanche être associée avec plusieurs attachments.

Par ailleurs, on peut également propager un attachment sur une ou plusieurs TGWRT. La propagation ne doit pas être confondue avec l’association. La propagation est simplement une facilité pour créer une route dans une TGWRT. Lorsqu’on propage un attachment sur une TGWRT, le service va automatiquement créer une route utilisant le CIDRBlock du VPC correspondant à l’attachment (ou les annonces BGP du VPN le cas échéant) avec cet attachment en cible. On pourrait faire la même configuration manuellement sans aucune différence fonctionnelle, c’est juste une facilité.

Donc pour résumer :

• J’associe un attachment avec une TGWRT parce que je veux que cette TGWRT soit utilisée pour router les paquets en provenance de cet attachment (ceux qui sortent du tuyau)
• Je propage un attachment sur une ou plusieurs TGWRT parce que je veux que ces TGWRT puissent router du traffic vers cet attachment (envoyer des paquets dans le tuyau).

Ici, les attachment de nos “App VPC” sont attachés à la TGWRT “AppVPCs” et ils sont propagés dans la TGWRT “Network” (pour information cette configuration particulière permet à chaque “App VPC” de communiquer via le VPN, mais pas entre eux).

Un flux, quatre tables de routage

Un point important à souligner, c’est que lorsqu’on souhaite établir une connectivité entre deux VPC via Transit Gateway, il n’y a pas forcément qu’une seule TGWRT à configurer.

En effet, rien n’empêche que les deux attachments de nos VPC soient associés à deux TGWRT différentes. En pratique, c’est même souvent le cas, comme nous le verrons. De plus, les VPC Route Table de chaque VPC doivent également être correctes.

Comme on le voit sur le schéma, si l’instance A et l’instance B communiquent, la TGWRT 1 est utilisée pour le trafic allant de A vers B car c’est elle qui est associée à l’attachment A. Mais c’est la TGWRT 2 qui est utilisée pour le trafic allant de B vers A car c’est elle qui est associée à l’attachment B. Généralement, on a besoin que le trafic puisse aller dans les deux sens pour que ça fonctionne, on a donc bien 4 tables de routage à considérer.

“Un flux, deux Transit Gateway Route Table et deux VPC Route Table”.

C’est important à garder en tête lorsqu’on fait du débug ou de l’audit sur Transit Gateway.

Le use-case trivial : hub and spoke

Le use-case le plus trivial est celui du hub&spoke. Le besoin fonctionnel est simple: je veux que tout le monde parle avec tout le monde.

Il est très simple à mettre en place avec Transit Gateway car il ne nécessite qu’une seule table de routage : on crée tous les attachments, on les associe tous à la TGWRT unique et on les propage tous sur cette même TGWRT unique.

On obtient alors ceci:

Et tout le monde parle avec tout le monde.

Cependant, en pratique, on ne veut pas forcément faire ça.

Dans le prochain article, nous verrons comment gérer à l’échelle un réseau plus complexe dans lequel des VPC doivent pouvoir se parler entre eux, d’autres pas, accéder au VPN ou pas, etc…

Bref, j’introduirais ma méthode pour gérer à l’échelle et faire évoluer un réseau arbitrairement complexe composé de multiple domaines de routage.