AWS-VPC-Diagramm: Subnetze, Routing-Tabellen und NAT richtig gezeichnet

Die meisten VPC-Diagramme werden einmal gezeichnet, zu Projektbeginn, und aus der Ressourcenkarte der Konsole übernommen. Sie zeigen jede Ressource, beantworten aber keine der Fragen, die man tatsächlich an sie hat: Kann das Internet diese Datenbank erreichen? Warum kann die App Pakete herunterladen, aber keine Verbindungen annehmen? Was geht kaputt, wenn eine Availability Zone ausfällt?

Dieser Guide zeigt, wie du ein AWS-VPC-Diagramm zeichnest, das diese Fragen beantwortet. Wir nehmen ein gängiges Layout, eine VPC über zwei Availability Zones mit öffentlichen, privaten und Daten-Subnetzen, und gehen die Teile durch, die über die Erreichbarkeit entscheiden: Subnetze, Routing-Tabellen, Gateways, Endpunkte und Sicherheitsgruppen.

Die Fragen, die ein VPC-Diagramm beantworten muss

• Was kann das Internet erreichen? Nur Ressourcen in öffentlichen Subnetzen mit einer Route zu einem Internet-Gateway, und nur wenn ihre Sicherheitsgruppen es erlauben.
• Wie kommen private Ressourcen nach außen? Meist über ein NAT-Gateway, manchmal über VPC-Endpunkte, manchmal gar nicht.
• Wie fließt der Traffic zwischen den Schichten? Vom Load Balancer zur App, von der App zur Datenbank, und über welche Ports.
• Was passiert, wenn eine AZ ausfällt? Welche Ressourcen es in jeder Zone gibt und welche gemeinsam genutzt werden.

Wenn die Zeichnung eine dieser Fragen schwer beantwortbar macht, braucht sie weniger Ressourcen und mehr Struktur.

Die Bausteine

Teil	Was es ist	Wie du es zeichnest
VPC	Dein privates Netzwerk mit einem CIDR-Block wie 10.0.0.0/16	Der äußere Frame, CIDR im Label
Availability Zone	Ein isolierter Standort in der Region	Eine Spalte oder ein Frame in der VPC
Subnetz	Ein Bereich des VPC-CIDR in genau einer AZ	Ein Frame in seiner AZ, CIDR im Label
Routing-Tabelle	Regeln, die Traffic aus einem Subnetz an ein Ziel schicken	Eine kleine Tabelle pro Subnetz-Schicht
Internet-Gateway	Die Tür der VPC zum Internet	Auf der VPC-Grenze, zum Internet hin
NAT-Gateway	Lässt private Subnetze ausgehende Verbindungen aufbauen	Zonal: in einem öffentlichen Subnetz, eines pro AZ. Regional: ein Gateway für alle AZs, kein Subnetz
VPC-Endpunkt	Ein privater Weg zu AWS-Services	Gateway-Endpunkte für S3 und DynamoDB; Schnittstellenendpunkte in Subnetzen
Sicherheitsgruppe	Zustandsbehaftete Firewall an jeder Netzwerkschnittstelle	Port-Regeln als Kantenlabels, nicht als Boxen
Netzwerk-ACL	Zustandsloser Filter auf dem Subnetz	Eine Notiz am Subnetz, nur wenn du eigene Regeln nutzt

Zwei Fakten prägen das ganze Layout. Ein Subnetz liegt in genau einer Availability Zone, daher kann ein Subnetz in deinem Diagramm nie über mehrere AZ-Spalten reichen. Und ein Standard-NAT-Gateway (zonal) liegt in einer AZ: Steht das einzige in AZ a, verlieren die privaten Subnetze in AZ b ihren ausgehenden Zugang, sobald AZ a ausfällt. Seit November 2025 bietet AWS außerdem regionale NAT-Gateways an, die sich selbstständig über die AZs erweitern und kein öffentliches Subnetz brauchen; dieses Beispiel nutzt zonale.

