AVNMを「VNetを作る製品」ではなく、組織スコープに対して意図したnetwork stateを配布するcontrol planeとして扱う。Network Groupへの所属、configurationの所有者、deployment region、exceptionとrollbackの境界を先に固定し、workload teamが担うNSG・subnet・application側の責任を奪わない。
Azure Virtual Network Managerを理解するための前提
Scopeはmanagement groupまたはsubscriptionで定義し、その配下のVNetだけを管理対象にする。最初に「誰がどのsubscriptionをmanager scopeへ入れるか」を決める。 Network GroupはVNetを論理的に束ねるpolicy適用単位であり、static membershipまたはAzure Policyを使ったdynamic membershipで管理できる。所属そのものは通信許可を意味しない。
Connectivity configurationはmesh / hub-and-spoke等の接続意図、security admin configurationはNSGより上位のcentral guardrail、routing configurationはUDRのdesired stateを配布する。 configurationは作成しただけでは対象VNetへ有効化されず、対象network resourceが存在するregionへdeployして初めて効力を持つ。draftとactive stateを分けてchange reviewする。
IPAMはaddress poolから重複しないCIDRを払い出す中央機能で、connectivity/security featureを使わないAVNM instanceでも利用できる。 AVNMはcentral controlのblast radiusが大きい。全region / 全network groupへの一括deployを標準手順にせず、canary group・region単位の段階展開・effective state確認をchange contractに含める。
manager scope、Network Group、configuration、deploymentの4層を別物として記録する。『managerにVNetが見える』ことと『configurationがそのVNetでactive』であることを混同しない。
Ownership / Control / Data plane boundary
Management group / subscriptionを境界に、AVNMが参照・構成できるVNetの範囲を定義する。
Network Group membershipとconnectivity / security / routing configurationが『望ましい状態』を表す。
configurationをtarget regionへdeployしてactive stateへ反映する。deploy前のdraftはdata planeを変えない。
subnet、NIC、NSG、Private Endpoint、application dependencyなどはworkload固有の設計として残し、central configurationとの合成結果を確認する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Manager scope | どのmanagement group / subscriptionを一つの変更blast radiusとして扱うか。 | scope owner、excluded subscription、cross-tenant要件、RBAC assignment。 |
| Network Group model | region / environment / trust zone / connectivity roleのどの軸でgroup化すれば、membershipが安定して説明できるか。 | group taxonomy、static/dynamic条件、exception process、owner。 |
| Configuration ownership | connectivity・security・routingを同一teamが所有するか、責務別に分離するか。 | configuration owner、reviewer、deployment approver、emergency path。 |
| Deployment unit | 一度にどのregion / groupへ反映するか。 | canary、wave、maintenance window、success signal、stop condition。 |
| Workload autonomy | central teamが固定するguardrailとworkload teamに残す自由度は何か。 | NSG/UDR ownership、local exception、shared-service consumption contract。 |
| State evidence | desired stateとeffective stateの差を何で検知するか。 | IaC/Policy source、deploy status、effective config、route/security runtime evidence。 |
実装・展開の順序
- Scopeを最小から作る。 対象management group / subscriptionとRBACを確認し、既存VNetを誤って大規模変更しないread-only inventoryを先に取得する。
- Network Groupを定義する。 まずstatic membershipで意図を確認し、dynamic Azure Policyへ移行する場合はpreview membershipと既存tag/name metadataの品質を確認する。
- configurationをdraftする。 connectivity / security / routingを同時に変えず、変更理由と期待されるeffective stateをconfigurationごとに分離する。
- canaryへdeployする。 影響の限定されたnetwork group / regionから反映し、deploy statusだけでなく実際のreachability、effective route、security evaluationを検証する。
- waveを拡大する。 既知のpositive / negative flow、hybrid path、shared DNS、egress、Private Endpoint等を各waveで再確認する。
- drift監視へ移行する。 source-controlled definition、Azure Policy membership、AVNM active configurationとruntime stateの差を継続監視する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Scope / RBAC | management group / subscriptionのscope、AVNM role、central approverを定義。 | 自分のsubscriptionがどのcentral scopeに属するかを把握し、必要なdelegated roleだけを保持。 |
| Network Groups | group taxonomy、dynamic membership policy、exceptionを管理。 | VNet metadataを規約に合わせ、意図しないgroup join/leaveをchangeとして扱う。 |
| Connectivity | hub/mesh topology、direct connectivity、regional deploymentを管理。 | application dependencyと必要なeast-west flowを申告し、実flowを検証。 |
| Security admin | organization-wide guardrailとexception collectionを管理。 | NSGでapplication固有のleast privilegeを実装し、central ruleとの合成結果を確認。 |
| Routing | central next-hop / UDR orchestrationの意図を管理。 | workload subnetのroute dependency、NVA symmetry、service-specific route requirementを提示。 |
| IPAM | address pool hierarchy、delegation、allocation policyを管理。 | delegated poolから必要prefixを取得し、勝手な直接CIDR割当を避ける。 |
Verification / review evidence
設計レビューで残す証拠
- manager scope一覧と対象subscription / management groupの承認済みinventory
- Network Groupごとのmembership根拠（static listまたはdynamic Azure Policy condition）
- configuration version / source commit / reviewer / target region / deploy wave
- change前後のdeploy statusとeffective connectivity / security evidence
- IPAM pool hierarchyとallocation owner、重複チェック結果
- rollback対象configurationと停止条件を含むchange record
runtimeで確認すること
- 対象VNetが想定Network Groupへ所属し、不要なgroupへ入っていないこと
- 対象regionで期待configurationがactiveになっていること
- hub/spokeやmeshの到達性がtraffic matrix通りで、禁止flowは失敗すること
- security admin ruleとNSGの合成結果が期待通りであること
- effective routes / next hopが想定され、NVA経由flowのsymmetryが崩れていないこと
- rollback後にroute convergenceと既存sessionを含むdata-plane状態が安定すること
az network manager list -o table
az network manager show --name <manager> --resource-group <rg> -o jsoncGet-AzNetworkManager | Select-Object Name, ResourceGroupName, LocationCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| VNetはmanagerに見えるのに設定が効かない | configurationを作成したがtarget regionへdeployしていない。 | deploy statusとactive/effective configurationを確認し、draft存在だけで完了判定しない。 |
| 想定外VNetが突然policy対象になる | dynamic membership条件がtag/name等の可変metadataへ過度に依存。 | membership条件、Azure Policy assignment scope、VNet metadata変更履歴を確認。 |
| 中央変更で多数workloadが同時断 | blast radiusをscope=変更単位と誤認し、全regionへ一括deploy。 | canary group / region、wave、negative test、stop conditionを導入。 |
| NSGを直しても通信が戻らない | security admin ruleが先にDenyしている、またはrouting configurationがpathを変更。 | security→route→NSGのeffective stateを層ごとに確認。 |
| IaCと実環境の説明が一致しない | source definition、AVNM draft、active deployment、workload local configのversionが混在。 | 4層のversion/evidenceをchange recordへ紐付ける。 |
Change safety / rollback
Current notes — 2026-09-11
2026-09-11時点のMicrosoft Learnでは、AVNM configurationは対象network resourceのregionへdeployするまで効力を持たないと明記されている。RoutingやIPAMを含む機能・CLIのsupport levelは個別に変化し得るため、導入時は各featureとtoolingのcurrent documentationを再確認する。