Network Groupを単なるフォルダーではなく、中央network policyの適用対象を決めるselectorとして扱う。membership条件の安定性、owner、exception、group join/leave時の影響を明示し、『groupに入った＝通信可能』とは扱わない。
Virtual Network Manager Network Groupsを理解するための前提
Network GroupはAVNM scope内のVNetを論理的に束ね、connectivity・security admin・routing configurationから参照するための適用単位になる。 membershipはstaticにVNetを追加する方法と、Azure Policy条件でdynamicに判定する方法がある。dynamic membershipは条件充足の変化に合わせてVNetが自動join/leaveする。
Network Groupへの所属自体はdata-plane connectivityを作らない。どのconfigurationがそのgroupを参照し、どのregionへdeployされたかまで確認して初めてeffective behaviorを説明できる。 dynamic membership条件にtagを使う場合、tag更新がnetwork changeになる。tagを『管理用ラベル』だけと考えず、policy selectorとしての変更管理を行う。
同じVNetが複数Network Groupに所属できる設計では、各configuration側で重複適用時の意味を明示し、group名だけから最終挙動を推測しない。 AVNMを削除しても、dynamic membership用に作成したAzure Policy assignmentが残る可能性がある。decommissionではPolicy側もinventoryしてcleanup対象に含める。
group taxonomyはregion / environment / trust / connectivity role等から、長期間安定する1〜2軸を選ぶ。workload名を無制限にgroup化してcentral modelを肥大化させない。
Ownership / Control / Data plane boundary
Network Groupは『誰に適用するか』を決める。traffic policyそのものではない。
dynamic conditionが参照するtag / resource propertyは、実質的にnetwork policy inputとなる。
connectivity / security / routingはgroupを参照して別々に定義される。
VNet create / tag change / move / deleteに伴うjoin/leaveをchange eventとして監視する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Grouping axis | region・environment・trust・connectivity roleのどれがpolicy適用に本当に必要か。 | group taxonomy、命名、owner、利用するconfiguration。 |
| Static vs dynamic | membershipの変更頻度と自動化メリットが、誤joinのリスクを上回るか。 | 静的対象一覧またはPolicy condition、test fixture、exception path。 |
| Metadata source | dynamic conditionの入力は誰が変更できるか。 | tag/property owner、RBAC、change review、allowed values。 |
| Exception | 一時的・恒久的な除外をgroup条件に埋め込むか別groupへ分離するか。 | exception owner、expiry、approval、verification。 |
| Multi-group membership | 同一VNetが複数groupに入った場合に各configurationがどう合成されるか。 | allowed overlaps、forbidden overlaps、review query。 |
| Decommission | manager/group削除時に何が残るか。 | Azure Policy assignment、configuration、documentation cleanup list。 |
実装・展開の順序
- 対象VNet inventoryを固定する。 subscription / region / tags / address space / current topologyをread-onlyで取得する。
- 静的groupでsemanticを検証する。 group名、owner、どのconfigurationが参照するかを少数VNetでレビューする。
- dynamic条件をdry reviewする。 Azure Policy conditionが既存VNetをどう分類するかを一覧化し、unexpected join/leaveを0件にする。
- membershipとconfiguration deploymentを分離する。 同じchange windowで両方を大規模変更しない。
- canary membershipを反映する。 join後にactive configurationと実flowを確認し、想定外policyがないことを検証する。
- 継続監視する。 tag/property変更でmembershipが変わったらnetwork changeとして記録・通知できるようにする。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Group taxonomy | 全社で使うgroup軸、命名、用途を定義。 | 自VNetが属すべきrole/environmentを申告。 |
| Dynamic Policy | Policy definition / assignment scope / condition / exceptionを管理。 | condition入力になるtag/propertyを規約に沿って維持。 |
| Static membership | shared infrastructure等、固定対象をcentral teamが管理。 | 静的参加が必要な例外を申請し、不要時に解除依頼。 |
| Configuration binding | どのgroupをどのcentral configurationが参照するかを管理。 | 必要なcommunication/security intentを提示し、実際のapplication testを担当。 |
| Lifecycle | manager / policy / group decommissionのcleanupを管理。 | VNet move/delete時のdependencyを事前申告。 |
Verification / review evidence
設計レビューで残す証拠
- groupごとの目的・owner・利用configuration一覧
- static member resource IDまたはdynamic Azure Policy condition
- dynamic conditionを既存VNetへ適用したexpected membership表
- VNet join/leave前後のeffective configuration差分
- 同一VNetのmulti-group membership一覧と意図
- decommission時に残存Policy assignmentを確認するchecklist
runtimeで確認すること
- canary VNetが期待groupだけへ参加すること
- metadataを変更した場合、意図したjoin/leaveがeventual consistency後に反映されること
- group参加後も、configuration未deployならdata-planeが変化しないこと
- configuration deployment後にpositive/negative flowが期待通り変わること
- groupから外したVNetに不要なcentral configurationが残っていないこと
- decommission後にorphaned Azure Policy assignmentが残っていないこと
az network manager group list --network-manager-name <manager> --resource-group <rg> -o tableGet-AzNetworkManagerGroup -NetworkManagerName <manager> -ResourceGroupName <rg>Common failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| 意図しないVNetまでcentral policyが効く | dynamic conditionが広すぎる、またはtag valueが自由入力。 | Policy conditionと実membershipを照合し、allowed tag valuesとRBACを制御。 |
| groupへ追加したのに通信できない | membershipをconnectivityそのものと誤解。 | そのgroupを参照するconnectivity configurationとregional deploymentを確認。 |
| tag修正だけで通信挙動が変わった | tagがdynamic membership selectorであることがchange processに組み込まれていない。 | network-impacting metadataを定義し、tag changeへreviewを追加。 |
| AVNM削除後もPolicyが残る | dynamic membershipのAzure Policy assignmentをdecommission対象にしていない。 | Policy assignment inventoryを取得して不要なものを明示的にcleanup。 |
| groupが乱立して誰も意味を説明できない | workload単位にcentral groupを増殖させた。 | policy intentに必要な安定軸へ集約し、group ownerとconsumer configurationを必須metadata化。 |
Change safety / rollback
Current notes — 2026-09-11
Microsoft Learnは、Azure Policy条件の充足状態が変わるとVNetがNetwork Groupへ自動的にjoin/leaveし、追加のNetwork Manager操作は不要と説明している。したがってcondition入力になるtag/propertyはnetwork control inputとして扱う。