Architecture AWS, modélisée en UML

Le familier est une toile d'icônes de services reliées par des traits. Il est vraiment bon pour une seule chose - montrer quels produits sont en jeu à quelqu'un qui sait déjà ce que ces produits font - et c'est pourquoi tout support de présentation AWS en contient un.

Ce qu'il ne porte pas, c'est le sens, le protocole, le port, ni si un trait veut dire "appelle par le réseau" ou "est configuré par". Ces quatre-là sont tout le contenu d'une revue de sécurité, et c'est ce que quelqu'un devant une alerte à trois heures du matin essaie de reconstituer. Un diagramme de déploiement les porte, au prix de ressembler moins à une brochure.

Trois choses de la figure d'ouverture méritent d'être reprises dans la vôtre, et aucune ne concerne AWS.

1. La région est une boîte, pas une étiquette. L'imbrication est la relation de contenance, donc la question de frontière - qu'y a-t-il dans eu-central-1 et qu'y a-t-il dehors - est tranchée par la géométrie plutôt que par une légende. Que le navigateur soit à l'extérieur est le fait le plus important du diagramme.
2. Chaque chemin porte un protocole et un port."HTTPS", "TCP 5432". Un trait non étiqueté entre un répartiteur de charge et un service est un trait qui n'a jamais été confronté à un groupe de sécurité.
3. L'artefact est à l'intérieur du noeud qui l'exécute. api.jar dans le service Fargate, et non à côté avec une flèche. Ce qui est déployé où est la question pour laquelle cette sorte de diagramme existe.

Ce qui est délibérément absent : IAM, CloudWatch, Secrets Manager, la passerelle NAT. Chacun est réel et aucun n'est participant d'un chemin de requête - ce sont des configurations, et les mettre sur le diagramme double sa taille sans répondre à une question que quiconque a posée.

C'est le diagramme qui rend une architecture cloud relisable plutôt que simplement documentée. L'Order API dépend de IOrderStore et IFileStore ; les adaptateurs nomment les produits. Tout ce qui est au-dessus des adaptateurs est portable par construction, et tout ce qui ne l'est pas tient dans deux boîtes que l'on peut compter.

C'est aussi la moitié qui ne change pas quand l'infrastructure change. Passez d'ECS à EKS, ou d'eu-central-1 à deux régions, et la figure d'ouverture est redessinée tandis que celle-ci reste intacte - la raison pratique de les garder séparées plutôt que de les fondre en une seule image impressionnante.

Le même traitement appliqué à une boutique est dans l'architecture e-commerce, modélisée, et la question des frontières de service est poussée plus loin dans l'exemple microservices.