Hubは共有機能を置く「共通VNet」、Spokeはworkloadを隔離する「利用VNet」と定義します。Hub-Spoke採用だけではspoke-to-spoke transit、internet egress、hybrid route、DNS、inspectionは自動的に決まらないため、それぞれをtraffic matrixとroute intentで明文化します。
Hub-and-Spoke Architectureを理解するための前提
Hub virtual networkはshared networking servicesの配置点であり、cross-premises connectivityや主要なegress control pointとして使える。Hub自体はregional resourceなので、複数regionへ展開する場合はregionごとのhubを基本に考える。 Spoke VNetはapplication、team、environmentなどworkload boundaryとして分離する。Microsoftのcurrent guidanceでは、多くのscenarioで各spokeを同一regionの単一hubへ接続する構成が基準になる。
VNet peeringはnon-transitive。Spoke A → HubのpeeringとHub → Spoke Bのpeeringが存在しても、それだけではHubをrouterとしてSpoke A → Spoke Bへ転送しない。central firewall/NVAまたはdirect peeringなど、明示的なtransit designが必要。 VPN Gateway / ExpressRoute gatewayをHubへ集約する場合、gateway transit / remote gatewayの設計と、各spokeのUDR・BGP route propagation・return pathを一体で確認する。
Azure FirewallをHubのegress/inspection pointにする場合、Spoke subnetからFirewallへ向けるrouteと、Firewallが実際のnext hopになることをeffective routesで確認する。Firewall配置だけでは強制経由にならない。 Hubに置くべきものは『多くのspokeが共有し、central ownershipが必要なnetwork service』に限定する。workload固有のLayer 7 ingressやapplication dependencyを中央へ集めすぎると、変更権限とblast radiusが不必要に拡大する。
Ownership / Control / Data plane boundary
Hub、hybrid gateway、central firewall/NVA、shared DNS、DDoS plan、global network policyを中央teamの責任範囲として扱う。
Spoke内subnet、workload NSG、application-specific ingress/egress requirement、service endpoint/private endpoint等はlanding zone側の責任として明確化する。
Peering flags、route tables、gateway transit、Firewall Policy、DNS linksは設定状態。『存在する』こととdata pathが期待経路を通ることを分ける。
source → local subnet → selected route → hub inspection/transit → destination と return pathをpacket walkで確認する。east-westとnorth-southを別flowとして検証する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Hubの粒度 | regionごとに何個のHubが必要か。scale、regulatory boundary、failure domain、different routing policyを理由に分割するか。 | Hub-to-region mapping、subscription/RG、address range、owner、SLA。 |
| Spokeの粒度 | workload / environment / trust zoneのどれをVNet boundaryにするか。 | subscriptionとVNetの1対多/1対1方針、CIDR、owner、lifecycle。 |
| East-West | Spoke間をdeny、direct peering、AVNM direct connectivity、central firewall/NVA transitのどれにするか。 | 許可traffic matrix、next hop、return path、inspection requirement。 |
| North-South | internet ingress/egressとon-prem ingress/egressをどこでinspectするか。 | UDR、gateway route、public IP ownership、DNAT/SNAT、logging。 |
| DNS | Hub集中Resolver/DNS proxyを使うか、Azure-provided DNS/Private DNSをどう共有するか。 | resolver endpoint、ruleset、zone link、on-prem conditional forwarder。 |
| 権限 | Platform teamが作るresourceとworkload teamが変更できるresourceをどこで分けるか。 | RBAC scope、Policy、change approval、exception process。 |
実装・展開の順序
- Address spaceを先に予約し、Hub/Spoke/On-premでoverlapしないregional CIDR planを作る。将来regionとM&A/partner接続分も予約する。
- Hubを作成し、gateway/firewall/DNSなど共有serviceのresource ownershipとavailability requirementを確定する。まだSpokeのdefault routeを一括変更しない。
- 1つのnon-production Spokeを接続し、peering flags・gateway transit・DNS query path・effective routesをread-onlyで確認する。
- north-southとeast-westの代表trafficについて、source/destination/protocol/port/expected next hopを固定してpacket walkを実行する。
- Firewall/NVA経由を強制するrouteをcanary Spokeへ適用し、forward pathとreturn path、existing session、新規session、DNS依存を検証する。
- 可観測性とrollbackが成立したことを確認してから、network group / IaC等を使い段階的に残りSpokeへ展開する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Hub VNet / peering standard | Hub CIDR、central peer側、peering option、gateway transit標準を管理。 | Spoke peer要求を申請し、workload側CIDRと通信要件を提示。 |
| Routing / inspection | central next hop、shared route policy、Firewall/NVA availabilityを管理。 | applicationが必要とするdestination/port/FQDNとexceptionを管理。 |
| DNS | Private Resolver、central forwarding、shared Private DNS運用を管理。 | workload固有zone record / Private Endpoint作成時のDNS dependencyを申告。 |
| Security | Security Admin Rulesやcentral Firewall baselineを管理。 | subnet/NIC NSGとapplication-level least privilegeを管理。 |
| Validation | cross-spoke/hybrid/egressの共通testを提供。 | business transactionとworkload固有negative testを実施。 |
Verification / review evidence
設計レビューで残す証拠
- Hub/Spoke/On-premを含むCIDR mapと重複チェック結果。
- Traffic matrix: source zone、destination zone、protocol/port、inspection要否、owner。
- Route matrix: prefix、route source、next hop、propagation、expected effective route。
- Peering/gateway transit/firewall/DNSのdependency diagram。
- failure matrix: Hub firewall故障、gateway故障、region障害、DNS障害時の期待挙動。
runtimeで確認すること
- 代表NICのEffective Routesで0.0.0.0/0、on-prem prefix、remote spoke prefixのnext hopを確認。
- Effective Security Rules / IP Flow Verifyでpolicy boundaryを確認し、Allowをend-to-end成功と誤認しない。
- Connection Troubleshootまたは実application requestで期待pathの到達性を確認。
- Firewall/NVA logsとVNet Flow Logsで実trafficがinspection pointを通過した証拠を残す。
- 変更後にforward/returnの両方向とnegative testを再実行。
az network vnet list -o table
az network vnet peering list -g <spoke-rg> --vnet-name <spoke-vnet> -o table
az network route-table list -o table
az network vnet-gateway list -o tableGet-AzVirtualNetwork
Get-AzVirtualNetworkPeering -ResourceGroupName <rg> -VirtualNetworkName <spoke-vnet>
Get-AzRouteTable
Get-AzVirtualNetworkGatewayCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| Spoke AからSpoke Bへ届かない | peeringをtransitive routingだと誤認。 | effective routeでremote spoke prefixのnext hopを確認し、direct peeringかNVA/Firewall transitを明示。 |
| on-premからSpokeへ片方向だけ通る | gateway側とspoke側でroute/propagation/UDRが非対称。 | 両方向のeffective routeとBGP learned/advertised prefixを分けて確認。 |
| Firewallを置いたのにbypassする | more specific system/BGP/peering routeが選ばれる、またはUDR未適用。 | longest-prefixとroute sourceを確認し、必要なscopeへroute intentを適用。 |
| Hub変更で多数workloadが同時障害 | shared serviceに変更を集中させ、canary/region staged deploymentがない。 | network groupやdeployment ringで小さく適用し、rollback条件を事前定義。 |
| DNSだけ不安定 | Hub DNS/Firewall DNS proxyとclient resolverが異なる名前解決結果を使う。 | query pathとresolver sourceを固定し、FQDN rule利用時は名前解決整合性を確認。 |