Azure Resource Manager とは
Azure Resource Manager は、Azure のデプロイおよび管理サービスです。 お使いの Azure アカウント内のリソースを作成、更新、削除するために利用できる管理レイヤーを提供します。 デプロイ後にリソースを保護および整理するには、アクセス制御、ロック、タグなどの管理機能を使用します。
次のビデオでは、Resource Manager の基本的な概念について説明します。
一貫性のある管理レイヤー
ユーザーが Azure API、ツール、または SDK のいずれかを介して要求を送信すると、その要求はリソース マネージャーによって受信されます。 要求は、認証および承認された後、適切な Azure サービスに転送されます。 すべての要求は同じ API を介して処理されるため、すべての異なるツールで一貫した結果と機能が得られます。
次の図は、Azure の要求の中で Resource Manager が果たす役割を示しています。
Azure portal で使用できる機能はすべて、PowerShell、Azure CLI、REST API、クライアント SDK でも使用できます。 API によって新しい機能が導入されると、これは最初のリリースから 180 日以内にポータルに反映されます。
重要
Resource Manager は、TLS 1.2 より前のプロトコルのサポートを 2025 年 3 月 1 日に停止します。 詳細については、「Azure Resource Manager の TLS 1.2 への移行」を参照してください。
用語
Resource Manager を初めて利用されるお客様の場合、耳慣れていない可能性がある用語を次に挙げます。
リソース: Azure を通じて利用できる管理可能な項目。 リソースの例としては、仮想マシン、ストレージ アカウント、Web アプリ、データベース、仮想ネットワークなどがあります。 リソース グループ、サブスクリプション、管理グループ、タグもリソースです。
リソース グループ - Azure ソリューションの関連するリソースを保持するコンテナー。 リソース グループには、グループとして管理するリソースが含まれます。 組織にとって最も有用になるように、どのリソースをリソース グループに含めるかを決定します。 「リソース グループとは?」を参照してください。
リソース プロバイダー - Azure リソースを提供するサービス。 一般的なリソースプロバイダーの一例として、仮想マシン リソースを提供する
Microsoft.Computeがあります。Microsoft.Storageは、もう 1 つの一般的なリソースプロバイダーです。 「Azure リソース プロバイダーと種類」を参照してください。宣言型構文 - 構文を作成するために一連のプログラミング コマンドを記述しなくても、"作成しようとしているもの" を明確に宣言できる構文。 ARM テンプレートや Bicep ファイルは、宣言型構文の例です。 これらのファイルで、Azure にデプロイするインフラストラクチャのプロパティを定義します。
ARM テンプレート - リソース グループ、サブスクリプション、管理グループ、またはテナントにデプロイする 1 つ以上のリソースを定義する JavaScript Object Notation (JSON) ファイル。 リソースを一貫して繰り返しデプロイするには、テンプレートを使います。 テンプレートをデプロイする方法の概要については、「ARM テンプレートとは」を参照してください。
Bicep ファイル - Azure リソースを宣言によってデプロイするためのファイル。 Bicep は、Azure 内のコードとしてのインフラストラクチャ ソリューションに最適なオーサリング エクスペリエンスを提供するように設計された言語です。 Bicep の詳細については、「Bicep とは」を参照してください。
拡張リソース - 他のリソースに機能を追加するリソース。 たとえば、ロールの割り当ては拡張リソースの一種です。 ロールの割り当てを他のリソースに適用して、アクセスを指定します。 拡張リソースに関する記事を参照してください。
Azure の用語定義の詳細については、「Azure 基礎の概念」を参照してください。
Resource Manager には、いくつかの利点があります
Resource Manager を使用すると、以下のことができます。
スクリプトではなく宣言型のテンプレートを使用してインフラストラクチャを管理します。
ソリューションのリソースを個別に処理するのではなく、すべてのリソースをグループとしてデプロイ、管理、監視します。
ソリューションを開発のライフサイクル全体で再デプロイします。リソースは、必ず一貫した状態でデプロイされます。
正しい順序でデプロイされるように、リソース間の依存関係を定義します。
Azure ロールベースのアクセス制御 (Azure RBAC) が管理プラットフォームにネイティブ統合されるため、すべてのサービスにアクセス制御を適用できます。
タグをリソースに適用し、サブスクリプションのすべてのリソースを論理的に整理します。
同じタグを共有するリソース グループのコストを表示することで、組織の課金を明確にします。
スコープを理解する
Azure には、管理グループ、サブスクリプション、リソース グループ、およびリソースという 4 つのレベルの管理スコープが用意されています。 次の図に、これらのレイヤーを視覚化したものを示します。
これらのスコープ レベルのいずれかに管理設定を適用します。 選択するレベルで、設定の適用範囲が決まります。 上位レベルの設定が下位レベルに継承されます。 たとえば、サブスクリプションにポリシーを適用すると、そのポリシーはサブスクリプション内のすべてのリソース グループとリソースに適用されます。 リソース グループにポリシーを適用すると、そのポリシーはリソース グループとそのすべてのリソースに適用されます。 ただし、別のリソース グループにそのポリシー割り当てはありません。
Azure での ID とアクセスの管理の詳細については、「Microsoft Entra ID とは」を参照してください。
テンプレートは、テナント、管理グループ、サブスクリプション、またはリソース グループにデプロイすることができます。
リソース グループとは
リソース グループは、Azure ソリューションの関連性のあるリソースを管理するために使うコンテナーです。 リソース グループを使用すると、関連するリソース間の変更を調整するのに役立ちます。 たとえば、リソース グループに更新プログラムをデプロイし、調整された操作でリソースが更新されるという確信を持つことができます。 または、ソリューションの使用が完了したら、リソース グループを削除し、すべてのリソースが削除されていることを確認できます。
リソース グループを定義する際には、いくつかの重要な考慮事項があります。
リソース グループ内のすべてのリソースで、同じライフサイクルが共有される必要があります。 そのため、これらのリソースは一緒にデプロイ、更新、削除されます。 たとえば、1 台のサーバーは 1 つのリソースです。 別のデプロイ サイクルに存在する必要がある場合は、別のリソース グループに含める必要があります。
各リソースが所属できるリソース グループは 1 つに限られます。
リソースは、いつでもリソース グループに追加したり、削除できる。
あるリソース グループから別のリソース グループへリソースを移動できる。 詳細については、「Azure リソースを新しいリソース グループまたはサブスクリプションに移動する」を参照してください。
リソース グループ内のリソースは、リソース グループとは異なるリージョンに配置できますが、同じ場所を使用することをお勧めします。 「リソース グループの場所として使用するのに適した場所」を参照してください。
リソース グループを使用すると、管理操作のアクセス制御のスコープを設定できる。 Azure ポリシー、ロール、またはリソース ロックを使用して、リソース グループを管理できます。
リソース グループにタグを適用できます。 リソース グループ内のリソースは、これらのタグを継承しません。
リソースは、他のリソース グループ内のリソースに接続できます。 このシナリオは、2 つのリソースが関連を持っていても、同じライフサイクルを共有していない場合に一般的です。 たとえば、別のリソース グループ内のデータベースに接続している Web アプリがある場合があります。
リソース グループを削除すると、リソース グループ内のすべてのリソースも削除されます。 Resource Manager によってこれらの削除がどのように調整されるかについては、「Azure Resource Manager のリソース グループとリソースの削除」を参照してください。
各リソース グループには、リソースの種類のインスタンスを最大 800 個までデプロイできます。 一部のリソースの種類は、800 インスタンスの制限から除外されています。 詳細については、「リソース グループの制限」を参照してください。
リソース グループの外部に存在するリソースもある。 これらのリソースは、サブスクリプション、管理グループ、またはテナントにデプロイされます。 これらのスコープでは、特定のリソースの種類のみがサポートされます。
リソース グループを作成するには、Azure portal、PowerShell、Azure CLI、または ARM テンプレートを使います。
リソース グループの場所として使用するのに適した場所
リソース グループを作成するとき、その場所を指定する必要があります。
リソースはリソース グループの外部に場所を持つ可能性があるにもかかわらず、リソース グループに場所が必要であり、リソース グループの場所が重要であるのはなぜかと疑問に思われるかもしれません。
リソース グループには、リソースについてのメタデータが格納されます。 リソース グループの場所を指定するときは、このメタデータが格納される場所も指定することになります。 コンプライアンス上の理由から、データが特定のリージョンに格納されるようにすることが必要な場合があります。
すべてのコントロール プレーン操作をリソース グループの場所を介してルーティングすると、リソース グループを一貫した状態に保つのに役立ちます。 リソース グループの場所を選択するときは、コントロール操作の発生元に近い場所を選択することをお勧めします。 通常、これはユーザーに最も近い場所です。 このルーティング要件は、リソース グループのコントロール プレーン操作にのみ適用されます。 アプリケーションに送信される要求には影響しません。
リソース グループのリージョンが一時的に利用できない場合、メタデータが使用できないために、リソース グループ内のリソースを更新できない可能性があります。 他のリージョン内のリソースは引き続き通常どおり機能しますが、それらを更新できない可能性があります。 この状況は、Azure DNS、Azure Private DNS ゾーン、Azure Traffic Manager、Azure Front Door などのグローバル リソースにも当てはまる場合があります。 Resource Manager が管理するリソースとメタデータを表示するには、「Azure Resource Graph のテーブルとリソースの種類のリファレンス」のリストを参照してください。
リソース グループのリージョンが利用できない場合、Resource Manager はリソースのメタデータを更新できず、書き込みの呼び出しをブロックします。 リージョンの停止の影響を軽減するには、リソースとリソース グループは、同じリージョン内に配置することをお勧めします。 そうすることで、リソースとメタデータは複数のリージョンでなく 1 つのリージョン内に存在するため、リージョンが利用できない可能性が低くなります。
信頼性の高いアプリケーションの構築方法の詳細については、「特定の Azure サービスの回復性のチェックリスト」を参照してください。
Resource Manager の回復性
Resource Manager は、回復性と継続的な可用性を実現するよう設計されています。 Resource Manager とコントロール プレーン操作 (management.azure.com に送信される要求) は、REST API 内で次のように動作します。
リージョン間で分散されます。 Resource Manager は、Azure の各リージョンに個別のインスタンスを持っています。つまり、あるリージョンで Resource Manager インスタンスに障害が発生した場合、この障害は、別のリージョンのサービスの可用性に影響せず、他の Azure サービスの可用性にも影響しません。 Resource Manager は複数のリージョンに分散されますが、一部のサービスはリージョン限定です。 この違いは、コントロール プレーン操作の最初の処理には回復性があるのに対し、サービスに転送された要求はリージョンの停止の影響を受ける可能性があることを意味します。
複数の可用性ゾーンを含む場所内の可用性ゾーン (およびリージョン) 間で分散されます。 この分散により、リージョンで 1 つ以上のゾーンが失われても、Resource Manager は別のゾーンまたはリージョンにフェールオーバーできます。 それは引き続きリソースにコントロール プレーン機能を提供します。
1 つの論理データセンターに依存しません。
メンテナンス アクティビティのために休止することはありません。
この回復性は、Resource Manager 経由で要求を受信するサービスに適用されます。 Azure Key Vault は、この一貫性からメリットを得るサービスの 1 つです。
同時実行操作を解決する
リソースを同時に更新すると、予期しない結果になる可能性があります。 複数の操作で同じリソースを同時に更新しようとすると、Azure Resource Manager は競合を検出し、1 つの操作にのみ、正常に完了することを許可し、他の操作をブロックしてエラーを返します。 この解決方法により、更新が決定的で確実であることが保証されます。そのため、リソースの状態を把握し、データの不整合や損失を回避できます。
たとえば、A と B の 2 つの要求があり、同じリソースの更新を同時に試みるとします。要求 A が要求 B の前に完了すると、要求 A は成功し、要求 B は失敗します。 要求 B は 409 エラーを返します。 このエラー コードを受け取った後に、リソースの更新された状態を取得し、要求 B を再送信するかどうかを決定できます。
次のステップ
- Azure のサービス全体に該当する制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。
- リソースの移動の詳細については、「新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。
- リソースにタグを付ける方法については、「タグを使用して Azure リソースと整理階層を整理する」を参照してください。
- リソースのロックについては、「Azure リソースをロックしてインフラストラクチャを保護する」を参照してください。