Die meisten AWS-Diagramme scheitern auf dieselbe Weise: Jemand wirft dreißig Service-Icons auf eine Leinwand, verbindet sie mit Pfeilen und nennt das Architektur. Es sieht geschäftig aus und sagt fast nichts, denn was in einem AWS-Design wirklich zählt, ist nicht, welche Services du benutzt hast. Es sind die Grenzen: was öffentlich ist, was privat ist, was in welcher Zone lebt und wo die Vertrauenslinien verlaufen. Stimmen die Grenzen, lehrt das Diagramm etwas. Fehlen sie, ist es Dekoration.
Bau ein AWS-Diagramm also von außen nach innen, Grenze für Grenze, und füge die Services zuletzt hinzu.
Beginne mit den Grenzen, nicht mit den Services
Stell dir ein AWS-Diagramm als eine Reihe verschachtelter Container vor. Jeder ist eine Grenze, die Lesende sehen müssen:
- Region: der äußerste Kasten. Alles lebt in einer (oder du zeichnest zwei für eine Multi-Region-Geschichte).
- VPC: dein privates Netzwerk innerhalb der Region.
- Availability Zones: zwei oder drei Spalten innerhalb der VPC, denn so zeichnest du Ausfallsicherheit.
- Subnetze: öffentliche und private Bahnen innerhalb jeder Zone. Diese Trennung ist die wichtigste Linie im ganzen Diagramm.
Zeichne diese zuerst als verschachtelte Rechtecke, bevor auch nur ein einziger Service platziert wird. Jetzt hat jede Ressource, die du hinzufügst, ein Zuhause, und ihre Position trägt Bedeutung: Eine Datenbank in einem privaten Subnetz sagt etwas, was ein frei schwebendes Icon nie könnte.
Füge die Services dort hinzu, wo sie hingehören
Erst jetzt kommen die Services dazu, und wo du sie platzierst, ist die Dokumentation. Der Load Balancer sitzt im öffentlichen Subnetz; die Anwendungsserver sitzen privat; die gemanagte Datenbank sitzt am tiefsten, privat und über mehrere Zonen verteilt. Ein Object Store oder ein CDN liegt außerhalb der VPC, weil er tatsächlich dort ist. Die Platzierung ist hier keine Dekoration; sie kodiert die Sicherheitslage.
In einem AWS-Diagramm ist die Position das Argument. Wo ein Kasten sitzt, sagt mehr als das Icon darauf.
Nutze erkennbare Icons, aber sparsam
Echte Icons des Anbieters helfen, ein Diagramm auf einen Blick zu lesen: Wer es liest, erkennt die Datenbank, die Queue, den Load Balancer, ohne Beschriftungen zu lesen. Nutze sie, aber lass sie nicht zur Hauptsache werden. Ein klares Icon pro Ressource, einheitliche Größen und viel Weißraum schlagen ein dichtes Mosaik. Die Grenzen tragen die Bedeutung; die Icons beschleunigen nur das Erkennen.
AWS-Diagramm aus Terraform: erzeuge den Entwurf
All das von Hand zu platzieren, ist langsam und veraltet, sobald sich die Infrastruktur ändert. Wenn du AWS mit Terraform verwaltest, ist das Layout bereits beschrieben: die VPC, die Subnetze, die Instanzen und die Managed Services sind alle deklariert. Erzeuge das Diagramm daraus, und Grenzen wie Ressourcen kommen aus der echten Definition, nicht aus deiner Erinnerung daran. Dann formst du es: Layout korrigieren, Schichten gruppieren, den öffentlichen Rand hervorheben.
Mach es fertig für die Lesenden
Bevor du es veröffentlichst, prüfe die Lesbarkeit. Ist die Trennung zwischen öffentlich und privat unverkennbar? Kann jemand eine Anfrage vom Internet bis zur Datenbank nachverfolgen? Sind die Availability Zones sichtbar getrennt, sodass die Geschichte der Ausfallsicherheit offensichtlich ist? Streiche alles, was diesen Fragen nicht dient. Ein fokussiertes Diagramm, das sie beantwortet, schlägt ein vollständiges Inventar aller Ressourcen im Account.
Zeichne die Grenzen, platziere die Services nach Vertrauensstufe, halte die Icons ruhig und erzeuge den Entwurf aus Terraform, damit er ehrlich bleibt. Das ist ein AWS-Diagramm, das Leute wirklich benutzen.