Azure の管理インフラストラクチャについて説明する

完了

管理インフラストラクチャには、Azure リソースとリソース グループ、サブスクリプション、アカウントが含まれます。 階層構造の組織を理解すると、Azure 内でプロジェクトと製品を計画するのに役立ちます。

リソースとリソース グループ

リソースは、Azure の基本的な構成要素です。 作成、プロビジョニング、デプロイなど、あらゆるものがリソースです。 Virtual Machines (VM)、仮想ネットワーク、データベース、Cognitive Services などは、すべて Azure 内のリソースと見なされます。

関数、VM、データベース、アプリが含まれたリソース グループ ボックスを示す図。

リソース グループは、単にリソースのグループ化のことです。 リソースを作成するときは、リソース グループに配置する必要があります。 リソース グループには多数のリソースを含めることができますが、1 つのリソースは一度に 1 つのリソース グループにのみ含めることができます。 一部のリソースはリソース グループ間で移動できますが、リソースを新しいグループに移動すると、そのリソースは以前のグループに関連付けされなくなります。 また、リソース グループを入れ子にすることはできません。つまり、リソース グループ B をリソース グループ A の内部に配置することはできません。

リソース グループは、リソースをグループ化する便利な方法を提供します。 リソース グループにアクションを適用すると、そのアクションはリソース グループ内のすべてのリソースに適用されます。 リソース グループを削除すると、その内部にあるすべてのリソースが削除されます。 リソース グループへのアクセスを許可または拒否すると、リソース グループ内のすべてのリソースへのアクセスが許可または拒否されます。

リソースをプロビジョニングするときは、ニーズに最も適したリソース グループ構造について考えておくことをお勧めします。

たとえば、一時的な開発環境を設定する場合、すべてのリソースをグループ化すると、リソース グループを削除することで、関連付けられているすべてのリソースを一度にプロビジョニング解除できます。 3 つの異なるアクセス スキーマを必要とするコンピューティング リソースをプロビジョニングする場合は、アクセス スキーマに基づいてリソースをグループ化し、リソース グループ レベルでアクセスを割り当てることが最善の場合があります。

リソース グループの使用方法に難しい規則はありません。そのため、リソース グループを設定して、その有用性を最大限に高める方法を検討してください。

Azure サブスクリプション

Azure 内では、サブスクリプションは管理、課金、スケールの単位です。 リソース グループがリソースを論理的に整理する方法と同様に、サブスクリプションを使用すると、リソース グループを論理的に整理し、課金を容易にできます。

認証と承認を使用して Azure アカウントにアクセスする Azure サブスクリプションを示す図。

Azure の使用には、Azure のサブスクリプションが必要です。 サブスクリプションにより、Azure の製品とサービスへのアクセスが認証および承認されます。 また、これにより、リソースをプロビジョニングすることもできます。 Azure サブスクリプションは Azure アカウントにリンクされています。これは、Microsoft Entra ID 内または Microsoft Entra ID によって信頼されるディレクトリ内の ID です。

アカウントには複数のサブスクリプションを含めることができますが、必要なのは 1 つだけです。 マルチサブスクリプション アカウントでは、サブスクリプションを使用してさまざまな課金モデルを構成し、異なるアクセス管理ポリシーを適用できます。 Azure サブスクリプションを使用して、Azure 製品、サービス、リソースに関する境界を定義できます。 使用できるサブスクリプションの境界には、次の 2 種類があります。

  • 課金の境界: このサブスクリプションの種類では、Azure の使用料金を Azure アカウントに課金する方法を決定します。 さまざまな種類の課金要件に応じて複数のサブスクリプションを作成できます。 Azure により、サブスクリプションごとに個別の課金レポートと請求書が生成されるため、コストを整理して管理することができます。
  • アクセス制御の境界: Azure では、アクセス管理ポリシーをサブスクリプション レベルで適用するので、さまざまな組織構造を反映する個別のサブスクリプションを作成できます。 たとえば、ある企業には、さまざまな部門があり、それらに個別の Azure サブスクリプション ポリシーを適用するとします。 この課金モデルを使用すると、ユーザーが特定のサブスクリプションを使用してプロビジョニングするリソースへのアクセスを管理および制御できます。

