デプロイ スコープについて
仮想マシン、Azure SQL 論理サーバーとデータベース、ストレージ アカウント、仮想ネットワーク、およびその他のほとんどの Azure リソースをリソース グループに配置する必要があります。 ただし、一部のリソースは別の方法でデプロイできます(またはデプロイする必要があります)。 これらのリソースは、通常、Azure 環境の動作を制御するために使用されます。
このユニットでは、Azure リソース組織の階層を確認し、さまざまなスコープで特定のリソースがどのようにデプロイされるかを確認します。
Azure リソース階層
Azure には、複数のレベルの管理を備えた階層型リソース構造があります。 おもちゃの会社が Azure 環境を整理する方法を示す図を次に示します。
あなたのテナントは Microsoft Entra インスタンスに対応しています。 通常、組織には Microsoft Entra インスタンスが 1 つだけ含まれます。 このインスタンスは、リソース階層のルートとして機能します。
管理グループ は、Azure サブスクリプションを整理する方法を提供します。 各テナントには 1 つのルート管理グループがあり、その下に独自の管理グループの階層を確立できます。 組織のさまざまな部分、または独自のセキュリティまたはガバナンス要件を持つサブスクリプションに対して、個別の管理グループを作成できます。 ポリシーとアクセス制御の制限を管理グループに適用できます。階層内のその管理グループの下にあるすべてのサブスクリプションは、これらの制限を継承します。 管理グループはリージョンにデプロイされず、リソースの場所には影響しません。
サブスクリプションは 課金アカウントとして機能し、リソース グループとリソースが含まれます。 管理グループと同様に、サブスクリプションには場所がなく、リソースがデプロイされる場所は制限されません。
リソース グループ は、リソースの論理コンテナーです。 リソース グループを使用すると、関連するリソースを 1 つの単位として管理および制御できます。 仮想マシン、Azure App Service プラン、ストレージ アカウント、仮想ネットワークなどのリソースは、リソース グループに配置する必要があります。 リソース グループは、Azure がグループ内のリソースのメタデータを追跡できるように場所に作成されますが、グループ内のリソースは他の場所にデプロイできます。
前に示した例は、管理グループを使用する方法を示す非常に基本的なシナリオです。 組織では、運用 Azure 環境を開始するために必要な一連の Azure リソースと構成である ランディング ゾーンの実装も検討する場合があります。 エンタープライズ規模のランディング ゾーンは、管理グループとサブスクリプションを使用して Azure リソースを効果的に管理するための実証済みのアプローチです。
どのモデルに従っても、階層のさまざまなレベルを理解することで、Azure 環境の使用方法と管理方法に関する柔軟な制御の適用を開始できます。 Bicep を使用すると、コードとしてのインフラストラクチャのすべての利点を使用して、これらのコントロールを管理できます。
注
また、特定のスコープでデプロイされるその他のリソースもあります。 拡張機能リソース は、別の Azure リソースのスコープでデプロイされます。 たとえば、リソース ロックは拡張機能リソースであり、ストレージ アカウントなどのリソースにデプロイされます。
リソース をリソース グループにデプロイすることに既に慣れているので、デプロイの他のスコープを見てみましょう。
サブスクリプションの範囲にあるリソース
次の場合に、リソースをサブスクリプションにデプロイできます。
- 新しいリソース グループを作成する必要があります。 リソース グループは、実際にはサブスクリプション スコープのリソースにすぎません。
- サブスクリプション内のすべてのリソースへのアクセス権を付与する必要があります。 たとえば、人事部に、部門のすべての Azure リソースを含む Azure サブスクリプションがある場合は、人事部の全員がサブスクリプションの内容を読み取ることができるようにロールの割り当てを作成できます。
- Azure Policy を使用していて、サブスクリプション内のすべてのリソースにポリシーを定義または適用する必要があります。 たとえば、おもちゃの会社の R&D 部門から、チームのサブスクリプション内に作成できる仮想マシン SKU の一覧を制限するポリシーをデプロイするように求められました。
管理グループスコープのリソース
次の場合に、管理グループにリソースをデプロイできます。
管理グループ階層に含まれるサブスクリプション内のすべてのリソースへのアクセス権を付与する必要があります。 たとえば、クラウド運用チームが組織内のすべてのサブスクリプションにアクセスする必要がある場合があります。 ルート管理グループでロールの割り当てを作成し、クラウド運用チームに Azure 内のすべてのアクセス権を付与できます。
注意事項
管理グループ、特にルート管理グループを使用してリソースへのアクセスを許可する場合は、非常に注意してください。 階層内の管理グループの下のすべてのリソースがロールの割り当てを継承することを忘れないでください。 組織が ID 管理と認証のベスト プラクティスに従っていることを確認し、最小限の特権の原則に従っていることを確認します。つまり、必要のないアクセス権を付与しないでください。
組織全体にポリシーを適用する必要があります。 たとえば、どのような状況でも、特定の地理的リージョンでリソースを作成できないというポリシーが組織にある場合があります。 ルート管理グループにポリシーを適用して、そのリージョンでのリソースの作成をブロックすることができます。
注
管理グループを初めて使用する前に、 Azure 環境用に設定します。
テナントスコープのリソース
次の場合に、テナントにリソースをデプロイできます。
Azure サブスクリプションを作成する必要があります。 管理グループを使用すると、サブスクリプションはリソース階層内の管理グループの下に配置されますが、サブスクリプションはテナント スコープのリソースとしてデプロイされます。
注
すべての Azure のお客様が、コードとしてインフラストラクチャを使用してサブスクリプションを作成できるわけではありません。 Microsoft との課金関係によっては、これが不可能な場合があります。 詳細については、「 プログラムによる Azure サブスクリプションの作成」を参照してください。
管理グループを作成または構成しています。 テナントの管理グループを有効にすると、Azure によって 1 つのルート管理グループが作成され、その下に複数のレベルの管理グループを作成できます。 Bicep を使用して、管理グループ階層全体を定義できます。 管理グループにサブスクリプションを割り当てることもできます。
Bicep を使用すると、テナント スコープにデプロイを送信できます。 テナントスコープのデプロイには特別なアクセス許可が必要です。 ただし、実際には、テナントスコープのデプロイを送信する必要はありません。 代わりに、別のスコープのテンプレートを使用して、テナント スコープのリソースをデプロイする方が簡単です。 これを行う方法については、このモジュールの後半で説明します。
ヒント
テナント スコープでポリシーまたはロールの割り当てを作成することはできません。 ただし、組織全体でアクセス権を付与したりポリシーを適用したりする必要がある場合は、これらのリソースをルート管理グループにデプロイできます。
リソース ID
現時点では、サブスクリプション内に存在するリソースのリソース ID について理解しています。 たとえば、サブスクリプション スコープのリソースであるリソース グループを表すリソース ID を次に示します。
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment
同じ情報の視覚的な表現を次に示します。
サブスクリプション自体には、次のような独自の ID があります。
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
注
サブスクリプションは管理グループの子と見なされますが、そのリソース ID には管理グループ ID は含まれません。 Azure では、他のリソースリレーションシップとは異なる方法で、サブスクリプションと管理グループの間の関係を追跡します。 これにより、すべてのリソース ID を変更しなくても、管理グループ間でサブスクリプションを柔軟に移動できます。
管理グループまたはテナント スコープでリソースを操作している場合、リソース ID は通常とは少し異なる場合があります。 ほとんどの場合、リソースの種類と特定のリソースに関する情報をインターリーブする標準的なパターンに従います。 ただし、特定の形式は、作業中のリソースによって異なります。
管理グループのリソース ID の例を次に示します。
/providers/Microsoft.Management/managementGroups/ProductionMG
次のような外観になります。
注
管理グループには、識別子と表示名の両方があります。 表示名は、管理グループの人間が判読できる説明です。 管理グループの ID に影響を与えずに表示名を変更できます。
リソースが管理グループ スコープにデプロイされると、そのリソース ID に管理グループ ID が含まれます。 管理グループ スコープで作成されたロール定義のリソース ID の例を次に示します。
/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
同じ ID の視覚的な表現を次に示します。
サブスクリプション スコープで別のロール定義が定義されている可能性があるため、そのリソース ID は少し異なります。
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
同じ ID の視覚的な表現を次に示します。
Azure リソース階層と、各スコープでデプロイできるリソースの種類を理解したら、リソースをデプロイするスコープに関する決定を行うことができます。 たとえば、リソース グループ、サブスクリプション、または管理グループのスコープでポリシー定義を作成する必要があるかどうかについて、情報に基づいて選択できます。 次のユニットでは、これらの各スコープを対象とする Bicep ファイルを作成する方法について説明します。