Architecture & GovernanceReviewed 2026-09-10

Hub-and-Spoke Architecture

central hubにFirewall/gateway/Bastion/DNS等を集約し、workloadをspoke VNetへ分離するAzure定番topology。

Scope: 設計・運用で誤りやすい点を優先して整理。SKU/region/limitsは変更されるため、実装時はリンク先のcurrent Microsoft Learnを再確認してください。

Overview

central hubにFirewall/gateway/Bastion/DNS等を集約し、workloadをspoke VNetへ分離するAzure定番topology。

Key technical points

  • hubはregional resourceとしてshared connectivity/egress/ingress/remote access/routingを提供する。
  • spokeはworkload/environment単位でisolationし、通常同regionのsingle hubへ接続する。
  • VNet peeringはnon-transitiveなのでspoke-to-spoke transitは明示設計する。

Design guidance

  • design diagramと同時にtraffic matrix、route matrix、failure matrix、ownership matrixを作る。
  • platform teamのcentral policyとworkload teamのself-service範囲をresource scope/RBACへ落とす。
  • at-scale変更はstaged deployment、canary region/group、rollbackを前提にする。

Operations checklist

  1. scope/region/subscription/network groupを明示する。
  2. traffic matrixとfailure testをacceptance criteriaにする。
  3. IaC/Policyとruntime stateのdriftを確認する。

Common pitfalls

  • diagramだけ作りtraffic/failure/ownershipを定義しない。
  • central policyを一括deployし、blast radiusを大きくする。

Verification pattern

Control plane
resource state、association、policy、route/BGP configが期待通りかを確認。
Data plane
同一5-tupleまたは実application journeyで到達性・latency・security判定を実証。
Observability
diagnostic logs / flow logs / Network Watcherで実際の判定とpathを残す。
Rollback
設定を戻した後のroute convergence、DNS cache、existing sessionまで確認。

Official sources