追加の Azure サブスクリプションを作成する

リソース グループを使用して関数またはアクセスによってリソースを分離するのと同様に、リソースまたは課金管理の目的で追加のサブスクリプションを作成することもできます。 たとえば、以下のものを分離するために、追加のサブスクリプションを作成することを選択できます。

  • 環境: サブスクリプションを作成して、開発とテスト、セキュリティ、またはコンプライアンス上の理由でデータを分離するために個別の環境を設定することを選択できます。 リソース アクセス制御はサブスクリプション レベルで発生するため、この設計は特に有用です。
  • 組織構造:さまざまな組織構造を反映させるために、サブスクリプションを作成できます。 たとえば、あるチームは低コストのリソースに制限し、IT 部門にはすべてを許可することができます。 この設計では、ユーザーが各サブスクリプション内でプロビジョニングするリソースへのアクセスを管理および制御することができます。
  • 課金: 課金目的で追加のサブスクリプションを作成することもできます。 コストは最初にサブスクリプション レベルで集約されるため、サブスクリプションを作成して、必要に応じてコストを管理および追跡することができます。 たとえば、運用ワークロード用として 1 つのサブスクリプションを作成し、開発およびテスト ワークロード用として別のサブスクリプションを作成することができます。

Azure 管理グループ

最後の部分は管理グループです。 リソースはリソース グループにまとめられ、リソース グループはサブスクリプションにまとめられます。 Azure で始めたばかりの場合は、整理するのに十分な階層のように見えるでしょう。 ただし、複数のアプリケーション、複数の開発チームを複数の地域で扱っている場合を想像してみてください。

多数のサブスクリプションがある場合は、それらのサブスクリプションのアクセス、ポリシー、コンプライアンスを効率的に管理する方法が必要になることがあります。 Azure 管理グループでは、サブスクリプションより上のレベルのスコープが提供されます。 管理グループと呼ばれるコンテナーにサブスクリプションを整理して、管理グループに管理条件を適用できます。 管理グループ内のすべてのサブスクリプションは、リソース グループがサブスクリプションから設定を継承し、リソースがリソース グループから継承するのと同じ方法で、管理グループに適用された条件を自動的に継承します。 管理グループを使うと、サブスクリプションの種類に関係なく、大きな規模でエンタープライズ レベルの管理を行うことができます。 管理グループを入れ子にすることができます。

管理グループ、サブスクリプション、リソース グループ階層

管理グループとサブスクリプションの柔軟な構造を作成し、リソースを階層に整理して、統一されたポリシーとアクセス管理を適用できます。 次の図は、管理グループを使用して管理のための階層を作成する例を示しています。

管理グループの階層ツリーの例を示す図。

管理グループを使用する方法の例を次に示します。

  • ポリシーを適用する階層を作成する。 たとえば、Production という名前のグループ内の VM の場所を米国西部リージョンに制限できます。 このポリシーは、その管理グループの子孫であるすべてのサブスクリプションに継承され、それらのサブスクリプションの下にあるすべての VM に適用されます。 このセキュリティ ポリシーをソースまたはサブスクリプションの所有者が変更することはできません。これにより、ガバナンスが向上します。
  • 複数のサブスクリプションへのユーザー アクセスを提供する。 その管理グループの下に複数のサブスクリプションを移動することで、管理グループに対する Azure ロールベースのアクセス制御 (Azure RBAC) 割り当てを 1 つ作成できます。 管理グループ レベルで Azure RBAC を割り当てることは、その管理グループの下にあるすべてのサブ管理グループ、サブスクリプション、リソース グループ、およびリソースも、それらのアクセス許可を継承することを意味します。 さまざまなサブスクリプションに Azure RBAC を割り当てるスクリプトを作成しなくても、管理グループへ 1 つ割り当てることで、ユーザーは必要なものすべてにアクセスできます。

管理グループに関する重要な事実:

  • 1 つのディレクトリでは、10,000 個の管理グループをサポートできます。
  • 管理グループのツリーは、最大 6 レベルの深さをサポートできます。 この制限には、ルート レベルまたはサブスクリプション レベルは含まれません。
  • 各管理グループとサブスクリプションでは、1 つの親のみをサポートできます。