connectivity configurationを『peeringを自動で増やす仕組み』ではなく、Network Group単位のtopology intentとして管理する。hubの責任、spoke間通信、global connectivity、gateway利用、deployment regionをtraffic matrixとfailure domainへ落とし込む。
VNM Connectivity Configurationを理解するための前提
Connectivity Configurationでは主にMeshとHub-and-SpokeのtopologyをNetwork Groupに対して宣言できる。 Meshはgroup内VNet間のdirect connectivityを意図する。Hub-and-Spokeはcentral hubとspoke groupの関係を定義し、shared servicesやcentral inspectionと組み合わせる。
Hub-and-Spokeでは、spoke group内でdirect connectivityを許可するかを別途設計する。『同じspoke groupだから相互通信できる』と自動的に想定しない。 cross-region topologyではglobal mesh等のoptionを使う場合がある。latency・egress・failure domain・data residencyを含め、単なる到達性だけで採用しない。
hub gatewayをspokeへ利用させる設計では、gateway resourceとpropagation behaviorを先に確認し、configuration deploymentとgateway provisioningの順序を管理する。 configurationはtarget regionへdeployされて初めてactiveになる。作成・更新・deploymentを別changeとして追跡する。
Connectivity Configurationはrouting/security/DNSをすべて解決するものではない。UDR、Firewall/NVA、DNS resolver、NSG/security admin ruleを含むend-to-end pathを別々に検証する。
Ownership / Control / Data plane boundary
Network Group間をmeshまたはhub-spokeでどう接続するかをcentral teamが宣言する。
hubはshared connectivity / gateway / inspectionを提供するが、application dependencyはspoke側が所有する。
connectivity作成とnext-hop制御は同義ではない。UDR/BGP/NVAを別レイヤーで評価する。
configuration deployment targetとworkload regionを合わせ、multi-regionを一つのfailure domainとして扱わない。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Topology type | meshとhub-spokeのどちらがtrust boundaryとtraffic patternに合うか。 | topology diagram、traffic matrix、spoke-to-spoke policy。 |
| Direct connectivity | spoke間をhub/NVA経由に固定するか、direct pathを許可するか。 | allowed pairs、inspection requirement、exception。 |
| Regional model | region内topologyとcross-region接続をどう分離するか。 | hub per region、global connectivity policy、failover path。 |
| Gateway use | hub gatewayをspokeから利用するか。 | gateway dependency、BGP/propagation、provisioning order。 |
| Configuration split | 一つの巨大configurationか、failure domain別に分割するか。 | config ownership、deployment wave、rollback unit。 |
| Verification | peering/config status以外に何をdata planeで確認するか。 | positive/negative flow、next hop、DNS、hybrid path、latency。 |
実装・展開の順序
- existing topologyを採取する。 VNet/peering/gateway/route table/BGPとtraffic matrixをread-onlyでinventoryする。
- Network Groupを小さく定義する。 canary spokeを選び、誤membershipがないことを確認する。
- connectivity configurationをdraftする。 hub、topology、direct connectivity、global option、gateway利用を明示する。
- 対象regionへdeployする。 まず一つのregion / canary groupでactive stateを確認する。
- end-to-endを検証する。 source→destinationのapplication journeyに加え、禁止されるspoke-to-spoke flow、NVA path、DNS、hybridを確認する。
- wave展開する。 route convergence / existing sessions / gateway loadを監視しながらregion・group単位で拡張する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Topology | hub / mesh / group bindingとcentral standardを定義。 | 必要なeast-west / north-south dependencyを申告。 |
| Hub services | gateway、Firewall/NVA、DNS/Bastion等のshared serviceを運用。 | shared serviceの利用条件に合わせてspokeを構成。 |
| Spoke | 接続されるNetwork Groupとcentral guardrailを管理。 | subnet、NIC、NSG、application endpointを所有。 |
| Routes | central route intent / gateway propagationを管理。 | workload固有route dependencyとasymmetry riskを提示。 |
| Verification | cross-spoke / hybridの共通testを用意。 | 実application flowとnegative testを実施。 |
Verification / review evidence
設計レビューで残す証拠
- 変更前のVNet peering / gateway / route topology
- Network Group membershipとconnectivity configuration source/version
- target regionsとdeployment status
- traffic matrix（hub-spoke / spoke-spoke / hybrid / internet）
- gateway/NVA/DNS dependencyとfailure path
- rollback configurationとknown-good connectivity evidence
runtimeで確認すること
- hub↔spokeのrequired flowが双方向で成立すること
- spoke↔spokeがdesign通りdirect / via inspection / deniedになること
- effective route / next hopがintended pathを示すこと
- hybrid routeとgateway propagationが期待prefixを持つこと
- DNS query pathがnew topologyでも変わらず成立すること
- configuration rollback後にpeer/pathがknown-goodへ収束すること
az network manager connect-config list --network-manager-name <manager> --resource-group <rg> -o tableaz network manager list-deploy-status --network-manager-name <manager> --resource-group <rg> --region <azure-region> -o jsoncCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| connectivity configはactiveだが通信不可 | route/NSG/security admin/DNS/NVAを確認せずtopologyだけ見ている。 | packet pathをroute→security→DNS→service listenerまで分解。 |
| spoke間が想定外にdirect通信する | direct connectivity/global optionとtrust policyの不一致。 | configuration optionとtraffic matrixを照合し、negative testを追加。 |
| hub gateway経由が成立しない | gateway未準備、route propagation/BGP前提不一致。 | gateway provisioning、effective route、advertised/learned prefixを確認。 |
| 一regionの変更で広範囲障害 | 巨大configurationを複数failure domainへ一括deploy。 | region/groupでconfigまたはwaveを分け、canaryを必須化。 |
| deploy後すぐの一時状態をfailureと誤認 | eventual consistency / convergenceを考慮せず瞬間値だけ評価。 | deploy statusとdata planeの収束を時間軸で観測し、timeout条件を定義。 |
Change safety / rollback
Current notes — 2026-09-11
Azure CLIの`az network manager connect-config`はcurrent documentation上GAのcommand groupとして提供され、virtual-network-manager extensionの利用が前提になる。CLI/support levelは変化し得るため自動化へ固定する前にcurrent referenceを再確認する。