デプロイのスコープの概要

  • 6 分

仮想マシン、Azure SQL の論理サーバーとデータベース、ストレージ アカウント、仮想ネットワーク、その他のほとんどの Azure リソースは、リソース グループに配置する必要があります。 ただし、別の方法でデプロイすることができる、またはする必要があるリソースもあります。 通常、このようなリソースは Azure 環境の動作を制御するために使用されます。

このユニットでは、Azure リソース編成の階層を確認し、特定のリソースをさまざまなスコープにどのようにデプロイするかを見ていきます。

Azure リソースの階層

Azure には、複数の管理レベルを持つ階層的なリソース構造があります。 これは、あなたのおもちゃ会社で Azure 環境をどのように編成できるかを示す図です。

Diagram showing an Azure tenant, three management groups, three subscriptions, and four resource groups.

"テナント" は Microsoft Entra インスタンスに対応します。 通常、組織が所有している Microsoft Entra インスタンスは 1 つだけです。 このインスタンスは、リソース階層のルートとして機能します。

"管理グループ" を使用すると、Azure サブスクリプションを整理することができます。 各テナントには 1 つのルート管理グループがあり、その下に独自の管理グループの階層を構築することができます。 組織のさまざまな部分や、独自のセキュリティまたはガバナンスの要件を持つサブスクリプションに対して、個別の管理グループを作成することができます。 管理グループには、ポリシーとアクセス制御の制限を適用することができます。また、これらの制限は、階層内のその管理グループ以下にあるすべてのサブスクリプションに継承されます。 管理グループはリージョンにはデプロイされません。また、リソースの場所にも影響を与えません。

"サブスクリプション" は請求アカウントとして機能します。また、リソース グループとリソースが含まれています。 管理グループと同様に、サブスクリプションには場所がなく、リソースのデプロイ先は制限されません。

"リソース グループ" は、リソースの論理コンテナーです。 リソース グループを使用すると、関連するリソースを 1 つのユニットとして管理および制御することができます。 仮想マシン、Azure App Service プラン、ストレージ アカウント、仮想ネットワークなどのリソースは、リソース グループに含める必要があります。 リソース グループは 1 つの場所に作成されるので、Azure からグループ内のリソースのメタデータを追跡できますが、グループ内のリソースは他の場所にデプロイできます。

前に示した例は、管理グループの使用方法を示す、ごく基本的なシナリオです。 組織では、運用 Azure 環境を始めるために必要な Azure リソースと構成のセットである "ランディング ゾーン" の実装を検討する場合もあります。 "エンタープライズ規模のランディング ゾーン" は、管理グループとサブスクリプションを使用して、Azure リソースを効果的に管理するための実証済みのアプローチです。

Diagram of an enterprise-scale landing-zone architecture, with four management groups and four subscriptions.

どのモデルを採用する場合でも、階層のさまざまなレベルを理解すると、Azure 環境の使用方法や管理方法に柔軟な制御を適用できるようになります。 Bicep を使用すると、コードとしてのインフラストラクチャのすべての利点を活かしながら、このような制御を管理することができます。

Note

また、特定のスコープにデプロイされるリソースもあります。 "拡張リソース" は、他の Azure リソースのスコープにデプロイされます。 たとえば、リソース ロックは拡張リソースであり、ストレージ アカウントなどのリソースにデプロイされます。

リソースをリソース グループにデプロイする方法は既に理解されていると思いますので、他のスコープのデプロイについて見てみましょう。

サブスクリプションスコープのリソース

次のような場合に、サブスクリプションにリソースをデプロイすることがあります。

  • 新しいリソース グループを作成する必要があります。 リソース グループは、実際にはサブスクリプションスコープのリソースに過ぎません。
  • サブスクリプション内のすべてのリソースにアクセス権を付与する必要があります。 たとえば、人事部門が部門のすべての Azure リソースを含む Azure サブスクリプションを持っている場合、人事部門の全員がサブスクリプションのコンテンツを読み取ることができるようにロールの割り当てを作成することができます。
  • あなたは Azure Policy を使用しており、サブスクリプション内のすべてのリソースにポリシーを定義または適用したいと考えています。 たとえば、おもちゃ会社の研究開発部門から、チームのサブスクリプション内で作成できる仮想マシン SKU の一覧を制限するポリシーをデプロイするように依頼されたとします。

管理グループスコープのリソース

