前提知識
リソースとリソースプロバイダについて知っている必要があります。
Azure には「リソース」という概念があり、リソース単位で各種コンポーネントを管理しています。リソースプロバイダはそのリソースを提供し管理するものです。
より詳細は以下 URL をご参照ください。
サブスクリプションとは
サブスクリプションとは、一般的に「定期購読」「定期購入」などと訳されますが、こと Azure においては大きく以下 2 つの意味合いがあります。
- Azure の従量課金サービスの支払単位
- Azure ポリシーや RBAC でのスコープ (どの範囲のリソースに適用するかの範囲指定)
支払単位としてのサブスクリプション
Azure を使い始めるための一般的なステップとして、まずはサブスクリプションを作成し、クレジットカード情報を紐づける必要があります。(ただし、サブスクリプションには色々な種類があり、例えば MS の研修用のサブスクリプション等もあったりします。その場合はクレジットカード情報は不要です。)
Azure で VM を立てたり、ストレージアカウントでファイルを保存したり、コンテナを動かしたりする場合は、そのサブスクリプション配下で「リソース」を作りますが、その従量課金のコストはサブスクリプションのクレジットカードに対して請求されます。
識別しなければならない点として、MS365 等の SaaS ライセンスはユーザー単位での定額ライセンスになり、サブスクリプションでの支払いの対象外です。
スコープとしてのサブスクリプション
Azure の管理者は Azure ポリシーや RBAC (ロール) を設定することにより、他の Azure 利用者が勝手に色々な操作ができないように制限を掛けることができます。
例えば Azure ポリシーなら「このサブスクリプションの配下のリソースは、必ずロケーションは East US を使わせる」といったポリシーを作ったり、RBAC なら「User-A は、このサブスクリプション配下のみ、VM に関する操作を許可する」といった設定をすることができます。
次に、User-A に対し、サブスクリプション A をスコープとして、Bulitin (予めセットされている) ロールである「ネットワーク共同作成者」を RBAC として設定した場合の例を示します。
参考までに、Azure Portal から「ネットワーク共同作成者」の定義 (JSON ビュー) を確認すると以下のようになります。
"Microsoft.Network/*" 以外にも "Microsoft.Authorization/*/read" (RBAC 設定の読取権限) や "Microsoft.Resources/deployments/*" (各種リソースをデプロイに関する全操作権限) 等もあることが分かります。
なお、今回の例ではスコープとして「サブスクリプション」を指定しましたが、「リソースグループ」、「リソースそのもの」を指定できます。また、サブスクリプションをまとめる単位として「管理グループ」というものもあり、これにより複数のサブスクリプションをまとめて、1 つのスコープとして指定することもできます。
管理グループは「ルート管理グループ」を起点として 6 段までネストすることが可能です。また、次に説明しますが、リソースグループもネスト構成は組めず、1段までしか作れません。(リソースグループの配下にリソースグループは作れません。)
リソースグループとは
Azure は様々なコンポーネントを「リソース」として管理しますが、このリソースを束ねるのがリソースグループです。サブスクリプションの 2 つ目の意味合いと同様、Azure ポリシーや RBAC のスコープとしても働きますが、それ以外にも色々と特徴があります。
具体的に、リソースグループには以下の特徴があります。
- リソースグループはサブスクリプションの直下に作られる
- リソースを作成するときは必ずリソースグループを 1 つだけ指定する
- リソースグループの下にリソースグループは作れない (ネスト構成は不可)
- リソースグループを削除すると、その配下のリソースは全て削除される (つまり、ライフサイクルを共にするリソースを同一リソースグループに収める)
- リソースグループをスコープとして指定した際、Azure ポリシーや Azure RBAC は配下のリソースにまで及ぶ
- リソースグループ自体にタグをつけても、タグは配下のリソースには継承されない
- リソースグループ配下のリソースは、リソースグループとロケーションが異なっていてもよい
- リソースグループには配下のリソースのメタ情報が含まれている
上記で注意すべき点を解説していきます。
リソースは複数のリソースグループに所属することはできません。また、リソースグループはフラットな関係であり、ネスト構成にはできません。
リソースグループを削除するときは、その配下のリソースも一緒に削除されます。つまり、リソースグループを選択するときの基準として「ライフサイクルが同じリソース」をまとめるのが良いでしょう。
リソースグループをスコープとした Azure ポリシーや RBAC は、その配下のリソースにまで影響が及びますが、リソースグループにタグを付けても、その配下のリソースにはタグは付けられません。
リソースグループにもロケーション設定が必要ですが、配下のリソースと揃っている必要はありません。ただし、リソースグループには配下のリソースのメタ情報が含まれるため、そのロケーション (リージョン) の障害においては管理面で影響を及ぼします。
例えばリソースグループ RG1 が East US に所属しており、その配下のリソースとして VM 等の一式が Japan East だったとします。そして East US に障害が発生した場合、Japan East のリソースは稼働し続けますが、リソースグループにアクセスできないため、Azure Portal から Japan East の各種リソースにアクセスできなくなります。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント