Azure Resource Manager の概要Azure Resource Manager overview

Azure Resource Manager は、Azure のデプロイおよび管理サービスです。Azure Resource Manager is the deployment and management service for Azure. Azure サブスクリプション内のリソースを作成、更新、および削除できる管理レイヤーを提供します。It provides a management layer that enables you to create, update, and delete resources in your Azure subscription. アクセス制御、ロック、タグなどの管理機能を使用して、デプロイ後にリソースを保護および整理します。You use management features, like access control, locks, and tags, to secure and organize your resources after deployment.

Azure Resource Manager テンプレートについては、テンプレートのデプロイの概要に関するページを参照してください。To learn about Azure Resource Manager templates, see Template deployment overview.

一貫性のある管理レイヤーConsistent management layer

ユーザーが Azure ツール、API、SDK のいずれかから要求を送信すると、Resource Manager は要求を受信します。When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. その要求の認証と承認が行われます。It authenticates and authorizes the request. Resource Manager は、要求されたアクションを行う Azure サービスに要求を送信します。Resource Manager sends the request to the Azure service, which takes the requested action. すべての要求は同じ API を介して処理されるため、すべての異なるツールで一貫した結果と機能が得られます。Because all requests are handled through the same API, you see consistent results and capabilities in all the different tools.

次の図は、Azure 要求の処理において Azure Resource Manager が果たす役割を示しています。The following image shows the role Azure Resource Manager plays in handling Azure requests.

Resource Manager の要求モデル

ポータルで利用できるすべての機能は、PowerShell、Azure CLI、REST API、およびクライアント SDK からも利用できます。All capabilities that are available in the portal are also available through PowerShell, Azure CLI, REST APIs, and client SDKs. API を介して最初にリリースされた機能は、最初のリリースから 180 日以内にポータルに表示されます。Functionality initially released through APIs will be represented in the portal within 180 days of initial release.

用語集Terminology

Azure Resource Manager には、初めて使う方にとって、あまり馴染みのない用語がいくつか存在します。If you're new to Azure Resource Manager, there are some terms you might not be familiar with.

  • リソース - Azure を通じて管理できる要素。resource - A manageable item that is available through Azure. リソースの例として、仮想マシン、ストレージ アカウント、Web アプリ、データベース、および仮想ネットワークがあります。Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources.
  • リソース グループ - Azure ソリューションの関連するリソースを保持するコンテナー。resource group - A container that holds related resources for an Azure solution. リソース グループには、グループとして管理するリソースが含まれます。The resource group includes those resources that you want to manage as a group. 組織にとって最も有用になるように、どのリソースをリソース グループに含めるかを決定します。You decide which resources belong in a resource group based on what makes the most sense for your organization. リソース グループ」を参照してください。See Resource groups.
  • リソース プロバイダー - Azure リソースを提供するサービス。resource provider - A service that supplies Azure resources. 一般的なリソースプロバイダーの一例として、仮想マシン リソースを提供する Microsoft.Compute があります。For example, a common resource provider is Microsoft.Compute, which supplies the virtual machine resource. Microsoft.Storage は、もう 1 つの一般的なリソースプロバイダーです。Microsoft.Storage is another common resource provider. リソースプロバイダーと種類に関するページを参照してください。See Resource providers and types.
  • Resource Manager テンプレート - リソース グループまたはサブスクリプションにデプロイする 1 つまたは複数のリソースを定義する JavaScript Object Notation (JSON) ファイル。Resource Manager template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group or subscription. このテンプレートを使えば、リソースを一貫性のある形で繰り返しデプロイできます。The template can be used to deploy the resources consistently and repeatedly. テンプレートのデプロイの概要に関するページを参照してください。See Template deployment overview.
  • 宣言型構文 - 一連のプログラミング コマンドを記述しなくても、"作成しようとしているもの" を明確に宣言することのできる構文です。declarative syntax - Syntax that lets you state "Here is what I intend to create" without having to write the sequence of programming commands to create it. 宣言型構文の例として、Resource Manager テンプレートがあります。The Resource Manager template is an example of declarative syntax. このファイルで、Azure にデプロイするインフラストラクチャのプロパティを定義します。In the file, you define the properties for the infrastructure to deploy to Azure. テンプレートのデプロイの概要に関するページを参照してください。See Template deployment overview.

Resource Manager には、いくつかの利点がありますThe benefits of using Resource Manager

Resource Manager を使用すると、以下のことができます。With Resource Manager, you can:

  • スクリプトではなく宣言型のテンプレートを使用してインフラストラクチャを管理します。Manage your infrastructure through declarative templates rather than scripts.

  • ソリューションのリソースを個別に処理するのではなく、すべてのリソースをグループとしてデプロイ、管理、監視します。Deploy, manage, and monitor all the resources for your solution as a group, rather than handling these resources individually.

  • ソリューションを開発のライフサイクル全体で再デプロイします。リソースは、必ず一貫した状態でデプロイされます。Redeploy your solution throughout the development lifecycle and have confidence your resources are deployed in a consistent state.

  • 正しい順序でデプロイされるように、リソース間の依存関係を定義します。Define the dependencies between resources so they're deployed in the correct order.

  • ロールベースのアクセス制御 (RBAC) が管理プラットフォームにネイティブ統合されるため、リソース グループのすべてのサービスにアクセス制御を適用できます。Apply access control to all services in your resource group because Role-Based Access Control (RBAC) is natively integrated into the management platform.

  • タグをリソースに適用し、サブスクリプションのすべてのリソースを論理的に整理します。Apply tags to resources to logically organize all the resources in your subscription.

  • 同じタグを共有するリソース グループのコストを表示することで、組織の課金をわかりやすくします。Clarify your organization's billing by viewing costs for a group of resources sharing the same tag.

