Dans mon article précédent, nous avons vu les principaux composants et concepts d’AWS Transit Gateway. Dans cet article, je vais présenter ma méthode pour facilement configurer Transit Gateway pour créer des réseaux complexes. Avant cela, il reste encore un tout dernier concept à explorer que je n’ai pas traité dans le dernier article pour éviter de trop le charger. Parlons un peu de trous noirs.

Les blackhole

Ceux qui ont une expérience avec les tables de routage des VPC ont peut-être déjà rencontré des routes « blackhole » sur leurs tables de routage. Ce phénomène se produit lorsque que la cible d’une route cesse d’exister (par exemple, une NAT instance qui a été stoppée ou terminée), l’API signale alors que la route est un « blackhole », c’est à dire une route qui ne mène nulle part.

Dans les tables de routage des VPC, c’est un phénomène qui se produit dans des circonstances anormales (c.a.d une cible est inatteignable) mais sur les Transit Gateway Route Table (TGWRT) c’est une option explicite : on peut choisir de créer une route « blackhole ». Et on peut donc se poser la question : mais pourquoi diable voudrait-on explicitement faire une route qui ne mène nulle part ?

Pour le comprendre, on peut étudier l’exemple d’une configuration dans laquelle la Transit Gateway est utilisée pour centraliser la sortie vers l’Internet, c’est à dire qu’on veut que tous les VPC accèdent à Internet via un VPC dédié à cet effet (par exemple pour contrôler les flux de sortie et répondre à des contraintes de conformité réglementaire). En revanche, on ne veut pas pour autant que les VPCs puissent se parler entre eux : ils doivent être isolés. On pourrait alors mettre en place cette configuration :

Les VPCs « Apps » sont associés à une TGWRT avec une route par défaut menant au VPC « Outbound ». Le VPC « Outbound » est quant à lui associé à une TGWRT dans laquelle tous les attachments des VPC « Apps » sont propagés (en plus ça nous fait une petite révision du vocabulaire expliqué dans le précédent article). Par ailleurs, chaque VPC « Apps » a une route par défaut vers la Transit Gateway. De fait, un des objectifs est atteint : tous les VPCs peuvent en effet atteindre Internet au travers du VPC « Outbound » :

Mais est-ce que les VPCs « Apps » sont bien isolés ? On serait tenté de répondre oui car, après tout, la TGWRT à laquelle ils sont associés ne contient aucune route vers les VPCs « Apps », seulement vers « Outbound ». Mais regardons ce qui se passerait si l’un des VPC essayait de parler à l’autre :

Et oui ! Le flux se retrouve en réalité à « rebondir » par le VPC « Outbound », et la communication est possible. Et c’est là que les blackholes explicites entrent en jeu :

Maintenant tous nos objectifs sont atteints, les VPCs sortent tous vers Internet via un « Outbound » centralisé et ils ne peuvent pas communiquer entre eux.

Pour résumer grossièrement, les blackholes nous servent à garantir que des VPCs (plus largement des attachments) ne peuvent pas communiquer.

PS : notez qu’il n’y a pas toujours de jeux de « rebonds » possibles et donc pas toujours besoin de blackhole, mais comme il est potentiellement compliqué de s’assurer que les rebonds sont impossibles alors que les blackholes sont faciles à mettre en place et gratuits… pourquoi s’en priver ? 🙂

Un use-case relativement complexe

Passons maintenant au coeur de notre sujet et considérons la situation suivante :

On souhaite que les consignes suivantes soient respectées :

• Tous les VPCs (Apps & Shared Services) doivent communiquer 1/ avec Internet en passant par le VPC Outbound et 2/ avec le réseau Corp en passant par le VPN ;
• Tous les VPCs “Apps” doivent communiquer avec le VPC Shared Service, quel que soit leur environnement ;
• Les VPCs de l’environnement “Dev” ne doivent pas communiquer avec ceux de l’environnement “Prod” ;
• Les VPCs des différentes applications ne doivent pas communiquer entre eux ;
• Le VPN et le VPC Outbound ne doivent pas communiquer.

La question est bien sûr : comment devrait-on configurer la Transit Gateway ? De combien de Transit Gateway Route Tables a-t-on besoin ? Quelles routes ?

Pas évident à première vue n’est-ce pas ? Heureusement il y a findus les bulles !

Une histoire de bulles

J’appelle ça des “bulles” parce que la première fois que j’ai été confronté à ce genre de problèmes, j’ai fait des dessins au tableau blanc et j’entourais des groupes de VPC en faisant les explications, et ça m’a fait penser à des bulles. On a échappé de peu à ce que je vous fasse un article sur les patates…

Depuis je suis sorti de ma grotte à plusieurs reprises, et il semble que le monde entier appelle ça des “domaines de routage”… C’est moins drôle. Donc je vais rester sur mes bulles.

L’important de toute façon, ce n’est pas le nom, ce sont les propriétés. Il n’y en a que deux ! Une bulle se définit par:

• la liste des “attachments” (VPC, VPN, …) qu’elle contient ;
• la liste des bulles avec lesquelles la communication est autorisée (y compris elle-même le cas échéant).

On verra que la seconde propriété est la plus importante.

Voyons comment définir nos bulles.

Etape 1 – Remplir les bulles

Pour commencer, il faut remplir les bulles, c’est à dire regrouper ensemble certains attachments.

En théorie, il faut regrouper les attachments qui doivent être routés de la même manière, qui doivent obéir aux mêmes règles de communication. En effet, il ne faut pas perdre de vue la principale propriété de nos bulles : “qui parle avec qui”.

