La plupart des diagrammes AWS échouent de la même façon : quelqu'un dépose trente icônes de services sur un canevas, les relie par des flèches et appelle cela une architecture. Cela a l'air chargé et ne dit presque rien, car ce qui compte vraiment dans une conception AWS, ce n'est pas la liste des services utilisés. Ce sont les frontières : ce qui est public, ce qui est privé, ce qui vit dans quelle zone, et où passent les lignes de confiance. Soignez les frontières et le diagramme devient pédagogique. Négligez-les et il n'est plus que décoration.
Construisez donc un diagramme AWS de l'extérieur vers l'intérieur, frontière par frontière, et ajoutez les services en dernier.
Commencez par les frontières, pas par les services
Voyez un diagramme AWS comme un ensemble de conteneurs imbriqués. Chacun est une frontière que le lecteur doit voir :
- Région : la boîte la plus extérieure. Tout s'y trouve (ou vous en dessinez deux pour un scénario multi-région).
- VPC : votre réseau privé à l'intérieur de la région.
- Zones de disponibilité : deux ou trois colonnes à l'intérieur du VPC, car c'est ainsi que l'on dessine la résilience.
- Sous-réseaux : des couloirs publics et privés dans chaque zone. Cette séparation est la ligne la plus importante de tout le diagramme.
Dessinez-les d'abord, sous forme de rectangles imbriqués, avant de poser le moindre service. Chaque ressource que vous ajoutez a alors sa place, et sa position a du sens : une base de données dans un sous-réseau privé dit quelque chose qu'une icône flottante ne pourrait jamais dire.
Ajoutez les services là où ils doivent être
C'est seulement maintenant que les services arrivent, et l'endroit où vous les placez constitue la documentation. Le répartiteur de charge se trouve dans le sous-réseau public ; les serveurs d'application sont en privé ; la base de données managée est au plus profond, privée et multi-zone. Un stockage objet ou un CDN vit en dehors du VPC, car c'est là qu'il se trouve réellement. Ici, le placement n'est pas décoratif ; il encode la posture de sécurité.
Dans un diagramme AWS, la position est l'argument. L'endroit où se trouve une boîte en dit plus que l'icône qu'elle porte.
Utilisez des icônes reconnaissables, avec modération
Les vraies icônes des fournisseurs aident un diagramme à se lire d'un coup d'œil : le lecteur repère la base de données, la file d'attente, le répartiteur de charge sans lire les libellés. Utilisez-les, mais ne les laissez pas devenir le sujet. Une icône claire par ressource, une taille cohérente et beaucoup d'espace blanc valent mieux qu'une mosaïque dense. Les frontières portent le sens ; les icônes accélèrent seulement la reconnaissance.
Générez le diagramme AWS depuis Terraform
Placer tout cela à la main est lent et devient obsolète dès que l'infrastructure change. Si vous gérez AWS avec Terraform, la topologie est déjà décrite : le VPC, les sous-réseaux, les instances et les services managés sont tous déclarés. Générez le diagramme à partir de là, et les frontières comme les ressources proviennent de la définition réelle, pas de votre souvenir. Ensuite, vous le façonnez : corriger la disposition, regrouper les tiers, mettre en évidence la bordure publique.
Finalisez pour le lecteur
Avant de le publier, faites une passe de lisibilité. La séparation public/privé est-elle impossible à manquer ? Peut-on suivre une requête depuis internet jusqu'à la base de données ? Les zones de disponibilité sont-elles visiblement distinctes pour que la résilience soit évidente ? Supprimez tout ce qui ne sert pas ces questions. Un diagramme ciblé qui y répond vaut mieux qu'un inventaire complet de toutes les ressources du compte.
Dessinez les frontières, placez les services selon leur niveau de confiance, gardez des icônes sobres et générez l'ébauche depuis Terraform pour qu'elle reste fidèle. Voilà un diagramme AWS que les gens utiliseront vraiment.