ユースケース

ネットワークアーキテクチャ図

インターネットから DNS、ロードバランサ、ファイアウォール、VPC、サブネットまで、指さして示せるトラフィック。

シナリオ

ローンチ前のネットワークレビュー。公開インターネットと DNS、ロードバランサ、ファイアウォール、VPC とサブネットのフレーム、それらが守るサーバまたは Kubernetes ワークロード。

プラットフォームの会話のためのネットワークトポロジ。エッジ、ロードバランサ、サブネットとその背後のサービス。C4 や Kubernetes と同じエディタで、チームの共通言語になります。ネットワークパックは Free です。

描くもの

ネットワークアーキテクチャ図

  • インターネットと DNS
  • ロードバランサ、ルータ、スイッチ
  • Firewall
  • フレームとしての VPC と subnet
  • Server、rack、wireless、CDN
  • レビュー聴衆向けの Legend

Archboard を選ぶ理由

Archboard は、Kubernetes と C4 と同じホスト型ワークスペースにあるネットワークトポロジキャンバスです。ポートと直交エッジが経路を見えるようにします。ネットワークパックは Free で描けます。レビューがプラットフォームチームの外に出るときの無制限ノードと埋め込みのために Pro を購読してください。

このキャンバスのパック

ネットワーク · クラウド · セキュリティ · Kubernetes

すべての組み込みパックは Free で使えます(3 ダイアグラム、各ダイアグラム 15 ノード+メモ・テキスト・ステッカー・マインドマップのトピック 150 件、ブランド付き公開共有、AI エージェントとのライブ編集)。Pro では無制限のダイアグラムとノード、チームメイトがライブ編集するためのシート、埋め込み、透かしなしの書き出しが加わります($10/シート/月)。

セッションの流れ

  1. Google または GitHub サインインのあとキャンバスを開く

  2. インターネット → DNS → ロードバランサ → ファイアウォール → VPC/subnet を置く

  3. サブネットフレームの中にサーバまたは Kubernetes ノードを置く

  4. ブランド付き公開閲覧リンクを共有するか、変更チケット用に SVG/PNG を書き出す

Network diagrams people can point at

Network architecture diagrams usually fail at the pointer test: in a review, nobody can point at the path a packet takes. Icons float without frames, subnets are implied, and the firewall might as well be decorative. A network topology canvas passes the test by making the path visible, from the Internet to DNS to load balancer to firewall to VPC and subnet frames, with servers or Kubernetes workloads inside them. Orthogonal edges carry the hops cleanly; labeled edges carry the policy, like which port the firewall allows. When the whole path is on one board, the review moves from guessing to deciding.

Frame aggressively. VPC and subnet frames turn a pile of servers into an address plan reviewers can read: public subnets hold the load balancer, private subnets hold the workloads, and the firewall sits visibly between the edge and everything else. Add a legend for the review audience, because reviewers who do not live in the network still need to read it. Put DNS early in the path; half of all network mysteries start with name resolution, and the diagram should say so.

From topology sketch to change ticket

A network diagram becomes operational when it attaches to the change process. Export an SVG or PNG for the ticket, share a branded public link for the pre-launch review, and snapshot a revision before the firewall rule changes, since the before-shape is the fastest way to roll a conversation back. Keep the Kubernetes workloads that sit behind the firewall on the same canvas instead of a separate drawing; the subnet frame should contain what it actually routes to, whether that is servers or Pods. Tickets with a live link get approved faster than tickets with a stale screenshot.

The Network pack ships on Free with Cloud, Security, and Kubernetes packs beside it, because topologies never stop at the subnet edge. Combine Internet, router, switch, and CDN nodes with the firewall and VPC frames, and let the canvas hold the whole story from edge to workload. Pro adds embed plus watermark-free snapshots for the tickets that leave the platform team. Draw the path the packet takes, and then point at it.

Open a published example

Questions

What should a network diagram always show?

The full packet path: Internet, DNS, load balancer, firewall, VPC and subnet frames, and the servers or workloads inside them, along with labeled edges for policy like allowed ports and protocols.

Can servers and Kubernetes share one topology?

Yes. Drop servers or Kubernetes nodes inside the same subnet frames on one canvas. Reviewers see what the subnet routes to without reconciling two drawings.

How do I present this to non-network reviewers?

Add a legend, keep one packet path per board, and share the live link so reviewers can pan and zoom. Export SVG or PNG when the change ticket needs a frozen snapshot.

1分でキャンバスを開く

Google または GitHub でサインイン。1シートは無料で、チームが加わったらアップグレード。