En pratique, ce n’est pas forcément facile de faire ce regroupement correctement en un coup d’oeil. De fait, on peut simplement commencer par faire des regroupements logiques : par environnement ou par type de VPC par exemple. Souvent, ça marchera très bien comme ça, d’autant que nous allons voir que les étape 1 et 2 peuvent être itératives ; donc il n’y a pas vraiment de problème à se tromper. Pour finir, il vaut mieux commencer par faire trop de bulles plutôt que pas assez (c’est plus facile à corriger rapidement).

Dans notre cas, on va définir les bulles suivantes :

Une bulle “Shared Services” contenant le VPC Shared Service tout seul, parce qu’on sent que c’est un cas à part entière, une bulle “Networks” avec le VPC Outbound et le VPN, et puis une bulle pour chaque environnement : “Apps Dev” et “Apps Prod”. 

Passons à l’étape importante.

Etape 2 – Définir les communications entre bulles

Maintenant que nous avons nos bulles, il faut déterminer pour chacune la liste des bulles avec lesquelles elle peut communiquer. Pour cette étape, la méthode est simple, on reprend l’énoncé point par point !

Tous les VPCs (Apps & Shared Services) doivent communiquer avec Internet en passant par le VPC Outbound et avec le réseau Corp en passant par le VPN

Ok, on signale ça sur notre schéma.

Tous les VPCs “Apps” doivent communiquer avec le VPC Shared Service, quel que soit leur environnement.

Les VPCs de l’environnement “Dev” ne doivent pas communiquer avec ceux de l’environnement “Prod”.

Les VPCs des différentes applications ne doivent pas communiquer entre eux.

Là, notez que c’est une consigne qui nous permet de dire que les bulles “Apps Dev” et “Apps prod” ne doivent pas pouvoir communiquer avec elles-mêmes.

Le VPN et le VPC Outbound ne doivent pas communiquer.

De même, pas de communication avec elle-même pour la bulle “Networks”

Et il nous manque un statut : est-ce que la bulle “Shared Services” communique avec elle-même ? Vu qu’il n’y a qu’un seul VPC dedans, la question n’a pas vraiment de sens. Mais si nous avions plusieurs VPCs de Shared Service, il paraîtrait logique qu’ils puissent communiquer entre eux. Donc on complète :

Ici, vous pouvez constater que tout se passe assez facilement : chaque énoncé est facile à refléter dans notre schéma. Vous pourriez un jour avoir une situation dans laquelle une contradiction apparaîtrait. Pas de panique, ça serait simplement le signe que vous n’avez pas fait suffisamment de bulles. Il suffira alors de couper en deux la ou les bulles pour lesquelles la contradiction apparaît.

Sachez qu’il y a toujours une solution (sauf si l’énoncé lui-même dit une chose et son contraire comme “A et B parlent” et “B et A ne parlent pas”) : dans le cas le plus extrême, chaque bulle ne contient qu’un seul VPC.

Il y aura aussi souvent des cas où il y a plus de bulles que nécessaire, on s’en rend compte facilement en présentant les choses sous forme de tableau :

On s’aperçoit là facilement que les lignes “Apps Dev” et “Apps Prod” sont identiques : cela signifie qu’on peut les réunir en une seule bulle. Et c’est tout simplement comme ça qu’on peut détecter les bulles en trop.

Mais dans notre cas, je vais laisser les choses comme ça : avoir des bulles en trop n’est pas gênant et j’aime le fait d’avoir des bulles séparées pour la dev et la prod, c’est plus logique. Et puis peut-être qu’une évolution future de mon réseau viendra différencier ces bulles, c’est possible !

Maintenant, toutes nos bulles sont bien définies : on sait pour chacune ce qu’elle contient et avec quelles bulles elle communique. Que faire de ces informations ?

Etape 3 – Traduire nos bulles en configuration Transit Gateway

La beauté de la chose, c’est qu’on peut traduire nos bulles de manière complètement systématique en configuration Transit Gateway. C’est trivial et ça tient en 4 règles :

• à chaque bulle correspond une (et une seule) Transit Gateway Route Table (TGWRT) dédiée ;
• dire qu’un VPC (ou VPN) appartient à une bulle signifie que l’attachment correspondant est associé à la TGWRT de la bulle ;
• dire que la bulle “A” communique avec la bulle “B” signifie que les attachments associés à la TGWRT “A” sont propagés dans la TGWRT “B” (et inversement) ;
• dire que la bulle “A” ne communique pas avec la bulle “B” signifie que les attachments associés à la TGWRT “A” (en fait, les CIDRblock de ces attachments) sont des blackholes dans la TGWRT “B” (et inversement).

Dans notre cas, on a donc 4 TGWRT à faire avec les associations, propagations et blackholes correspondants. Avec l’ajout de CIDRblocks dans notre situation, la configuration sera comme suit :

Vous pouvez vérifier, ça répond parfaitement à l’énoncé !

Alors, certes, ça fait beaucoup de routes… En pratique, ça fait même souvent plus de routes que nécessaire d’ailleurs. Mais ce n’est pas grave : Transit Gateway supporte 10 000 routes dans 20 TGWRT, et ce sont des soft-limits, donc pas d’inquiétude là-dessus. Ce qui compte, c’est que la méthode est simple !

Par contre, vous pourriez me dire “Mais Jérémie, c’est l’enfer à faire à la main !”, et je vous répondrais que vous avez raison. C’est pour ça que dans le prochain article, nous verrons qu’en plus d’être simple, la méthode est surtout automatisable !