Das Beispiel: zwei AZs, drei Schichten

Die VPC nutzt 10.0.0.0/16 in zwei Availability Zones, mit je drei Subnetzen:

Schicht	AZ a	AZ b	Route für 0.0.0.0/0
Öffentlich	10.0.0.0/24	10.0.1.0/24	Internet-Gateway
App (privat)	10.0.10.0/24	10.0.11.0/24	NAT-Gateway in derselben AZ
Daten (privat)	10.0.20.0/24	10.0.21.0/24	Keine

Jede Routing-Tabelle enthält außerdem die local-Route für 10.0.0.0/16, über die sich die Subnetze in der VPC gegenseitig erreichen; was tatsächlich erlaubt ist, entscheiden dann die Sicherheitsgruppen. AWS reserviert in jedem Subnetz fünf Adressen, ein /24 bietet also 251 nutzbare Adressen.

Was wo läuft:

• Ein Application Load Balancer hat Knoten in beiden öffentlichen Subnetzen und nimmt HTTPS aus dem Internet an.
• App-Server (EC2-Instances oder ECS-Tasks) laufen in beiden App-Subnetzen und nehmen nur Traffic von der Sicherheitsgruppe des ALB an.
• Eine primäre RDS PostgreSQL-Instance läuft in einem Daten-Subnetz, ein Standby im anderen. RDS verlangt eine DB-Subnetzgruppe mit Subnetzen in mindestens zwei AZs.
• Ein NAT-Gateway in jedem öffentlichen Subnetz gibt den App-Servern ausgehenden Zugang für Updates und Drittanbieter-APIs.
• Ein Gateway-Endpunkt für S3 lässt die App-Server S3 erreichen, ohne über das NAT-Gateway zu gehen, und spart so auch die Datenverarbeitungsgebühren des NAT-Gateways.

So sieht das Diagramm aus:

Layout-Regeln für ein lesbares Diagramm

Spalten für AZs, Zeilen für Schichten

Ordne die Availability Zones nebeneinander an und die Schichten von oben nach unten: oben öffentlich, dann App, dann Daten. So liest sich die Erreichbarkeit von oben nach unten, und eine Ressource, die in einer Spalte fehlt, fällt sofort auf.

Internet-Gateway auf die Grenze setzen

Das Internet-Gateway hängt an der ganzen VPC, nicht an einem Subnetz. Zeichne es auf den VPC-Frame, zwischen das Internet und die öffentlichen Subnetze.

Routen als Tabelle zeigen, nicht als Pfeile zu allem

Ein Pfeil von jedem Subnetz zu jedem Gateway macht das Diagramm zum Spinnennetz. Eine kleine Routing-Tabelle pro Schicht, wie die oben, sagt dasselbe präzise. Zeichne Pfeile nur für die wichtigsten Traffic-Pfade.

Sicherheitsgruppen-Regeln an die Kanten schreiben

Sicherheitsgruppen gehören zu Netzwerkschnittstellen, nicht zu Subnetzen, deshalb sind Frames die falsche Form für sie. Beschrifte stattdessen die Kanten: HTTPS 443 from internet, 8080 from ALB SG, 5432 from app SG. Genau diese Information suchen die Leute.

Peering und VPN an den Rand legen

Transit-Gateways, Peering-Verbindungen und Site-to-Site-VPNs verbinden die VPC mit anderen Netzen. Zeichne sie auf die VPC-Grenze, mit den Remote-CIDRs im Label, und halte die Gegenseite in einem eigenen Diagramm.

Häufige Fehler

