Azure Management Groups

解決する課題

• サブスクリプションが増えると、ポリシーやアクセス権限をサブスクリプションごとに個別設定する運用が破綻する
• 部門・環境（本番/開発）・地域などの単位で、ガバナンスをまとめて適用したい
• 全社共通のルール（許可リージョン、必須タグ、禁止リソース種別など）を、一箇所で定義して全体へ波及させたい
• 「誰が・どの範囲で操作できるか」を、サブスクリプション横断で一貫して統制したい

主要概念と用語

• 管理グループ（Management Group）: サブスクリプションをまとめるコンテナ。管理グループの中に管理グループやサブスクリプションを入れ子にして階層を作れる
• ルート管理グループ（Tenant Root Group）: テナントに 1 つだけ存在する最上位の管理グループ。すべての管理グループとサブスクリプションの祖先にあたる
• 階層（Hierarchy）: ルートを頂点としたツリー構造。上位に設定したものが下位へ継承される
• 継承（Inheritance）: 上位の管理グループに割り当てた Azure Policy や RBAC ロールが、配下のすべての管理グループ・サブスクリプション・リソースに自動で適用される性質
• スコープ（Scope）: 設定を適用する範囲。管理グループ、サブスクリプション、リソースグループ、リソースという入れ子の階層になっている
• Azure Policy / イニシアティブ: 管理グループに割り当てると配下を一括統制できる、コンプライアンス定義の仕組み
• テナント（Microsoft Entra テナント）: 管理グループ階層が属する組織の単位。階層はテナント境界を越えられない

仕様・制限・クォータ

• ルート管理グループはテナントに 1 つで、自動的に作成される。これを削除したり移動したりはできない
• 階層には入れ子の深さに上限がある（おおむね数階層程度）。実運用では深くしすぎず、浅く分かりやすい構造が推奨される
• 1 つのサブスクリプションや管理グループは、親を 1 つだけ持つ（複数の親には属せない）
• 1 テナントあたりの管理グループ総数にも上限があるが、通常の組織設計では十分な余裕がある
• 新規作成時、当初はすべてのサブスクリプションがルート直下に位置づけられ、そこから階層へ整理していく
• 管理グループの操作には、親側に対する適切な権限が必要（後述のセキュリティ参照）

内部の仕組み

管理グループは、サブスクリプションの「上」に位置するスコープのコンテナです。Azure のコントロールプレーン（Azure Resource Manager）は、ある操作の可否を判断する際に、リソースから親方向（リソースグループ → サブスクリプション → 管理グループ → ルート）へさかのぼって、各スコープに割り当てられたポリシーと RBAC を合成して評価します。

• 継承は上から下へ一方向。上位スコープの割り当ては下位で取り消せず、下位スコープでは「さらに絞る」追加の制約しか足せない
• 複数スコープのポリシーが重なった場合、より上位の拒否（Deny）が優先される傾向にあり、組織レベルのガードレールが効く
• RBAC も同様に継承され、上位で付与したロールは配下の全リソースに及ぶ
• サブスクリプションを別の管理グループへ移動すると、新しい親の継承が即座に適用され、古い親由来の継承は外れる

設計パターン / ベストプラクティス

• 環境やガバナンス境界で階層を分ける（例: 本番 / 非本番、規制対象 / 非対象）。組織図そのままより、ポリシーの適用単位で切る方が運用しやすい
• 共通ガードレールはなるべく上位に置き、例外は下位スコープで個別に扱う。重複設定を減らせる
• ルート直下に「サンドボックス」や「隔離（Quarantine）」用の管理グループを設け、新規サブスクリプションを一旦そこへ入れて検証してから本番階層へ移す
• Azure Policy のイニシアティブを管理グループに割り当て、許可リージョン・必須タグ・禁止 SKU などをまとめて統制する
• 階層・ポリシー・RBAC を IaC（Bicep / Terraform）で管理し、ガバナンス構成をコードで追跡可能にする
• Microsoft のランディングゾーン（Cloud Adoption Framework）の管理グループ設計を参考にすると、定石に沿った構造を作りやすい

運用・監視

• Azure Policy のコンプライアンス状態を管理グループ単位で集約し、組織全体の準拠率を俯瞰する
• アクティビティログで、管理グループへのポリシー割り当て・ロール割り当て・サブスクリプション移動などの操作を監査する
• サブスクリプションの所属（どの管理グループの配下か）の棚卸しを定期的に行い、想定外の階層配置を是正する
• ルートや上位への割り当て変更は影響範囲が広いため、変更管理プロセスに載せて段階的に展開する
• コスト管理（Cost Management）と組み合わせると、管理グループ単位での集計で部門横断のコスト可視化ができる

コスト

管理グループ自体の利用に追加料金は発生しないのが基本です。ガバナンスのためのコンテナであり、課金対象のリソースではありません。実際の費用は、その配下にあるサブスクリプションやリソースの利用に対して通常どおり発生します。むしろ、ポリシーで禁止 SKU や許可外リージョンを抑止することで、無駄なコストの発生を未然に防ぐ側面があります。

セキュリティ

• 上位スコープの RBAC を継承できるため、組織横断の権限設計を一元化できる
• 管理グループの作成・移動・割り当てには、親スコープに対する権限が必要。例えば既定では、サブスクリプションを管理グループへ移すには移動元・移動先の双方に適切な権限が求められる
• ルートへの割り当てはテナント全体に及ぶため、ルートに対する権限保有者を厳格に絞る
• Azure Policy を管理グループに割り当て、禁止リソース種別や必須構成を組織レベルで強制するガードレールを敷ける

Well-Architected の観点

• セキュリティ: ポリシーと RBAC を上位スコープに集約し、組織全体に一貫したガードレールを継承させられる。許可リージョンや禁止リソースの強制で攻撃面と逸脱を抑える
• オペレーショナルエクセレンス: ガバナンスを一箇所で定義して全体へ波及させることで、サブスクリプションごとの個別運用をなくし、構成の標準化と監査の一元化を進められる

試験で問われるポイント

関連サービス・比較

管理グループは、AWS Organizations の OU（組織単位）に最も近い概念です。ポリシー継承の仕組みは、AWS の SCP（サービスコントロールポリシー）に Azure Policy が対応します。

ハンズオン / CLI例

# 管理グループを作成（部門単位の例）
az account management-group create \
  --name finance-mg \
  --display-name "Finance Department"

# 既存の管理グループの配下に子の管理グループを作る（本番用）
az account management-group create \
  --name finance-prod-mg \
  --display-name "Finance Production" \
  --parent finance-mg

# サブスクリプションを管理グループの配下へ移動
az account management-group subscription add \
  --name finance-prod-mg \
  --subscription "00000000-0000-0000-0000-000000000000"

# 管理グループにポリシーを割り当て、許可リージョンを統制（配下へ継承）
az policy assignment create \
  --name "allowed-locations" \
  --display-name "Allowed locations" \
  --scope "/providers/Microsoft.Management/managementGroups/finance-mg" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --params '{ "listOfAllowedLocations": { "value": ["japaneast", "japanwest"] } }'

# 階層を確認（配下の子要素も含めて取得）
az account management-group show \
  --name finance-mg \
  --expand --recurse -o table