Après 20 heures de transit vers Las Vegas et quelques heures de sommeil, nous voilà sur les starting blocks pour débuter notre semaine.
Samuel et moi nous vous présentons la 1ere session de la journée du Lundi à laquelle nous assistons :
Pour ceux qui n'ont pas eu l'opportunité d'assister à un précédent re:Invent il faut savoir que la zone que couvre les hôtels de l'événement est juste gigantesque. Nous trouvant dans un des hôtels du sud, il nous a fallu une bonne heure pour atteindre la salle de conférence du Mirage hôtel.
Mais assez parlé de nos aventures, allons au coeur du sujets les stratégies à adopter et nouveautés sur AWS Transit Gateway.
Vous le savez peut être certainement, AWS Transit Gateway n’est pas un nouveau service. Effectivement ce service à été annoncé il y a un an mais c’est certainement son expérimentation sur une année qui permet aujourd’hui de proposer des stratégies et des évolutions pertinentes. Des évolutions clairement en phase avec les besoins des clients d’AWS qui nagent dans le casse tête des interconnexions réseaux.
L’idée générale est de simplifier le travail pour les personnes qui s’occupent de monter des réseaux et de les interconnecter (à l’échelle mondiale !!)
Notions de bases
Rappelons quelques composants nécessaires lorsqu’on fait du réseau sur le Cloud AWS :
- VPC : Virtual Private Cloud permet d'isoler une section de manière logique et dans laquelle vous pouvez lancer des ressources AWS dans un réseau virtuel.
- VPN & DirectConnect (DX) : pour connecter vos infrastructures “onPremise” avec vos VPCs
- VPC Peering : Établissement d’un lien réseau entre 2 VPCs. N’oubliez pas qu’un peering n'est pas transitif.
- VPC Private Link : Établissement d’un lien privé (non exposé sur Internet) entre 2 VPCs, mais orienté “application” : vous aurez besoin d’un NLB pour joindre une application (Support des ALBs annoncé sur la fin de l’année 2020)
Enfin, à l’intérieur d’un VPC, vous avez déjà la possibilité d’ajouter de la segmentation avec IAM, les Security Groups et les NACLs.
Un service contre la complexité
Une fois les composants réseau interconnectés avec tout çà, il est nécessaire de mettre en place les routes. Et c’est là que les difficultés commencent (restriction d’accès entre plusieurs environnements par exemple)
Voici une “capture live” d’une architecture de référence avec la Transit Gateway :
La transit Gateway fonctionne avec des policies. Ces policies permettent de propager tout ou partie des sous-réseaux attachés à la transit Gateway. Ainsi, il est possible d’autoriser la connectivité sur tous vos VPCs avec un compte “Shared Service” qui contiendrait votre outil d’indexation de logs, vos fichiers partagés, etc… Vous pouvez publier une route sur une base de données de production à travers un VPN sans pour autant qu’elle soit accessible sur des VPC "non production"..
Le service permet de centraliser les échanges réseaux, de dé-complexifier les interconnexions et garder un niveau de sécurité adapté à ses exigences.
Une stratégie de taille
Nick Matthews Principal Solutions Architect chez AWS nous conseille de rester sur une segmentation orientée réseau et infrastructure pour des petites Landing zones (peu de compte, peu de VPC).
Cependant dès que nous visons des infrastructures “plat de spaghetti” avec beaucoup d’interconnexions, c'est justement ici qu’intervient AWS Transit Gateway.
Cas particulier
Si un développeur demande un lien en désaccord avec la matrice des interconnexions peut-être est-il plus pertinent de partir sur un autre service pour ce cas là. Nous pouvons par exemple évoquer Private Link ou les VPC Peering.
Nick Matthews nous a également présenté des uses cases d’utilisation de la Transit Gateway qui mérite d’être cités :
- Conserver vos IP voir les centraliser grâce au service Transit Gateway
- Gérer de manière avancée les ingress et egress à l’échelle globale de votre infrastructure.
- Attachement d’interfaces vs Propagation via la transit Gateway
STNO - Serverless Transit Network Orchestrator
C’est une nouvelle brique qu’AWS nous présente ici : la possibilité de gérer l’association entre d’une part la Transit Gateway et d’autre part des Comptes AWS. Cette brique est entièrement serverless (comprendre c’est une fonction lambda qui s’occupe d'effectuer les opérations pour vous) et se base sur la présence de tags spécifiques sur vos VPC & Subnets.
Ci-joint le schéma global :
(https://aws.amazon.com/fr/solutions/serverless-transit-network-orchestrator/
Cette brique est complétée avec :
une interface qui vous permet de suivre l’historique des actions
un système d’approbation : En effet, un composant “State Machine” est implémenté notamment lorsque le rattachement à un réseau est trop sensible pour que ce soit automatisable.
Conclusion
Ne nous voilons pas la face : La partie “Netwok” des infrastructures est compliquée. Commencez simplement avec Transit Gateway. Puis, petit à petit intégrer plus de connexions avec vos VPN, direct Connect, VPC ou encore vos services partagés.
Ne partez pas sur ce service si vous n’avez pas une infrastructure réellement dimensionnante.
Le coût peut sembler assez élevé et complexe à prévoir. Toutefois dans certains cas l’opération peut être rentable. Au lieu d’avoir 3 Nat gateway par VPC nous pouvons imaginer 3 Nat Gateway par région à travers la Transit Gateway. Nous pouvons penser à plein d’autres cas où la Transit Gateway permet de rendre des ressources communes et partagées.
Intégrez des services et procédures de sécurité dans l’élaboration de votre architecture réseau.
Faites vous aider par des partenaires AWS tel que Ippon Technologies qui accompagne au quotidien ses clients sur des problématiques d’infrastructure dimensionnante, scalable et résiliente.