• Ein Subnetz über zwei AZs. Das kann es nicht geben. Zeichne ein Subnetz pro AZ, auch wenn beide Zwillinge sind.
• Ein zonales NAT-Gateway für beide AZs, ohne es zu erwähnen. Das kann eine bewusste Kostenentscheidung sein; schreib es ins Diagramm, damit niemand von unabhängigen Zonen ausgeht.
• Sicherheitsgruppen als verschachtelte Boxen. Sie überlappen beliebig und gelten pro Schnittstelle; Verschachtelung suggeriert Regeln, die es nicht gibt.
• Die Ressourcenkarte der Konsole abzeichnen, mit jeder Netzwerkschnittstelle und jeder Zuordnung einer Routing-Tabelle. Nützlich für Audits, unlesbar fürs Design.
• Keine CIDRs. Überlappende Adressbereiche sind genau das, was später Peering verhindert. Schreib den CIDR an jeden VPC- und Subnetz-Frame.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Netzwerk-Pack einen VPC-Frame hinzu und setz seinen CIDR auf 10.0.0.0/16.
3. Füge darin für die zwei AZs je einen Rahmen aus dem Basis-Pack hinzu und in jede AZ Subnetz-Frames aus dem Netzwerk-Pack mit ihren CIDRs.
4. Füge außerhalb der VPC einen Internet-Node aus dem Netzwerk-Pack hinzu und für das Internet-Gateway einen Router auf der VPC-Grenze.
5. Füge aus dem Cloud-Pack einen Cloud-Lastverteiler für den ALB hinzu, Recheninstanz-Nodes für die App-Server und Nodes vom Typ Verwaltete Datenbank für Primary und Standby von RDS. Nimm für die NAT-Gateways Router-Nodes aus dem Netzwerk-Pack.
6. Verbinde die Ports und beschrifte die Kanten mit Ports und Quell-Sicherheitsgruppen.
7. Füge aus dem Basis-Pack eine Tabelle mit den Routing-Tabellen hinzu und eine Notiz für Entscheidungen wie NAT pro AZ.

Das vollständige Beispiel braucht mehr als die 15 Diagramm-Nodes des Free-Plans, ein so detailliertes VPC-Diagramm passt also gut zu Pro. Für Multi-Region-Designs sieh dir das AWS-Multi-Region-Architekturdiagramm an, für weitere Netzwerkmuster die Use-Case-Seite zu Netzwerken.

FAQ

Gehört jedes Subnetz ins Diagramm? Ins VPC-Designdiagramm ja, denn die Erreichbarkeit hängt von Subnetz und Routing-Tabelle ab. In einem Anwendungsdiagramm reicht meist ein Frame pro Schicht.

Brauche ich in jeder AZ ein NAT-Gateway? Mit zonalen NAT-Gateways ja, damit die Zonen unabhängig bleiben. Ein einzelnes zonales NAT-Gateway spart Geld, macht aber jede AZ für ausgehenden Traffic von einer Zone abhängig und verursacht Gebühren für AZ-übergreifende Datenübertragung. Ein regionales NAT-Gateway ist ein einziges Gateway, das sich in jede AZ mit Workloads erweitert. Wofür du dich auch entscheidest: Schreib es ins Diagramm.

Wohin gehören VPC-Endpunkte? Gateway-Endpunkte (S3 und DynamoDB) sind Ziele in Routing-Tabellen, also zeichne sie auf die VPC-Grenze und nenne sie in der Routing-Tabelle. Schnittstellenendpunkte sind Netzwerkschnittstellen in deinen Subnetzen, also zeichne sie in die Subnetze, in denen sie liegen.

Sicherheitsgruppen oder Netzwerk-ACLs im Diagramm? Sicherheitsgruppen immer als Kantenlabels. Netzwerk-ACLs nur als Notiz am Subnetz, und nur, wenn du die Standardeinstellungen geändert hast.

Kann ich das aus meinem AWS-Konto generieren? Archboard liest dein AWS-Konto nicht. Zeichne das Design, das du anstrebst, und vergleiche es bei Reviews mit der Ressourcenkarte der Konsole.

Kostenlos starten — ein Seat, keine Kreditkarte.