Serverless-Architekturdiagramm auf AWS: API Gateway, Lambda, DynamoDB und Events

In einem Serverless-System sind die Server weg, und mit ihnen die übliche Form eines Architekturdiagramms. Stattdessen zählt, wie jede Funktion ausgelöst wird, was passiert, wenn sie fehlschlägt, und welche Events einen Teil des Systems mit dem nächsten verbinden. Ein Diagramm mit zwanzig Lambda-Boxen und keinem einzigen Trigger wirkt vollständig und erklärt nichts.

Dieser Guide zeigt, wie du ein Serverless-Architekturdiagramm auf AWS zeichnest, das eine neue Kollegin nachvollziehen kann: ein ausgearbeitetes Beispiel, eine Notation für Aufrufarten und Fehlerpfade und die Fehler, die solche Diagramme irreführend machen.

Zuerst klären, wie jede Funktion aufgerufen wird

Jede Lambda-Funktion im Diagramm wird von irgendetwas gestartet, und AWS kennt drei Aufrufmodelle, die sich im Fehlerfall unterschiedlich verhalten. Das ist das Nützlichste, was ein Serverless-Diagramm zeigen kann.

Aufrufmodell	Typische Quellen	Wer bei Fehlern wiederholt	Wo Fehler landen
Synchron	API Gateway, eine Funktions-URL, ein SDK-Aufruf	Der Aufrufer entscheidet	Eine Fehlerantwort an den Aufrufer
Asynchron	EventBridge, S3-Benachrichtigungen, SNS	Lambda wiederholt standardmäßig zweimal	Eine On-Failure-Destination oder eine Dead-Letter-Queue, sofern du eine konfigurierst
Event Source Mapping (Lambda pollt)	SQS, DynamoDB Streams, Kinesis	Lambda versucht den Batch immer wieder	SQS: die Dead-Letter-Queue der Queue. Streams: eine On-Failure-Destination, sonst laufen die Datensätze ab

Beschrifte jede Trigger-Kante mit Quelle und Modell: sync, async oder poll, batch 10. Wenn ein Incident mit „Nachrichten stauen sich“ beginnt, ist das die Linie, nach der alle suchen.

Das Beispiel: eine Serverless-Bestell-API

Ein kleiner Bestellservice, komplett auf Managed Services aufgebaut:

1. Clients rufen eine HTTP-API in API Gateway auf. Ein JWT-Authorizer prüft Tokens, die ein Benutzerpool von Amazon Cognito ausstellt.
2. API Gateway ruft createOrder synchron auf. Die Funktion validiert den Request und schreibt die Bestellung in die DynamoDB-Tabelle orders.
3. Ein DynamoDB-Stream auf der Tabelle triggert die Funktion publishOrderEvents, die OrderPlaced an einen benutzerdefinierten EventBridge-Bus sendet. Weil das Event aus dem Stream kommt, wird es nur für erfolgreiche Schreibvorgänge veröffentlicht.
4. Eine EventBridge-Regel filtert auf OrderPlaced und leitet das Event an die SQS-Queue receipts weiter.
5. Lambda pollt die Queue und ruft sendReceipt mit Batches von bis zu zehn Nachrichten auf; die Funktion schickt dem Kunden über Amazon SES eine E-Mail.
6. Eine Nachricht, die fünfmal fehlschlägt, wandert in receipts-dlq, wo ein Alarm das Team benachrichtigt.

Der Request-Pfad endet bei Schritt 2: Der Client bekommt seine Antwort, sobald die Bestellung gespeichert ist. Alles danach läuft asynchron, und das Diagramm zeichnet diese Trigger als gestrichelte Kanten.

Regeln für Serverless-Diagramme

Trigger als beschriftete Kanten zeichnen

Die Kante, die in eine Funktion führt, sagt, was sie startet: POST /orders, DynamoDB stream, rule: OrderPlaced, SQS, batch 10. Eine Funktion ohne eingehende Kante ist entweder toter Code oder eine Linie, die in deinem Diagramm fehlt.

Request-Pfad und asynchrone Arbeit trennen

Nutze durchgezogene Kanten für synchrone Aufrufe und gestrichelte für alles, was später passiert. Wer das Diagramm liest, sollte den Pfad, der für den Nutzer Latenz erzeugt, verfolgen können, ohne jedes Label zu lesen.

Den Fehlerpfad bewusst zeichnen

Entscheide für jede asynchrone Kante, wohin Fehler gehen, und zeichne es ein: eine Dead-Letter-Queue, eine On-Failure-Destination oder eine Notiz wie „Datensätze laufen nach 24 Stunden ab“. DynamoDB Streams hält Datensätze 24 Stunden lang vor; ein Consumer, der immer wieder fehlschlägt, verliert also Events, sobald sie ablaufen. Eine On-Failure-Destination in S3 behält eine Kopie der fehlgeschlagenen Datensätze; ein SQS- oder SNS-Ziel bekommt nur Metadaten, also muss etwas die Datensätze innerhalb dieser 24 Stunden aus dem Stream zurücklesen.