次のような場合に、リソースを管理グループにデプロイすることがあります。

  • 管理グループ階層に該当するサブスクリプション内のすべてのリソースに、アクセス権を付与する必要があります。 たとえば、クラウド運用チームの場合、組織内のすべてのサブスクリプションに対するアクセス権が必要な場合があります。 ルート管理グループでロールの割り当てを作成することができます。これにより、Azure のすべてに対するアクセス権がクラウド運用チームに付与されます。

    注意事項

    管理グループ、特にルート管理グループを使用してリソースに対するアクセス権を付与する場合は、細心の注意を払ってください。 階層内の管理グループ以下にあるすべてのリソースに、ロールの割り当てが継承されることに注意してください。 組織が ID 管理と認証のベスト プラクティスに従っていること、最小限の特権の原則に従っていることを確認します。つまり、必要のないアクセスは付与しないでください。

  • 組織全体にポリシーを適用する必要があります。 たとえば、特定のリージョンでは、どのような状況でもリソースを作成できないというポリシーを設定することができます。 そのリージョン内のリソース作成をブロックするというポリシーをルート管理グループに適用することができます。

Note

管理グループを初めて使用する前に、実際の Azure 環境に合わせて設定してください。

テナントスコープのリソース

次のような場合に、テナントにリソースをデプロイすることがあります。

  • Azure サブスクリプションを作成する必要があります。 管理グループを使用している場合、サブスクリプションはリソース階層内で管理グループ以下に配置されますが、サブスクリプションはテナントスコープのリソースとしてデプロイされます。

    Note

    すべての Azure のお客様がコードとしてのインフラストラクチャを使用してサブスクリプションを作成できるわけではありません。 Microsoft との課金リレーションシップによっては、これができない場合があります。 詳細については、「Azure サブスクリプションをプログラムから作成する」を参照してください。

  • 管理グループを作成または構成しています。 テナントの管理グループを有効にすると、Azure によって 1 つのルート管理グループが作成されます。その下に複数レベルの管理グループを作成することができます。 Bicep を使用して、管理グループ階層全体を定義することができます。 また、管理グループにサブスクリプションを割り当てることもできます。

    Bicep を使用すると、テナント スコープにデプロイを送信することができます。 テナントスコープのデプロイに特別なアクセス許可が必要です。 ただし、実際には、テナント スコープのデプロイを送信する必要はありません。 その代わり、テナントスコープのリソースを、別のスコープのテンプレートを使用してデプロイする方が簡単です。 その方法については、モジュールの後半で説明します。

    ヒント

    テナント スコープでポリシーまたはロールの割り当てを作成することはできません。 ただし、組織全体にアクセス権を付与したり、ポリシーを適用したりする必要がある場合は、このようなリソースをルート管理グループにデプロイすることができます。

リソース ID

ここまでは、サブスクリプション内に存在するリソースのリソース ID について説明しました。 たとえば、サブスクリプションスコープのリソースであるリソース グループを表すリソース ID は次のとおりです。

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment

同じ情報を視覚的に表現すると次のようになります。

Screenshot of a Resource ID for a resource group.

サブスクリプション自体に、次のような独自の ID があります。

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e

Note

サブスクリプションは管理グループの子とみなされますが、そのリソース ID に管理グループ ID は含まれていません。 サブスクリプションと管理グループ間の関係は、他のリソースの関係とは異なる方法で Azure によって追跡されます。 そのため、すべてのリソース ID を変更することなく、管理グループ間でサブスクリプションを柔軟に移動することができます。

管理グループまたはテナントのスコープでリソースを操作する場合、リソース ID は通常とは少し異なる可能性があります。 ほとんどの場合は、リソースの種類と、特定のリソースに関する情報を織り交ぜた標準的なパターンに従っています。 ただし、具体的な形式は、使用しているリソースによって異なります。

管理グループのリソース ID の例を次に示します。

/providers/Microsoft.Management/managementGroups/ProductionMG

表示は次のようになります。

Screenshot of a Resource ID for a management group.

Note

管理グループには、識別子と表示名の両方があります。 表示名は、管理グループを人間が判読できる形式で説明したものです。 表示名は、管理グループの ID に影響を与えることなく変更できます。

リソースが管理グループ スコープにデプロイされると、そのリソース ID には管理グループ ID が含まれます。 管理グループ スコープで作成されたロール定義のリソース ID の例を次に示します。

/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

同じ ID の視覚的な表現を次に示します。

Screenshot of a Resource ID for a role definition that's deployed at a management group scope.

サブスクリプション スコープで別のロール定義が定義されている場合、そのリソース ID は少し異なります。

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

同じ ID の視覚的な表現を次に示します。

Screenshot of a Resource ID for a role definition that's deployed at a subscription scope.

Azure リソース階層と、各スコープにデプロイできるリソースの種類について理解したら、リソースのデプロイ先のスコープを判断できます。 たとえば、リソース グループ、サブスクリプション、または管理グループのどのスコープでポリシー定義を作成するかについて、情報に基づいて選択することができます。 次のユニットでは、これらの各スコープをターゲットとする Bicep ファイルの作成方法について説明します。