Architecture AWS, modélisée en UML

The familiar one is a canvas of service icons with lines between them. It is genuinely good at one job - showing which products are in play to somebody who already knows what those products do - and it is why every AWS deck contains one.

What it does not carry is direction, protocol, port, or whether a line means "calls over the network" or "is configured by". Those four are the entire content of a security review, and they are what somebody staring at an alert at 3am is trying to reconstruct. A deployment diagram carries them, at the cost of looking less like a brochure.

Three things on the hero figure are worth copying into your own, and none of them is about AWS.

1. The region is a box, not a label. Nesting is the containment relationship, so the boundary question - what is inside eu-central-1 and what is not - is answered by geometry rather than by a legend. The browser being outside it is the most important fact on the diagram.
2. Every path carries a protocol and a port."HTTPS", "TCP 5432". An unlabelled line between a load balancer and a service is a line that has never been checked against a security group.
3. The artifact sits inside the node that runs it. api.jar inside the Fargate service, rather than beside it with an arrow. What is deployed where is the question this diagram kind exists for.

What is deliberately absent: IAM, CloudWatch, Secrets Manager, the NAT gateway. Every one is real and none of them is a participant in a request path - they are configuration, and putting them on the diagram doubles its size while answering no question anybody asked.

This is the diagram that makes cloud architecture reviewable rather than merely documented. The Order API depends on IOrderStore and IFileStore; the adapters name the products. Everything above the adapters is portable by construction, and everything that is not portable is in two boxes you can count.

It is also the half that does not change when the infrastructure does. Move from ECS to EKS, or from eu-central-1 to two regions, and the hero figure is redrawn while this one is untouched - which is the practical reason to keep them apart rather than merging them into one impressive picture.

The same treatment applied to a shop is in e-commerce architecture, modelled, and the service-boundary question is taken further in the microservices example.