Eine Funktion pro Node

Ein einzelner „Lambda“-Node für dreißig Funktionen versteckt die Trigger, und die Trigger sind die Architektur. Bei zu vielen Funktionen teilst du das Diagramm nach Service auf, statt Boxen zusammenzulegen.

Nach Deployment-Einheit in Frames gruppieren

Fasse Ressourcen, die gemeinsam deployt werden, etwa einen SAM-, CDK- oder Terraform-Stack, in einem Frame zusammen. Das zeigt Zuständigkeiten und was sich gemeinsam ändert.

Berechtigungen und Limits als Notizen festhalten

Jede Funktion hat eine IAM-Ausführungsrolle, manche haben reservierte Concurrency oder lange Timeouts. Zeichne nicht für jede Funktion eine Rolle. Füge eine Notiz für das hinzu, was in einem Review zählt: „nur createOrder darf in orders schreiben“, „SQS-Trigger von sendReceipt mit maximaler Concurrency 5, um die SES-Limits zu schützen“.

Häufige Fehler

• API Gateway als Load Balancer gezeichnet. Es authentifiziert, drosselt und transformiert auch Requests, und der Authorizer gehört ins Diagramm.
• Fehlende Dead-Letter-Queues oder Dead-Letter-Queues, die niemand beobachtet. Zeichne auch den Alarm ein.
• Event-Busse ohne Regeln. Ein EventBridge-Bus verteilt Events per Regel; beschrifte die Kante mit der Regel, nicht nur mit dem Bus.
• Sync und async nicht unterschieden. Das ist der Unterschied zwischen einer langsamen API und einer langsamen E-Mail.
• Infrastrukturrauschen. Log-Gruppen, Layer und jede einzelne IAM-Policy gehören ins Template, nicht in die Übersicht.

In Archboard nachbauen

Die Nodes im Cloud-Pack von Archboard sind anbieterneutral und haben Ports, deshalb beschriftest du jeden Node mit dem Namen des AWS-Service:

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge für die Clients und für Amazon SES Kasten-Nodes aus dem Basis-Pack hinzu, dazu ein API-Gateway aus dem Cloud-Pack und einen Identitätsanbieter aus dem Sicherheits-Pack mit dem Label Amazon Cognito.
3. Füge für jede Lambda-Funktion eine Funktion aus dem Cloud-Pack hinzu und benenne sie genau wie in deinem Template.
4. Ergänze eine Verwaltete Datenbank aus dem Cloud-Pack mit dem Label DynamoDB: orders, ein Thema aus dem Daten-Pack mit dem Label EventBridge bus, Warteschlange-Nodes aus dem Cloud-Pack für die Queue und ihre Dead-Letter-Queue sowie für den Alarm einen Alarm aus dem DevOps-Pack.
5. Verbinde die Ports. Lass den Request-Pfad durchgezogen, stell asynchrone Kanten auf gestrichelt und beschrifte jeden Trigger mit Quelle und Aufrufmodell.
6. Leg den Stack in einen Rahmen aus dem Basis-Pack, füge Notizen für Berechtigungen und Limits hinzu und teile dann den Live-Link mit dem Team.

Das Beispiel nutzt 13 Diagramm-Nodes und passt damit in den Free-Plan. Für das Netzwerk rund um einen Serverless- oder Container-Workload lies den Guide zum AWS-VPC-Diagramm, weitere Cloud-Muster findest du auf der Anwendungsfall-Seite für Cloud-Architekturen.

FAQ

Soll ich jede Lambda-Funktion zeichnen? Im Service-Diagramm ja, weil jede ihren eigenen Trigger und ihr eigenes Fehlerverhalten hat. In einer Systemübersicht zeigst du den Service als einen Node und verlinkst auf sein Diagramm.

Kann ich die offiziellen AWS-Icons verwenden? Archboard hat kein AWS-spezifisches Pack: Baue das Diagramm aus typisierten Nodes mit Ports aus den Packs Cloud, Netzwerk und Sicherheit und beschrifte jeden mit dem Service-Namen, etwa Amazon SES oder DynamoDB: orders. Wenn du zusätzlich Logos willst, findest du unter Suchen und einfügen Markensymbole für AWS-Services wie AWS Lambda, die du als Symbol-Nodes platzieren kannst.

Wie stelle ich Step Functions dar? Als einzelnen Node im Architekturdiagramm, beschriftet mit dem Namen des Zustandsautomaten, und den Workflow selbst als eigenes Flussdiagramm oder BPMN-Diagramm.

Wohin gehören Cold Starts und Concurrency? In Notizen neben den Funktionen, bei denen sie eine Rolle spielen, etwa Provisioned Concurrency an einem latenzkritischen Endpoint.

Muss ich IAM-Rollen zeigen? Nicht als Nodes. Notiere die Berechtigungen, die das Design prägen, und halte die vollständigen Policies in deinem Infrastrukturcode.

Kostenlos starten — ein Seat, keine Kreditkarte.