AWS-Architektur, in UML modelliert
Das übliche AWS-Diagramm ist eine Wand aus Dienst-Icons und sagt, welche Produkte Sie gekauft haben. Dies ist die andere Sorte: zwei Diagramme, die sagen, was was erreichen darf, über welchen Port, und welche Teile Ihnen zum Austauschen gehören.
8 Min. LesezeitUML 2.5.123 von 23
01Two kinds of AWS diagram
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.
02Reading the topology
Three things on the hero figure are worth copying into your own, and none of them is about AWS.
- 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.
- 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.
- The artifact sits inside the node that runs it.
api.jarinside 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.
03The same system without the vendors
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.
In one line each
- 01Icon diagrams name products; deployment diagrams name paths, protocols and ports.
- 02Draw the region as a containing node - nesting is the boundary, no arrow needed.
- 03Label every communication path with its protocol and port, or it has not been checked.
- 04Put artifacts inside the node that executes them.
- 05Leave IAM, logging and secrets off: they are configuration, not participants.
- 06Keep the component view separate - it survives the re-platforming that invalidates the topology.
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.
04Häufige Fragen
UML oder AWS-Icons für ein AWS-Architekturdiagramm?
Beides, für verschiedene Leser. Das Icon-Diagramm ist das bessere Vertriebs- und Einarbeitungsbild, weil jeder die Produkte erkennt; ein UML-Verteilungsdiagramm ist das bessere Arbeitsdokument, weil es Protokolle, Ports und Richtungen benennt - genau danach fragen ein Security-Review und ein Vorfall um drei Uhr nachts.
Wie stellt man eine VPC oder Region in UML dar?
Als Knoten, der die anderen enthält, gezeichnet durch Verschachtelung. Die Beziehung ist die Enthaltung selbst, ein Pfeil ist überflüssig, und die Grenzfrage - was liegt in der Region und was ausserhalb - steht im Bild statt in einer Legende.
Muss jeder genutzte AWS-Dienst gezeichnet werden?
Nein, und genau das macht solche Diagramme unbrauchbar. Nehmen Sie einen Dienst auf, wenn ein Anfragepfad ihn kreuzt oder er Zustand hält, den Sie migrieren müssten; lassen Sie weg, was Konfiguration statt Beteiligter ist - IAM, CloudWatch, Secrets Manager.
Wie verhindert man, dass ein Cloud-Diagramm nach einer Migration veraltet?
Teilen Sie es in zwei. Die Komponentensicht benennt Verträge, von denen Ihr Code abhängt, und übersteht einen Plattformwechsel unverändert; nur die Verteilungssicht muss sich ändern, womit aus einem kompletten Neuzeichnen die Bearbeitung eines Diagramms wird.
Passend dazu