AZ700-CORE#103
新規 AVNM (Azure Virtual Network Manager) で大規模 Hub-Spoke 環境 (50 Spoke VNet) を集中管理する手順を順序付けてください。
- AVNM リソースを作成 (Scope: 適用対象 サブスクリプション、Features: Connectivity + Security Admin)
- Network Group を作成 (Spoke 用)、動的メンバーシップで Azure Policy 風に「タグ env=prod の VNet を自動所属」と定義
- Connectivity 構成を作成 (Topology: Hub and Spoke、Hub VNet を指定、Network Group を Spoke として割り当て)
- Security Admin 構成を作成 (Always Deny RDP/SSH from Internet、Always Deny SQL 1433 from Public 等)
解説
【正しい順序】
- ステップ 1: AVNM リソース作成
- ステップ 2: Network Group 作成 + 動的メンバーシップ
- ステップ 3: Connectivity 構成
- ステップ 4: Security Admin 構成
【各ステップの理由】
- ステップ 1: AVNM 作成: すべての構成の親リソース。Scope (適用対象サブスクリプション) と Features (Connectivity + Security Admin) を最初に確定。
- ステップ 2: Network Group: VNet をグループ化、動的メンバーシップでタグ評価により自動所属。50 VNet を一つひとつ手動追加せず、Azure Policy 風の動的評価で「タグ env=prod の VNet を自動 Spoke 所属」を実現します。
- ステップ 3: Connectivity 構成: Hub VNet を指定し、Network Group を Spoke として割り当て。AVNM が各 Spoke→Hub のピアリングを自動生成。
- ステップ 4: Security Admin 構成: Always Deny ルール (RDP/SSH Internet 公開禁止) や Always Allow (組織標準許可) を定義。Network Group に対して一括適用します。
【AVNM のメリット (規模別)】
| VNet 数 | 手動管理 | AVNM 利用 |
|---|---|---|
| 1〜10 | 運用可能 | 過剰投資の可能性 |
| 10〜50 | 運用負担 増加 | 推奨 (大きな効率化) |
| 50+ | 破綻リスク | 必須 |
【動的メンバーシップ式の例】
// Network Group 動的メンバーシップ式 (Azure Resource Graph)
Resources
| where type =~ "microsoft.network/virtualnetworks"
| where tags.env == "prod"
| where tags.region == "eastus"【誤った順序の問題点】
- ❌ Connectivity 構成を Network Group なしで作成: 適用対象が定義されておらず、構成が機能しない。
- ❌ Deploy を構成完了前に実行: 未完成の構成が VNet に適用され、想定外の影響。
- ❌ 検証をスキップ: 誤った構成が本番環境に影響し続けるリスク。
コメント