Zenn
☁️

AZ-104 を調べてみた04 ‐Azure IDとガバナンスの管理③

に公開
Azure
勉強
az104
idea

サブスクリプションとリソースグループの管理


サブスクリプション、リソースグループ、管理グループというAzureの基本構造を学びながら、管理や運用のベースとなる考え方を整理します。

4.1 サブスクリプションとは？ ー 請求と管理のスタート地点

サブスクリプションは、Azureリソースの課金と管理の単位です。企業での利用では、「開発」「テスト」「本番」など用途別に分けて使われるのが一般的です。

✅ サブスクリプションの基本

  • 契約の単位：Azureの利用料はサブスクリプション単位で計算・請求されます。
  • 作成方法：Azure Portal、CLI、PowerShellから作成可能。無料アカウントでの開始もOK。
  • 種類：従量課金（Pay-As-You-Go）、Enterprise Agreement (EA)、CSP など。

✅ 管理上よく出るポイント

  • 表示名の変更：後から管理しやすい名前（例：dev-subscription）に変更可能。
  • ディレクトリ移管：組織改編などでサブスクリプションを別のテナント（Microsoft Entra ID）に移動できます。RBACの再構成が必要になる場合もあり注意。
  • 所有者の設定：RBACで「所有者」ロールを付与することで、リソース管理の全権限を与えられます。AZ-104ではこのロールの権限と違いが問われることもあります。

4.2 リソースグループの活用 ー 論理的な整理箱

リソースグループは、関連するAzureリソース（VMやストレージなど）を論理的にまとめるコンテナです。課金は発生せず、管理のしやすさを向上させる目的で使われます。

✅ なぜ必要？

  • ライフサイクルの管理：プロジェクト単位で一括削除・作成が可能。
  • 環境や部門ごとに分類：誤操作を減らし、利用状況も把握しやすくなります。

✅ 試験で問われやすい操作

  • 作成・削除：削除時は中のリソースも一括で消える点に注意。

  • デプロイ時のルール：

    • リソースは必ずどこかのリソースグループに属する。
    • リソースグループとリソースのリージョンは必ずしも一致しなくてよい（ただし一貫性の観点では推奨されません）。

  • 移動：

    • リソースは後から別のリソースグループ、またはサブスクリプションに移動可能。
    • 一部のリソースには移動制限があるため、事前に公式ドキュメントを確認しておくと安心です。

  • ロック機能（Locks）：

    • 「削除ロック」「読み取り専用ロック」によって、意図しない操作を防止可能。特に本番環境では有効活用しましょう。

4.3 管理グループと階層ガバナンス ー 複数サブスクリプションを束ねる

組織が大きくなり、サブスクリプションが複数に分かれると、共通のルールを全体に適用したくなります。そこで使われるのが管理グループです。

✅ 管理グループとは？

  • 最上位のコンテナ：複数のサブスクリプションをまとめるための論理的な単位。
  • 組織的なポリシーやアクセス権の一元管理を目的に使用されます。

✅ 階層構造と継承の考え方

  • 最大6階層まで構築可能（ルート管理グループ含む）。
  • 上位に設定されたRBACやAzure Policyは、下位に自動で継承されます。

✅ 管理グループでできること

  • Azure Policyの一括適用：

    • 例：「特定リージョン以外にはVMを作成させない」「タグは必須」といった制限を強制可能。

  • RBACの統合管理：

    • 例：「開発チームには配下すべてのサブスクリプションへのContributor権限を与える」などが実現できます。

✅ 試験でよく問われる観点

  • 管理グループは「組織全体のガバナンスの起点」であること。
  • サブスクリプション → リソースグループ → リソースの階層構造に、管理グループを上位層として理解しておく。
  • ポリシーやRBACの継承ロジックを図で説明できると理解が深まります。

まとめ：AZ-104試験での要点

観点 試験ポイント
サブスクリプション 種類・作成方法・ディレクトリ移動の影響
リソースグループ 削除の影響、リージョンとの関係、移動可能性
管理グループ RBAC/Policyの継承、階層構造の理解

Azureの構造を「管理の階層構造」として捉えられるよう整理してみましょう！

補足① 階層構造と権限の継承

Azure RBAC の権限は、以下の階層構造を持つ「スコープ」のいずれかに割り当てられます。上位のスコープで与えられた権限は、その下のすべてのスコープに自動的に継承されます。

🏢 管理グループ (最上位レベル)
    ⬇️
📋 サブスクリプション (請求単位)
    ⬇️
📁 リソースグループ (リソースの論理的なグループ)
    ⬇️
⚙️ リソース (VM、ストレージなどの個別リソース)

補足② 継承の基本ルール

上位スコープで付与されたロールの割り当ては、すべての下位スコープに自動的に継承されます。これにより、階層的な権限管理が可能になります。

ルール項目 説明
📊 継承の流れ 管理グループ → サブスクリプション → リソースグループ → リソース の順で権限が継承されます。
🚫 継承のブロック 下位スコープでは、継承された権限を削除することはできません。継承は常に有効です。
➕ 権限の追加 下位スコープで追加の権限を付与することは可能です（継承された権限と追加権限が共存）。
🔒 拒否の優先 「拒否」の割り当てがある場合、それは「許可」よりも常に優先されます。

Discussion