Routing ConfigurationをUDRの『大量投入ツール』ではなく、Network Groupに対するdesired routing behaviorとして設計する。既存route table、BGP/system route、NVA symmetry、eventual consistencyとの合成を確認し、configuration deploymentと実効next hopを別々に検証する。
VNM Routing Configurationを理解するための前提
Azure Virtual Network ManagerはRouting Configurationでdesired routing behaviorを記述し、UDRをorchestrateしてその状態を作成・維持する。 routing rule collectionはNetwork Groupをtargetにし、group membershipの変化に応じて対象VNet/subnetへrouting intentが適用・解除される。
標準的なmodelではAVNMがmanaged resource group内のroute tableを管理する。既存route tableへruleを追加するUseExistingのようなmodeはAPI/version依存のcurrent behaviorを確認して採用する。 UDRはsystem route / BGP route / service-specific behaviorと競合し得る。Routing Configurationが存在するだけで実packet pathを断定せず、effective routes / next hopを確認する。
Network Group join/leaveやconfiguration deploymentにはeventual consistencyがある。大量VNetを同時にmembership変更するとroute convergence中の一時状態を考慮する必要がある。 Firewall/NVAへforced pathを作る場合、return pathとstateful deviceのsession symmetryをtraffic matrixに含める。片方向のnext hopだけでPASSにしない。
2026-09-11時点でMicrosoft LearnのAzure CLI referenceは`az network manager routing-config` command groupをPreviewと表示している。feature全体とCLI command support levelを混同しない。
Ownership / Control / Data plane boundary
Routing Configuration / rule collection / ruleが中央のroute intentを定義する。
AVNM-managedまたは既存route tableへ反映されたUDRがresource stateとなる。
system/BGP/UDR等をAzureのroute selectionで合成し、effective routeが実際の候補を示す。
NVA / Firewall / gateway / destinationまで実packetが双方向に通るかが最終判定。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Target granularity | どのNetwork Groupに同じroute intentを適用できるか。 | group taxonomy、excluded VNet/subnet、rule collection owner。 |
| Route-table mode | AVNM-managed route tableを使うか、既存route tableとの共存が必要か。 | ownership、API capability確認、IaC authority、rollback method。 |
| Next hop | Firewall/NVA/VPN/ER等のどこへ送るか。 | prefix、next-hop type/address、HA model、symmetry。 |
| BGP interaction | gateway/Route Server/Virtual WAN等のlearned routeとどう合成するか。 | propagation expectation、effective route test、failure behavior。 |
| Scale | membership変更とroute updateをどのwaveで展開するか。 | canary、batch size、convergence timeout、stop condition。 |
| Tooling | CLI/PowerShell/APIのsupport levelをautomation requirementにできるか。 | pinned API/CLI version、preview acceptance、fallback deployment method。 |
実装・展開の順序
- effective route baselineを保存する。 canary NIC/subnetで現行route table、BGP propagation、next hopを記録する。
- route intentを表にする。 destination prefix、expected next hop、source group、return path、failure pathをroute matrixへ固定する。
- routing configurationをdraftする。 existing tableとのownership conflictがないことを確認し、rule collectionを小さく保つ。
- canary group / regionへdeployする。 control-plane deploy statusとroute table更新を確認し、収束を待つ。
- data planeを試験する。 effective route / next hop、NVA logs、positive/negative flow、return pathを同じ5-tupleで確認する。
- wave拡張する。 membership変更を同時大量実施せず、convergence/error signalを見ながら段階反映する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Route intent | shared prefix / central next-hop standardを定義。 | applicationが必要なdestination/prefixとexceptionを提示。 |
| Route tables | AVNM-managed resourceとIaC authorityを管理。 | workload側で同一route tableを無断上書きしない。 |
| NVA / Firewall | HA、health、return path、capacityを管理。 | applicationのstateful flow/timeout要件を共有。 |
| BGP / gateways | propagationとlearned prefixの共通設計を管理。 | hybrid dependencyとon-prem destinationを申告。 |
| Verification | effective route / next-hop共通観測を提供。 | 実application journeyとfailure recoveryを検証。 |
Verification / review evidence
設計レビューで残す証拠
- 変更前後のeffective route tableとselected next hop
- routing configuration / rule collection / Network Groupのsource/version
- target region deployment statusとconvergence timestamp
- route matrix（source group / destination prefix / next hop / return path）
- NVA/Firewall healthとstateful session evidence
- rollback configurationおよび旧route table state
runtimeで確認すること
- canary NICでexpected prefixのeffective next hopが一致すること
- NVA/Firewallの両方向logで同じflowが観測できること
- hybrid BGP prefixとUDRの優先関係が設計通りであること
- 禁止destinationが別routeへ逃げずfail-closedになること
- membership join/leave後にrouteが所定時間内で収束すること
- NVA failover / rollback後にsessionとrouteがknown-goodへ戻ること
az network manager routing-config list --network-manager-name <manager> --resource-group <rg> -o tableGet-AzNetworkManagerRoutingConfiguration -NetworkManagerName <manager> -ResourceGroupName <rg>Common failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| routing configをdeployしたがnext hopが変わらない | 対象group/region不一致、route table association/reflect遅延、別routeが選択。 | membership・deployment・route table・effective routeを順に確認。 |
| 往路だけNVA経由でsessionが失敗 | return pathが別gateway/direct pathになりasymmetric。 | source/destination両側のeffective routeとNVA session logを比較。 |
| 既存IaCがroute tableを元に戻す | AVNMとTerraform/Bicep等が同じresource stateのauthorityを競合。 | single writerを決め、ownershipをIaC module境界に反映。 |
| 多数VNetで一時的route差異 | dynamic membershipとregional deploymentを一度に大規模変更。 | waveを分離し、eventual consistencyの収束条件を監視。 |
| CLI自動化がupgradeで壊れる | Preview command groupをversion pin/compatibility testなしでproduction pipelineへ固定。 | support levelを明示し、CLI extension/API versionをpinしてpreflight test。 |
Change safety / rollback
Current notes — 2026-09-11
2026-09-11時点のMicrosoft Learnでは`az network manager routing-config`配下のAzure CLI command groupはPreviewと明記されている。Routing Configurationのservice conceptとCLI automation surfaceのsupport levelは別に評価する。