Ask three people for the network diagram and you get three different pictures: a photo of the rack, a spreadsheet of IP addresses, and a cloud console screenshot. None of them answers the questions that come up in a review or an outage: which segments exist, what can talk to what, and how traffic gets between the office and the cloud.
This guide builds a logical network topology diagram for a typical small company, an office LAN with Wi-Fi and a site-to-site VPN to a cloud VPC, and covers the conventions that keep such a diagram readable.
Physical or logical topology
| Physical topology | Logical topology | |
|---|---|---|
| Shows | Devices, ports, cables, racks, patch panels | Segments, address ranges, routing, policy between zones |
| Answers | "Which port is the access point on?" | "Can a guest reach the file server?" |
| Readers | The people who cable and replace hardware | Engineers, security reviewers, auditors, new hires |
| Changes when | Hardware moves | Addressing, routing or rules change |
Most conversations need the logical view. Keep the physical one for the people who work in the rack, and do not mix the two on one page: port numbers next to firewall policy make both harder to read.
Common topologies, briefly
- Star. Every device connects to a central switch. Almost every office LAN is a star or a tree of stars.
- Mesh. Nodes connect to several others, so traffic has more than one path. Common between core switches, data center fabrics and Wi-Fi mesh systems.
- Hybrid. Real networks combine both: stars at the edge, redundant links in the core, tunnels between sites.
Bus and ring topologies are mostly history on modern LANs.
The example: an office and a cloud VPC
A 40-person company has an office with staff laptops, guest Wi-Fi, a file server and printers. Its internal app runs in a cloud VPC, and staff reach it over a site-to-site VPN instead of the public internet.
The address plan comes first, because the diagram is built from it. All internal ranges come from the private blocks in RFC 1918, and the public address uses a documentation range from RFC 5737:
| Segment | VLAN | Range | Gateway | What lives there |
|---|---|---|---|---|
| Staff | 10 | 10.10.10.0/24 | 10.10.10.1 (firewall) | Laptops and desk phones, wired and Wi-Fi |
| Guests | 20 | 10.10.20.0/24 | 10.10.20.1 (firewall) | Visitor devices on the guest SSID |
| Servers and printers | 30 | 10.10.30.0/24 | 10.10.30.1 (firewall) | File server, printers |
| Cloud VPC | 10.20.0.0/16 | VPC router | App servers and the database | |
| Private subnet | 10.20.1.0/24 | VPC router | App server, managed database | |
| ISP uplink | 203.0.113.10 | ISP | The firewall's static public address |
Two rules drive this plan. First, the office (10.10.0.0/16) and the VPC (10.20.0.0/16) must not overlap, or the VPN cannot route between them. Second, avoid 192.168.0.0/24 and 192.168.1.0/24 for the office: many home routers use them, and staff working from home would collide with them on a client VPN.
The firewall routes between the VLANs, so it is also where the policy lives:
| From | To | Allowed |
|---|---|---|
| Staff | Servers and printers | File sharing and printing ports |
| Staff | Cloud private subnet | HTTPS; SSH only from the admin group |
| Guests | Anything internal | Nothing; internet only |
| Cloud private subnet | Office | Replies only (stateful) |
The site-to-site VPN in one paragraph
An IPsec VPN uses IKE, on UDP port 500, to authenticate the peers and agree on keys, and ESP, IP protocol 50, to carry the encrypted traffic; UDP 4500 is used when a NAT sits in the path. On AWS, each Site-to-Site VPN connection has two tunnels with different public IP addresses, terminating on a virtual private gateway or transit gateway; configure both on your firewall so maintenance on one tunnel does not cut the office off. The office side needs a static public IP. Routing is static or dynamic with BGP, and the VPC's route tables need routes back to 10.10.0.0/16, either propagated from the virtual private gateway or added by hand.
The diagram
Diagram contents
- Internet
- Office firewall
- Core switch
- Wi-Fi access point
- VLAN 30 · Servers
- File server
- VLAN 10 · Staff
- Staff laptops
- VLAN 20 · Guests
- Guest devices
- Cloud VPC
- Private subnet
- App server
- Managed database
- Links
- ISP uplink · 203.0.113.10
- trunk: VLAN 10, 20, 30
- PoE + trunk
- SSID Office
- SSID Guest
- IPsec site-to-site VPN · 2 tunnels
How to read it:
- Top left, the edge. The office firewall has the static public address and is the IPsec peer. It routes between the three VLANs and enforces the policy table above.
- Middle, the office LAN. The core switch trunks VLANs 10, 20 and 30. The access point gets power and a trunk from the switch and maps the staff SSID to VLAN 10 and the guest SSID to VLAN 20.
- Right, the cloud. The dashed edge is the IPsec VPN, two tunnels, to the VPC. The app server and the managed database sit in a private subnet with no route from the internet.
- The legend explains the line styles: Ethernet, Wi-Fi, power over Ethernet and WAN.
What to label
- Every segment's range and VLAN ID. A box called "Staff network" without 10.10.10.0/24 cannot be checked against anything.
- Gateways and VPN peers. Which device routes each segment, and which public addresses form the tunnel.
- What may cross a boundary. Put the policy on the edges or in a table next to the diagram, not only in the firewall's configuration.
- SSID to VLAN mapping for every wireless network.
- The direction of initiation where it matters, for example that the cloud subnet only answers.
What to leave out
- Every laptop and phone. One node per kind of device per segment is enough.
- Cable colors and port numbers on a logical diagram. They belong in the physical one.
- Internal details of the cloud provider. The VPN endpoints are the virtual private gateway's; you do not need to draw AWS's side of the tunnel.
Use a legend
Line styles carry meaning on a network diagram, so explain them. A small legend with Ethernet, Wi-Fi, power over Ethernet, WAN and VPN takes one minute to add and saves every new reader from guessing. If you color segments, say what the colors mean as well.
Keep it current
Network diagrams go stale at the first unannounced change. Make the diagram part of the change: when someone adds a VLAN, changes a firewall rule or adds a tunnel, the change ticket links to the updated diagram, and a reviewer checks both. Architecture diagrams that don't rot describes a workflow for exactly that. For the cloud side in more depth, see the AWS VPC diagram guide, and for replacing the flat office network with identity-based access, the zero trust architecture diagram.
Build it in Archboard
- Sign in with Google or GitHub and create a diagram.
- From the Network pack, add Internet, Firewall, Switch and Wireless nodes for the office edge and LAN.
- Add three Network pack Subnet frames for VLANs 10, 20 and 30, each with its range in the frame's CIDR field, and put a Device or Server node inside each: staff laptops, guest devices, the file server.
- Add a Network pack VPC frame with a Subnet frame inside it, and put a Cloud pack Compute node and a Managed DB node in the subnet.
- Connect the nodes and set each edge's connection kind (Ethernet, Wi-Fi, PoE or WAN). Draw the VPN as a dashed edge from the firewall to the VPC.
- Add a Network pack Legend for the connection kinds.
The example uses 15 diagram nodes, within the Free plan. The network use case page shows more of what the Network pack covers.
FAQ
What is the difference between a network diagram and a network topology diagram? The terms are often used interchangeably. A topology diagram emphasizes how segments and devices connect; a logical topology diagram adds address ranges, routing and policy.
Should the diagram show IP addresses? Show ranges for every segment and addresses for gateways and VPN peers. Individual host addresses belong in an IP address management tool.
Why put guests on a separate VLAN? So the firewall can give them the internet and nothing else. On a shared segment, a guest device can reach printers, file shares and anything else that trusts the local network.
Do I need two VPN tunnels? On AWS each connection comes with two tunnels, and both should be configured on your device, so one can carry traffic while the other is down for maintenance.
How often should a network diagram be updated? With every change that touches addressing, routing or firewall rules. Tie the diagram to the change process rather than to a calendar.