2.2リソースの階層（管理グループ・サブスクリプション・リソースグループ）

Azure を使い始めると、VM・ストレージ・データベースといったリソースがすぐに数百・数千に増えます。これらを整理し、権限やコストを統制するために、Azure には4段の階層が用意されています。上から 管理グループ ＞ サブスクリプション ＞ リソースグループ ＞ リソース。上位ほど広い範囲をまとめ、下位ほど個々の実体に近づきます。この入れ子を理解すると、「どこにルール（ポリシーや権限）を当てれば、どこまで効くか」が見通せます。

2.2.14つの階層

1. 管理グループ（Management group）：複数のサブスクリプションをまとめる最上位のコンテナ。組織全体や部門単位で、ポリシーやアクセス制御を一括適用する。入れ子にもできる。
2. サブスクリプション（Subscription）：課金と利用の境界であり、リソースの論理的な入れ物。請求や上限（クォータ）の単位で、部門・環境（本番/開発）ごとに分けることが多い。
3. リソースグループ（Resource group, RG）：関連するリソースをまとめるコンテナ。権限やライフサイクル（まとめて削除など）を一括で扱える。1つのリージョンに「所属情報」を持つが、中のリソースは別リージョンでもよい。
4. リソース（Resource）：VM・ストレージアカウント・データベースなど、個々のサービスの実体。必ず1つのリソースグループに属する（複数には属せない）。

2.2.2スコープと継承

この階層が効いてくるのが スコープ（適用範囲）と継承 です。アクセス制御（RBAC）や Azure Policy は、4つのどの階層にも割り当てられ、割り当てた階層より下のすべてに継承（伝播）されます。たとえば管理グループに「特定リージョンしか使わせない」ポリシーを当てれば、配下の全サブスクリプション・全リソースグループ・全リソースに自動で効きます。広く効かせたいルールは上位に、限定的なルールは下位に当てる——これが統制（ガバナンス）の基本戦略です。

2.2.3Azure Resource Manager（ARM）

Azure Resource Manager（ARM）は、リソースの作成・変更・削除を受け付ける統一された管理レイヤーです。Azure ポータル・Azure CLI・Azure PowerShell・SDK・ARM テンプレート / Bicep など、どの入口から操作しても、要求はすべて ARM を通ります。だからこそ、どのツールを使っても一貫した認証・アクセス制御（RBAC）・タグ・ロックが効くのです。

ARM のもう一つの価値は 宣言的なテンプレート（ARM テンプレート＝JSON、または Bicep＝より簡潔な記法）です。「欲しい状態」をコードで書いて適用すると、ARM がその状態を作ります。同じテンプレートから同一環境を何度でも再現でき、構成をコード管理（IaC：Infrastructure as Code）できます。

ARM が提供する統制の道具も押さえましょう。タグは「key=value」のラベルをリソースに付け、部門・環境・コスト中心などで横断的に分類・集計できます（リソースグループの境界をまたいでコストを見たいときに有効）。リソースロックは、誤操作を防ぐために「削除禁止（CanNotDelete）」「読み取り専用（ReadOnly）」を設定する仕組みで、重要な本番リソースの事故的な削除・変更を防ぎます。これらはサブスクリプション・リソースグループ・リソースの各レベルで設定でき、下位へ継承されます。

実務では、増え続けるリソースを見失わないために 命名規則 と タグ付けの方針 を最初に決めるのが定石です。たとえば「環境-アプリ-リージョン-種別」のような命名や、必須タグ（owner / costCenter / env）を Azure Policy で強制しておくと、後からの整理やコスト按分が一気に楽になります。

2.2.4この節のまとめ

• 階層は 管理グループ ＞ サブスクリプション ＞ リソースグループ ＞ リソース
• サブスクリプション＝課金/利用の境界、リソースグループ＝コンテナ（リソースは1つのRGに属す）
• RBAC/Policy は割り当てた階層より下に継承＝広いルールは上位、限定ルールは下位に当てる
• ARM＝作成・変更・削除が通る統一管理レイヤー。テンプレート/Bicep で環境をコード化（IaC）