- Pour comprendre les éléments complexes du tableau de bord AWS VPC, une carte mentale a été créée afin de visualiser d’un seul coup d’œil les relations entre les ressources réseau AWS
- L’ouvrage AWS Networking Fundamentals de Toni Pasanen a servi de référence principale pour organiser les ressources liées au networking en se concentrant sur leur structure de connexion
- Si le networking AWS devient complexe, c’est à cause de la variété des types de connexion, notamment entre compte et on-premise, compte à compte, VPC à VPC, subnet à subnet, VPC à Internet, et VPC à services AWS
- Le résultat est une carte mentale reliant entre eux les composants du networking AWS, avec aussi accès à l’original sur Lucidchart
- Les développeurs qui structurent AWS networking pour la première fois peuvent l’utiliser pour comprendre visuellement comment les différentes ressources s’articulent entre elles
La confusion née du tableau de bord VPC
- Jusqu’en mars 2023, il était difficile de comprendre ce qui se passait dans le tableau de bord VPC d’AWS
- Il y avait tellement d’éléments, avec une barre de défilement très longue dans le panneau de gauche, qu’il était difficile de voir comment chaque ressource était reliée aux autres
Sources de référence et angle d’organisation
- Pour comprendre les nombreuses ressources impliquées dans le networking AWS, la majeure partie de AWS Networking Fundamentals de Toni Pasanen a été lue
- Après la lecture, le constat a été que s’il existe autant de ressources de networking AWS, c’est parce qu’il existe de nombreuses méthodes de connexion possibles
Les types de connexion traités dans le networking AWS
- Le networking AWS inclut plusieurs types de connexion
- connexion entre un compte AWS et un environnement on-premise
- connexion de compte à compte
- connexion de VPC à VPC
- connexion de subnet à subnet
- connexion entre VPC et Internet
- connexion entre VPC et certains services AWS
Le résultat sous forme de carte mentale
- Pour relier toutes les pièces entre elles, les concepts de networking AWS ont été organisés en carte mentale
- La version originale éditable est disponible via ce lien Lucidchart
- Des retours sont demandés sur son utilité et sur d’éventuelles erreurs
1 commentaires
Commentaires Hacker News
Je ne comprends pas pourquoi le débogage des politiques IAM et des problèmes d’authentification est à ce point bancal sur AWS
Si quelqu’un veut devenir un concurrent, c’est là-dessus qu’il faut se concentrer. J’ai perdu des heures à chercher la cause d’une erreur d’absence d’autorisation, et la documentation officielle dit en gros de fouiller manuellement parmi environ 8 types de politiques pouvant s’appliquer, comme les SCP, IAM, les politiques de ressource, etc.
Au final, même quand on trouve la documentation qui utilise Athena et CloudTrail, la moitié des requêtes manque sans raison, et même si le message d’erreur contient un ID de requête, on ne peut pas facilement le retrouver avec ça. Il faudrait pouvoir interroger directement via l’ID de requête et voir clairement quelle politique a refusé l’accès
De bout en bout, c’est un chaos total, et on a presque l’impression qu’ils maintiennent cet état pour vendre davantage de contrats de support
Pour mes projets personnels, sauf cas très rares, je choisis presque toujours d’autres options qui offrent un meilleur rapport qualité-prix. Il y a une dizaine d’années, AWS se vendait en mode « nous gérons les systèmes, donc licenciez tous vos administrateurs système » ; aujourd’hui, les bons ingénieurs AWS DevOps sont chers et difficiles à trouver, et surtout, sur de grosses configurations, respecter correctement les recommandations AWS coûte énormément
Pour donner à une Function App l’accès à une base de données SQL, il suffisait d’utiliser le vrai nom de la Function App, et s’il y avait un alias, de le restreindre à l’identifiant d’objet. Plus besoin de mot de passe ni de certificat, et ça fonctionne, tout simplement
En utilisant aussi le package d’authentification et des choses comme Application Insights, à condition de savoir lire les logs, on reste rarement longtemps bloqué sur le « qu’est-ce qui s’est passé au juste ? »
Cela dit, Azure aussi exige de connaître à l’avance où sont les pièges, sinon on tombe dans des frustrations similaires. Microsoft laisse bien mieux qu’AWS des indices sur l’emplacement de ces pièges, mais certains indices utiles disparaissent commodément au moment critique, au point qu’il faut presque un magicien avec 20 ans d’expérience pour franchir le dernier voile et éviter que les coûts et la complexité n’explosent d’un facteur 5 à 10
Le débogage des comptes de service est encore plus pénible parce qu’il faut parfois redémarrer des machines ou des clusters. Un outil du type « traceroute cloud » capable de montrer exactement où se situe le problème serait formidable
Pour être juste, il existe des outils pour le moindre privilège que je n’ai pas encore essayés : IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
C’est vraiment agaçant, et ils devraient faire concevoir ça par des UX designers et des ingénieurs, mais ils ne le font pas
Si un tel service est fourni aux clients, il pourrait potentiellement l’être aussi aux attaquants, et cela pourrait effectivement violer les politiques de sécurité et de conformité de certaines entreprises
Malgré tout, je pense qu’il faudrait au moins laisser le choix au client s’il signe un document reconnaissant un gros risque, comme « faire des choses dangereuses avec l’utilisateur root AWS »
Comme les requêtes AWS sont très distribuées, une composition proche de GraphQL semblerait, conceptuellement, bien adaptée à ce type de système. Ce n’est pas non plus très éloigné de systèmes de traçage comme OTEL
C’est pour ça que je déteste devoir toucher à AWS. Apprendre ça, ce n’est pas de la connaissance technique, c’est de la connaissance produit
J’ai lu la série TCP/IP Illustrated du début à la fin et je l’ai complètement assimilée, et ce savoir m’a été utile pendant des décennies
À l’inverse, la connaissance d’AWS est certes complexe en soi, mais elle me donne chaque fois envie de refuser de l’apprendre. Quand je vois ce diagramme, si l’objectif était la simplification, je ne sais pas vraiment à quel point c’est une réussite
Par exemple, si le but est de permettre aux clients enterprise de reproduire un réseau d’entreprise virtuel ou un réseau de datacenter virtuel, ceux-ci sont bien plus complexes qu’une pile TCP côté client
Pour les usages simples, les valeurs par défaut sont simples elles aussi. Pour les cas complexes, il faut certes des connaissances produit propres à AWS, mais la plupart des concepts sous-jacents sont partagés avec d’autres clouds ou avec les réseaux on-premise. C’est un peu comme apprendre un N-ième langage de programmation
TCP/IP est un savoir utile aux programmeurs réseau. En cours de réseau à l’université, on manipulait des réseaux, sous-réseaux, tables de routage, protocoles de routage comme RIP·OSPF·BGP, NAT, etc., sur du vrai matériel, et comme le cursus était très sponsorisé par Cisco, à la fin du semestre on avait à peu près le niveau d’une certification CCNA
On a aussi appris beaucoup de « connaissance produit », comme le fonctionnement des produits Cisco, mais j’en ai oublié l’essentiel, et les concepts de base se transfèrent très bien à Azure, AWS et GCP. Les VPC du cloud sont le pendant virtuel des réseaux réels, comme les machines virtuelles sont le pendant des machines réelles
En particulier, NAT embrouille vraiment les gens. Plus fondamentalement, beaucoup d’ingénieurs ont aussi du mal avec la notation CIDR, voire avec TCP lui-même. Par exemple, ils pensent que le buffer passé à
send()est envoyé comme une seule unité, ou querecv()reçoit toujours un « message » complet. La différence entre un timeout de connexion et un reset par le pair prête aussi souvent à confusionCela dit, j’aimerais qu’on n’ait pas besoin de ces connaissances. IPv6 rend les réseaux tellement vastes que cela élimine en grande partie les questions comme la planification de la taille des sous-réseaux. NAT peut bien disparaître dans un enfer glacé. Je serais ravi de ne plus jamais revoir de VPN non plus, il suffit d’utiliser TLS. J’aimerais aussi faire disparaître les pare-feu cloud qui utilisent les adresses IP comme mécanisme d’authentification, ainsi que les erreurs trompeuses que cela entraîne. Azure est atroce sur ce point
Comme beaucoup de logiciels professionnels, c’était simple au départ par nécessité, puis c’est devenu complexe avec le temps, et AWS a gonflé très vite grâce à l’attrait d’un service d’infrastructure entièrement managé à la demande et aux ressources colossales qu’Amazon y a consacrées
La valeur de ne pas avoir à gérer directement le matériel reste énorme, mais au-delà du prix affiché, on paie clairement aussi le coût d’une connaissance propriétaire difficile à migrer, propre au fournisseur
À la place, on a une accumulation de concepts à usage unique comme « internet gateway », « NAT gateway », « egress only internet gateway » et « transit gateway ». Au final, on risque de voir émerger une génération d’ingénieurs qui ne comprendront que le « cloud », sans savoir comment ça fonctionne réellement
Il suffit de déléguer à AWS tous les composants « non différenciants » et de se concentrer sur le métier où l’on est vraiment bon
Si AWS avait simplement fourni un adressage global classique et des pare-feu, l’essentiel de cette complexité aurait disparu
On oublie facilement à quoi sert Internet au niveau IP et quels problèmes l’architecture de bout en bout résout
Ce qu’AWS enseigne comme du networking « Well-Architected™ » relève en réalité davantage d’un culte du cargo rentable, et cela mène à la complexité, à des labyrinthes de réseaux 10.x qui se ressemblent tous, à des collisions d’adresses, à des proxys bricolés quand on essaie de les faire communiquer entre eux, à une sécurité réelle dégradée et à l’enfermement propriétaire. La complexité est l’ennemie de la sécurité
Les anciens administrateurs système n’étaient pas payés la moitié ou le quart de ma rémunération, et ils géraient généralement assez de matériel pour couvrir 100 développeurs à eux seuls. Pour tous les autres, le surcoût nécessaire pour éviter cette extension de périmètre et ces dégâts cérébraux représentait donc quelque chose comme 0,5 %
Sur AWS, on assiste encore une fois à une véritable mort de l’expertise
Et pour l’adressage global et les pare-feu, on peut déjà plus ou moins faire ça en créant un VPC avec uniquement des sous-réseaux publics et en utilisant les security groups comme pare-feu, non ? Les bonnes pratiques recommandent des sous-réseaux publics/privés et des NAT gateways, mais il ne me semble pas impossible de ne s’appuyer que sur les security groups
Le tout derrière des IP anycast globales
C’est ce qui crée une grande partie de la complexité inutile qu’on voit dans le networking cloud
Cette carte mentale pourrait sans doute être encore simplifiée autour de quelques concepts réseau.
La plupart des relations et des flèches disparaîtraient alors, et on pourrait faire correspondre les concepts AWS à d’autres clouds ou même à un réseau domestique.
https://news.ycombinator.com/item?id=18925350 est une excellente ressource qui visualise très bien les bases. Si on commence par ce qu’est un réseau, ce qui est à l’intérieur et ce qui est à l’extérieur, le modèle mental devient bien plus simple, et les fonctionnalités AWS paraissent assez logiques même sans en connaître tous les détails.
Au final, il résume clairement et de façon concise un système complexe. Ce sera une ressource à laquelle je reviendrai la prochaine fois que je devrai me frayer un chemin dans la forêt AWS.
Par exemple, un subnet dans un rectangle de zone de disponibilité, lui-même dans un VPC, lui-même dans une région. Ça ressemble grosso modo à ça, mais en plus joli : https://images.edrawsoft.com/articles/aws-diagram-examples/e...
Je me souviens avec nostalgie des débuts du cloud, quand le networking AWS était simple.
Cela dit, on savait bien que ça finirait par arriver. Si on veut être tout pour tout le monde, on finit forcément par reproduire la folie du networking de datacenter IPv4 hérité.
J’ai récemment essayé de faire quelque chose de conceptuellement simple sur Azure : éviter qu’un compte de stockage contenant des sauvegardes de base de données soit exposé à Internet et puisse être sondé par n’importe qui.
Je pensais qu’il suffirait d’activer le pare-feu, mais la liste d’autorisation n’acceptait que des subnets, et encore, un par un. Pas de réseau virtuel entier, et même pas l’option “tous mes réseaux virtuels” qui existe ailleurs.
Il y a aussi la fonction Private Endpoint, mais elle dégrade les performances et ajoute des coûts. J’imagine qu’il faut bien récompenser les fées du cloud pour le dur labeur consistant à changer une adresse de “public” à “private” dans une configuration de réseau défini par logiciel.
Sauf qu’en pratique ça ne marche pas. Il faut écraser le DNS pour que les clients trouvent la bonne cible, et dès qu’on l’a rattaché au domaine AD, les services PaaS n’ont plus pu y accéder.
On a donc fini par créer une zone DNS privée supplémentaire, la relier au réseau hub, y ajouter le service DNS Resolver lui aussi payant, puis passer une semaine à configurer une montagne de règles pour que le domaine AD continue de fonctionner.
Au départ, je voulais juste éviter qu’un hacker russe puisse accéder aux sauvegardes si la clé de stockage fuyait. Peut-être que la semaine prochaine j’arriverai aussi à mettre à jour le template d’abonnement pour redéployer les réseaux virtuels avec la configuration DNS mise à jour. Pas idempotent ? Peut-être en preview l’an prochain.
Ensuite, pour l’exposition publique, il suffit d’utiliser une public gateway ou Front Door. Je n’aime pas ça, mais ça n’a jamais été complètement simple non plus. C’est surtout que le chaos absolu du networking d’entreprise, autrefois strictement réservé aux ops, est maintenant beaucoup plus visible pour les développeurs.
Je parle de magie parce que le DNS fait partie de ces domaines qu’on évite de toucher à la main. Surtout qu’avec App Service et plusieurs abonnements, on ne peut pas partager les subnets, et si on utilise des slots d’application il faut planifier à l’avance pour ne pas manquer d’espace d’adressage IP.
Ce que je ne comprends pas sur Azure, c’est pourquoi le réglage par défaut en environnement entreprise n’est pas “rien n’est sur Internet”. On devrait ouvrir seulement ce qui doit être exposé. De toute façon, publier quelque chose sur Internet est déjà complexe par nature, puisqu’il faut configurer plusieurs éléments comme le load balancer. Au minimum, même en configuration entreprise, le défaut devrait être hors d’Internet.
Microsoft vend peut-être des certifications Azure et a donc intérêt à rendre ça difficile, mais je ne comprends pas pourquoi, en 2023, il faut encore se soucier de cette complexité dès les réglages par défaut. Qu’il y ait beaucoup de possibilités de personnalisation, très bien.
Cette ressource est vraiment très bien. J’ai souvent trouvé que la documentation Google Cloud introduisait assez bien ce type de complexité au moment où on en a besoin, mais je n’avais jamais vu une vue d’ensemble aussi complète.
En revanche, il a fallu se battre pour voir l’image. Sur la page elle est trop petite et on ne peut même pas cliquer dessus ; en l’ouvrant dans un nouvel onglet, on tombe sur une page inutile façon imgur où elle reste minuscule. J’ai finalement dû télécharger l’image pour pouvoir la voir correctement.
Cette ressource est impressionnante. Elle montre bien à quel point les cartes mentales et les diagrammes sont puissants pour apprendre des produits cloud ou d’autres concepts.
J’en utilisais beaucoup quand je préparais les certifications AWS, et même en prenant de longues notes, je comprenais bien mieux en voyant les services reliés dans une carte qu’en les lisant comme une succession de pages. Bien sûr, chacun apprend différemment.
Je ne comprends pas vraiment toutes les critiques dans ce fil. La plupart des systèmes réseau proposés par AWS s’utilisent quand on en a besoin.
Ce n’est peut-être pas élégant, mais ça fait le travail. Et une bonne partie des composants spécifiques à AWS correspondent directement à de vrais concepts réseau. Une AZ, c’est un cage ; un VPC, un VLAN ; un PL correspond à peu près à un VPN P2P entre comptes.
La plupart du reste, ce sont des composants réseau classiques qu’on retrouve dans des environnements de grande taille.
L’entreprise où je travaille exploite un réseau mondial assez complexe, connecté à AWS via DX depuis plusieurs PoP. Nous utilisons tout ce qui figure sur ce diagramme, et chaque composant a un objectif bien défini.
Si ce diagramme vous semble excessivement complexe, c’est probablement parce que vous n’utilisez pas tout cela, ou pas pour l’usage prévu, ou alors parce que vous n’êtes pas ingénieur réseau.
Est-ce qu’il y a vraiment quelqu’un qui arrive à lire l’image ? Même sur desktop, je n’arrive pas à l’afficher dans une résolution lisible.
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... reste une page web ; l’image est plus grande, mais pas plus lisible.
En l’enregistrant, ça marche au moins. Ensuite, il faut un grand écran. La taille est de 7 763 × 4 684 pixels.
Ça a l’air extrêmement complexe. Parmi les trois grands fournisseurs de cloud, je ne connais que GCP, et même là le réseau n’est pas simple, mais c’est quand même assez intuitif et cohérent dans une certaine mesure
J’aimerais bien que quelqu’un ayant davantage d’expérience multi-cloud compare, pour le top 3, le degré de facilité ou de difficulté de la configuration des communications internes et externes
Ce n’est pas vraiment surprenant, puisque la plupart ont aussi un équivalent direct dans les standards réseau eux-mêmes. Au fond, les deux ne sont qu’une manière d’aborder le monde du software-defined networking.