スコープを理解するUnderstand scope

Azure には、管理グループ、サブスクリプション、リソース グループ、およびリソースという 4 つのレベルのスコープが用意されています。Azure provides four levels of scope: management groups, subscriptions, resource groups, and resources. 次の図に、これらのレイヤーの例を示します。The following image shows an example of these layers.

Scope (スコープ)

これらのスコープ レベルのいずれかに管理設定を適用します。You apply management settings at any of these levels of scope. 選択するレベルで、設定の適用範囲が決まります。The level you select determines how widely the setting is applied. 上位レベルの設定が下位レベルに継承されます。Lower levels inherit settings from higher levels. たとえば、サブスクリプションにポリシーを適用すると、そのポリシーはサブスクリプション内のすべてのリソース グループとリソースに適用されます。For example, when you apply a policy to the subscription, the policy is applied to all resource groups and resources in your subscription. リソース グループにポリシーを適用すると、そのポリシーはリソース グループとそのすべてのリソースに適用されます。When you apply a policy on the resource group, that policy is applied the resource group and all its resources. ただし、別のリソース グループにそのポリシー割り当てはありません。However, another resource group doesn't have that policy assignment.

テンプレートを管理グループ、サブスクリプション、またはリソース グループにデプロイすることができます。You can deploy templates to management groups, subscriptions, or resource groups.

リソース グループResource groups

リソース グループを定義する際、次のような考慮すべき要素があります。There are some important factors to consider when defining your resource group:

  • グループ内のすべてのリソースで、同じライフサイクルが共有される必要がある。All the resources in your group should share the same lifecycle. そのため、これらのリソースは一緒にデプロイ、更新、削除されます。You deploy, update, and delete them together. データベース サーバーなどの 1 つのリソースが、別のデプロイ サイクル上に存在する必要がある場合は、別のリソース グループに含めなければなりません。If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.

  • 各リソースは、1 つのリソース グループにのみ存在できる。Each resource can only exist in one resource group.

  • リソースは、いつでもリソース グループに追加したり、削除できる。You can add or remove a resource to a resource group at any time.

  • あるリソース グループから別のリソース グループへリソースを移動できる。You can move a resource from one resource group to another group. 詳細については、「 新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。For more information, see Move resources to new resource group or subscription.

  • リソース グループには、別のリージョンに配置されたリソースを含めることができる。A resource group can contain resources that are located in different regions.

  • リソース グループを使用すると、管理操作のアクセス制御のスコープを設定できる。A resource group can be used to scope access control for administrative actions.

  • リソースは、他のリソース グループ内のリソースとやり取りできる。A resource can interact with resources in other resource groups. このやり取りは、2 つの関連するリソースで同じライフサイクルが共有されていない場合によく見られます (データベースに接続する Web アプリなど)。This interaction is common when the two resources are related but don't share the same lifecycle (for example, web apps connecting to a database).

リソース グループを作成するとき、そのリソース グループの場所を指定する必要があります。When creating a resource group, you need to provide a location for that resource group. "なぜリソース グループに場所が必要なのか。You may be wondering, "Why does a resource group need a location? リソースがリソース グループとは異なる場所に存在してよいとしたら、いったいなぜリソース グループの場所が問題になるのか" と、疑問に思われるかもしれません。And, if the resources can have different locations than the resource group, why does the resource group location matter at all?" リソース グループには、リソースについてのメタデータが格納されます。The resource group stores metadata about the resources. リソース グループの場所を指定するとき、このメタデータが格納される場所を指定することになります。When you specify a location for the resource group, you're specifying where that metadata is stored. コンプライアンス上の理由から、データは特定のリージョンに格納されるようにする必要があります。For compliance reasons, you may need to ensure that your data is stored in a particular region.

リソース グループのリージョンが一時的に使用できない場合は、メタデータが使用できないため、リソース グループ内のリソースを更新できません。If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. 他のリージョン内のリソースは通常どおり機能しますが、それらを更新することはできません。The resources in other regions will still function as expected, but you can't update them. 信頼性の高いアプリケーションの設計の詳細については、「信頼性の高い Azure アプリケーションの設計」を参照してください。For more information about building reliable applications, see Designing reliable Azure applications.

Azure Resource Manager の回復性Resiliency of Azure Resource Manager

Azure Resource Manager サービスは、回復性と継続的な可用性を実現するよう設計されています。The Azure Resource Manager service is designed for resiliency and continuous availability. REST API での Resource Manager とコントロール プレーン操作 (management.azure.com に送信される要求) は、次のように動作します。Resource Manager and control plane operations (requests sent to management.azure.com) in the REST API are:

  • リージョン間に分散されます。Distributed across regions. 一部のサービスはリージョン固有です。Some services are regional.

  • 複数の可用性ゾーンを含む場所では、可用性ゾーン (リージョン) 間で分散されます。Distributed across Availability Zones (as well regions) in locations that have multiple Availability Zones.

  • 単一の論理データ センターに依存しません。Not dependent on a single logical data center.

  • メンテナンスのために休止することはありません。Never taken down for maintenance activities.

この回復性は、Resource Manager 経由で要求を受信するサービスに適用されます。This resiliency applies to services that receive requests through Resource Manager. たとえば、Key Vault はこの回復性からメリットを得られます。For example, Key Vault benefits from this resiliency.

次の手順Next steps