How to Draw a Network Architecture Diagram

A diagram for an incident responder needs traffic paths and failure domains. One for an auditor needs trust boundaries and data flows. One for a capacity planner needs link speeds. Trying to serve every audience in one picture produces clutter nobody can read. Write the question at the top of the diagram.

Logical diagrams show networks, subnets, zones, routing, and how traffic flows. Physical diagrams show devices, ports, racks, and cabling. Cloud diagrams show virtual networks, gateways, peering, and managed services. Keep them separate but cross-referenced, so readers can move between views without decoding a single overloaded drawing.

Show zones such as internet edge, DMZ, application, data, management, and user networks. Include major components: firewalls, load balancers, routers, gateways, and key services. Label subnets and important addresses. Draw the main traffic paths, including how users reach services and how services reach dependencies.

Mark where traffic crosses from one trust level to another, such as from the internet into a DMZ or from application servers into databases. Note which controls apply at each crossing: firewall rules, WAF, mutual TLS, or VPN. Trust boundaries are what security reviews and breach investigations care about most.

Indicate redundancy: paired devices, multiple links, availability zones, and regions. Highlight single points of failure honestly. During an outage, knowing what shares a path or a device is often the fastest route to the cause.

Adopt a standard set of icons and line styles, such as solid lines for physical links and dashed lines for logical tunnels. Include a legend. Use colour sparingly and consistently, for example to mark zones, so the diagram remains readable in black and white.

Include enough to answer the diagram's question and no more. A high-level diagram may show only zones and major flows; a detailed diagram for one site can show VLANs and interfaces. Link from high-level to detailed views instead of merging them.

General diagramming tools work well for hand-drawn diagrams, and cloud providers publish official icon sets. Diagrams-as-code tools generate diagrams from text, which fits version control and code review. Some network and cloud tools can generate diagrams from live configuration, which helps keep them accurate.

Diagrams rot quickly. Store them with configuration in version control, update them as part of change requests, date each diagram, and review them on a schedule. A stale diagram is worse than none during an incident, because it sends responders down the wrong path.

Cloud networks are defined in code, so diagrams can be generated from infrastructure definitions or account inventories. Show accounts or projects, virtual networks, subnets, route tables, gateways, peering, and private endpoints. Highlight internet-facing resources clearly.

Drawing every device and cable on one page, omitting traffic direction, leaving out management and backup networks, hiding single points of failure, using inconsistent icons, and never updating the diagram after changes.

Link diagrams from runbooks and alerts. During an incident, responders should be able to find the relevant view in seconds. After incidents, update diagrams with anything the investigation revealed that was missing.

Ask someone unfamiliar with the network to explain a traffic path using only the diagram. Where they get stuck, the diagram is missing information or is too dense. Peer review catches errors before the diagram is relied on.

For security and compliance, a data flow view shows where sensitive data travels: which services store it, which networks it crosses, and where it leaves the organisation. It complements network diagrams by answering what data could be exposed if a given zone is compromised, which is the first question in any breach investigation.

Use the same names for zones, subnets, and devices as your configuration and monitoring tools. If a diagram calls something core-fw-1 but alerts call it fw-prod-a, responders lose time translating during incidents.

Give each diagram an owner and a last-reviewed date. Track changes like code, with commit messages explaining what changed and why.

If no diagram exists, start with traffic: trace how a user request reaches the main service and how that service reaches its database and external dependencies.