『大規模だからVirtual WAN』『自由度が欲しいからHub-Spoke』だけで決めません。接続対象、route control、NVA/shared services、cross-region transit、team skill、change modelを比較し、どの責任をMicrosoft-managed hubへ移すのかを明示します。
Hub-Spoke vs Azure Virtual WANを理解するための前提
Traditional Hub-Spokeはcustomer-managed VNetをHubとして使い、Firewall/NVA、gateway、route tables、peeringなどの構成と運用を自組織が直接設計する。 Azure Virtual WANはMicrosoft-managed virtual hubを使い、VNet、branch VPN、ExpressRoute等の接続とtransit routingをサービス側で統合する。multi-hubではinter-hub connectivityを組み込みで扱える。
Hub-Spokeはcustom NVAやgranular route design、既存network investmentを活かしやすい。一方でregion/hub/spoke数が増えるほどpeering、UDR、gateway、cross-region routeの管理面が増える。 Virtual WANのvirtual hubは任意のVMや一般的なshared computeを直接配置する通常のVNetではない。BastionやDNS Resolverなどhub内に置けない共有serviceはhub extension VNet等のpatternを検討する。
Azure landing zoneではtraditional Hub-SpokeとVirtual WANの両方がnetwork topology optionとして扱われ、どちらでもconnectivity subscriptionへplatform network resourcesを集約する設計が基本になる。 Azure Virtual Network ManagerとVirtual WANのintegrationはcurrent Microsoft Learnでpreviewとして説明されている。production設計でGA前提に固定せず、region/feature/support条件を再確認する。
Ownership / Control / Data plane boundary
Hub-Spokeはhub VNet、peering、UDR、NVAをcustomerが管理。Virtual WANはvirtual hub fabricをMicrosoftが管理し、customerはconnections/routing intent等を構成する。
Hub-SpokeのtransitはrouteとNVA/Firewallを明示する。Virtual WANはhub connectivityをmanaged transitとして提供するが、policy/route intentは設計が必要。
Hub VNetにはVM-based serviceやBastion等を置ける。Virtual hubへ任意resourceを置く前提は持たず、必要ならhub extension VNetを設計する。
『managed』は責任消滅ではない。route advertisement、connection association/propagation、Firewall policy、DNS、observability、change validationは依然としてcustomer responsibility。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Route control | custom UDR/NVA chainや細かなroute manipulationが必須か。 | required prefixes、transit pattern、BGP/UDR ownership、routing intent適用範囲。 |
| Branch scale | branch/siteが多数あり、VPN/ER/SD-WAN connectionをregional/globalに統合する必要があるか。 | site countだけでなくregions、throughput、routing domains、provider boundary。 |
| Multi-region | global transitを自前peering/UDRで管理するか、Virtual WAN inter-hubを使うか。 | RTO/RPO、regional isolation、cross-region inspection、failover path。 |
| NVA / shared compute | custom NVA、Bastion、DNS appliance、AD等のVM-based shared serviceをhub内に置く必要があるか。 | native virtual hub feature、supported NVA、hub extension VNetの要否。 |
| Operations | 既存teamがVNet/peering/UDRを運用する方が透明か、managed hubへ抽象化する方が安全か。 | runbook、RBAC、diagnostic capability、deployment process、skills。 |
| Cost | hub resourceの個別課金とVirtual WAN unit/connection/traffic等をworkload profileで比較したか。 | 実traffic/connection前提を使ったcost model。 |
実装・展開の順序
- 現在と将来のconnection inventoryをVNet、on-prem/branch、partner/cloud、internet ingress/egress、region単位で作る。
- 必須要件を『routing』『security』『shared compute』『branch』『multi-region』『operations』へ分け、両方式で実現方法を対応付ける。
- unsupported/preview dependencyを洗い出し、production採用を妨げる項目をfeature availabilityの一次資料で確認する。
- 代表regionでsmall topologyを作り、VNet-to-VNet、VNet-to-on-prem、internet egress、DNS、failure testを同一traffic matrixで比較する。
- day-2 operationとしてroute change、new spoke onboarding、incident drill、rollbackを実施し、構築時ではなく運用時の複雑性を測る。
- decision recordに『採用理由』『棄却理由』『再評価条件』を残して標準topologyを確定する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Hub fabric | Hub VNetではcustomerがresource lifecycleを管理。Virtual WANではmanaged virtual hubのservice boundaryを理解し構成。 | Workloadはhub実装へ依存せず必要connectivityをcontractとして申請。 |
| Connection onboarding | standard peering/site/connection policyを作り、自動化。 | CIDR、ASN/site情報、required routes、security requirementを提供。 |
| Routing | central route/routing intentとhybrid integrationを管理。 | application route dependencyとexceptionを申告し、direct/bypassを勝手に追加しない。 |
| Shared services | Hubまたはextension VNetのDNS/Bastion/NVA等を管理。 | workload固有serviceをcentral hubへ持ち込まない。 |
| Validation | topology共通のpath/failover testを所有。 | business requestとworkload-level HAを所有。 |
Verification / review evidence
設計レビューで残す証拠
- Hub-Spoke / vWAN双方のlogical diagramと責任分界。
- 接続数ではなくtraffic classを含むconnection inventory。
- route control要件とunsupported/preview feature list。
- shared service placement matrix（hub / extension VNet / spoke）。
- failure mode比較とday-2 operation effort。
runtimeで確認すること
- VNet-to-VNet / branch-to-VNet / ER-to-VNetのselected pathとreturn path。
- Firewall/NVA経由時に実logへtrafficが残ること。
- new spoke/VNetを追加した際のconnection/routing propagation。
- regional hub failureやconnection withdrawal時の期待failover。
- DNS/Bastion等、virtual hub外のshared service reachability。
az network vwan list -o table
az network vhub list -o table
az network vnet list -o table
az network vnet peering list -g <rg> --vnet-name <hub-vnet> -o tableGet-AzVirtualWan
Get-AzVirtualHub
Get-AzVirtualNetwork
Get-AzVirtualNetworkPeering -ResourceGroupName <rg> -VirtualNetworkName <hub-vnet>Common failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| Virtual WANへ移したがshared serviceが置けない | virtual hubを通常VNetと同じresource hosting boundaryだと考えた。 | hub extension VNetやspoke placementを設計し直す。 |
| Hub-Spokeがregion追加ごとに複雑化 | cross-region peering/UDR/transitを手作業で増やしている。 | AVNM automationまたはVirtual WAN multi-hubを再評価。 |
| vWANなのにtrafficが期待Firewallを通らない | connection association/propagationやrouting intentを確認していない。 | effective routeとhub routing configurationをtraffic classごとに検証。 |
| 機能比較だけで決め運用が破綻 | incident/rollback/onboardingをselection criteriaにしていない。 | day-2 drillをPoC acceptanceへ含める。 |
| preview integrationへ依存 | AVNM↔Virtual WAN integration等のsupport状態を固定的に扱った。 | release status/region/supportをdeployment直前に再確認しfallbackを持つ。 |
Change safety / rollback
Current notes — 2026-09-11
2026-09-11時点のMicrosoft Learnでは、Azure Virtual Network ManagerがVirtual WAN hubをhubとして利用するintegrationはpreviewとして案内されています。これを必須dependencyにする場合はproduction support条件を都度確認してください。