Engineering

Cloud-Icons für Architektur­diagramme: AWS, Azure und GCP richtig eingesetzt

Ein Cloud-Diagramm mit den falschen Icons liest sich wie eine Fremdsprache. So setzt du Cloud-Icons für Architekturdiagramme so ein, dass jeder Reviewer sie auf einen Blick erkennt.

Es gibt eine bestimmte Art von Cloud-Diagramm, bei der Reviewer ein ungutes Gefühl bekommen, ohne genau zu wissen, warum. Alles ist ein graues Rechteck. Der Load Balancer, die Queue, der Objektspeicher und die verwaltete Datenbank sehen alle gleich aus und lassen sich nur durch die Wörter unterscheiden, die in ihnen stehen. Technisch ist es korrekt. Aber niemand kann es überfliegen, und ein Diagramm, das du Wort für Wort lesen musst, ist kaum schneller als der Absatz, den es ersetzt hat.

Gute Cloud-Diagramme wirken mühelos, weil sie sich auf eine gemeinsame visuelle Sprache stützen. Ein Engineer, der auf der Plattform gearbeitet hat, kennt die Form eines Compute-Service, eines Objektspeichers, einer verwalteten Queue, bevor er ein einziges Label liest. Wenn dein Diagramm die Ikonografie des Anbieters selbst nutzt, dockt es direkt an dieses gemeinsame Gedächtnis an, und das Bild lässt sich überfliegen. Genau das ist der Unterschied zwischen einem Diagramm, dem Leute vertrauen, und einem, bei dem sie die Augen zusammenkneifen.

Icons tragen Bedeutung, sie sind keine Dekoration

Es ist verlockend, Icons als Feinschliff zu behandeln, den man am Ende hinzufügt. Das sind sie nicht; mit ihnen kodiert ein Cloud-Diagramm den Typ. Sobald ein Kasten das Objektspeicher-Icon trägt, kennt der Leser seine Haltbarkeit, sein Zugriffsmuster und sein Kostenmodell, ohne dass du irgendetwas davon aufschreibst. Ein Icon für eine verwaltete Datenbank sagt "das betreibt jemand anderes", wie es ein schlichtes Rechteck nie könnte. Entfernst du die Icons, wirfst du eine Informationsebene weg, und deshalb wirkt das komplett graue Diagramm so flach.

VPC CDN Load bal. ComputeContainer x N Managed DB Object store
Jeder Service trägt sein eigenes Icon, sodass der Typ vor dem Label gelesen wird. LetDraw liefert die echten AWS-, Azure- und GCP-Iconsets mit; hier sind es Platzhalter.

AWS-, Azure- und GCP-Icons: nutze das echte Iconset des Anbieters

LetDraw enthält Icon-Bibliotheken im offiziellen Stil für die drei großen Clouds (AWS, Azure und GCP), du musst einen Compute-Service also nicht mit einem generischen Server-Symbol annähern. Öffne die Formenbibliothek, wähle deinen Anbieter und zieh die tatsächlichen Services auf die Leinwand: den Load Balancer, der wie der Load Balancer dieses Anbieters aussieht, die Queue, die wie seine Queue aussieht. Ein Diagramm aus dem richtigen Set liest sich für alle korrekt, die auf dieser Plattform arbeiten, und das ist meist genau das Publikum des Diagramms.

Auch das Mischen von Anbietern ist in Ordnung und ehrlich, wenn dein System tatsächlich mehrere umfasst. Die Icons machen die Grenze offensichtlich (diese Hälfte liegt in einer Cloud, jene in einer anderen), statt eine Multi-Cloud-Realität hinter einheitlich grauen Kästen zu verstecken.

Das richtige Icon sagt dem Leser, was ein Kasten ist, bevor er ein einziges Wort liest. Genau das ist die Aufgabe eines Cloud-Diagramms.

Starte mit der Infrastruktur, die du bereits deklariert hast

Du musst nicht jeden Service von Hand platzieren. Wenn deine Infrastruktur in Terraform oder einer ähnlichen Deklaration lebt, listet diese Datei bereits die Ressourcen und ihre Verbindungen auf. Füge sie in "Aus Code generieren" ein, und LetDraw ordnet die Komponenten für dich an; dann stempelst du die passenden Anbieter-Icons auf die Kästen, damit sich der generierte Entwurf wie eine echte Architektur liest und nicht wie ein Abhängigkeitsgraph.

main.tf
resource "aws_lb" "web" { # → load balancer icon }
resource "aws_ecs_service" "api" { # → compute icon }
resource "aws_db_instance" "main" { # → managed DB icon }
resource "aws_s3_bucket" "assets" { # → object-store icon }
Tipp. Zeichne Vertrauens- und Netzwerkgrenzen als beschriftete Container (VPC, Subnetz, Region) und platziere die Icons darin. Die Grenze beantwortet "was kann was erreichen", und um genau diese Frage geht es bei den meisten Cloud-Diagrammen insgeheim.

Halte es lesbar, während es wächst

Echte Cloud-Diagramme werden voll, und was sie ruiniert, sind Pfeile, die gerade durch alles gezogen werden, was im Weg ist. Lass stattdessen die Leinwand die Verbinder um deine Services herumführen, gruppiere jede Schicht oder Region in einen Container, und das Bild bleibt bei dreißig Kästen so lesbar wie bei fünf. Wenn du es als Code brauchst (für ein Dokument, ein Wiki, einen Pull Request), exportiere es nach Mermaid oder D2 und committe es neben dem Terraform, das es beschreibt.

Ein gutes Cloud-Diagramm ist nicht hübscher als ein schlechtes; es ist schneller zu lesen. Nutze die echten Icons, generiere den ersten Entwurf aus deiner Infrastruktur und gib deinen Reviewern ein Bild, das sie auf den ersten Blick erkennen.

Zeichne ein Cloud-Diagramm, das man auf den ersten Blick erkennt

Nutze die echten AWS-, Azure- und GCP-Iconsets, generiere den ersten Entwurf aus deinem Terraform und halte es lesbar, während es wächst.

LetDraw kostenlos öffnen