AWS アカウントと Azure アカウントを比較する
この記事では、Azure のアカウントと組織構造とアマゾン ウェブ サービス (AWS) のアカウントと組織構造を比較します。
他の AWS と Azure のサービスを比較する記事へのリンクと、AWS と Azure の間の完全なサービス マッピングについては、aws プロフェッショナル向けの azure を参照してください。
アカウント階層の管理
一般的な AWS 環境では、次の図のような組織構造が使用されます。 組織のルートと、必要に応じて専用の AWS 管理アカウントがあります。 ルートの下には、異なるアカウントに異なるポリシーを適用するために使用できる組織単位があります。 AWS リソースでは、多くの場合、論理的および課金の境界として AWS アカウントが使用されます。
Azure の構造は似ていますが、専用の管理アカウントではなく、テナントに対する管理アクセス許可を提供します。 この設計により、管理のためのアカウント全体が不要になります。 AWS とは異なり、Azure では基本的なユニットとしてリソース グループが使用されます。 リソースはリソース グループに割り当てる必要があり、アクセス許可はリソース グループ レベルで適用できます。
AWS 管理アカウントと Azure テナント
Azure では、Azure アカウントを作成すると、Microsoft Entra テナントが作成されます。 このテナント内のユーザー、グループ、アプリケーションを管理できます。 Azure サブスクリプションはテナントの下に作成されます。 Microsoft Entra テナントは、ID とアクセス管理を提供します。 これにより、認証されたユーザーと承認されたユーザーが、アクセス許可を持つリソースにのみアクセスできるようになります。
AWS アカウントと Azure サブスクリプション
Azure では、AWS アカウントと同等のものが Azure サブスクリプションです。 Azure サブスクリプションは、Microsoft Entra テナント内の Azure アカウントにリンクされている Azure サービスの論理ユニットです。 各サブスクリプションは課金アカウントにリンクされ、リソースが作成、管理、課金される境界が提供されます。 サブスクリプションは、コストの割り当てを理解し、予算の制限に従うために重要です。 これらは、使用されるすべてのサービスが追跡され、正しく課金されることを保証するのに役立ちます。 AWS アカウントなどの Azure サブスクリプションは、リソースクォータと制限の境界としても機能します。 一部のリソース クォータは調整可能ですが、調整できないリソースもあります。
AWS のクロスアカウント リソース アクセスを使用すると、ある AWS アカウントのリソースに別の AWS アカウントからアクセスしたり、別の AWS アカウントで管理したりできます。 AWS には、アカウント間でリソースにアクセスするための ID およびアクセス管理 (IAM) ロールとリソースベースのポリシーもあります。 Azure では、さまざまなスコープ (管理グループ、サブスクリプション、リソース グループ、または個々のリソース) で適用されるロールベースのアクセス制御 (RBAC) を使用して、異なるサブスクリプションのユーザーとサービスへのアクセスを許可できます。
AWS OU と Azure 管理グループ
Azure では、AWS 組織単位 (OU) と同等のものが管理グループです。 両方とも、複数のアカウントまたはサブスクリプションにわたってクラウド リソースを高レベルで整理および管理するために使用されます。 Azure 管理グループを使用して、Azure サブスクリプションのアクセス、ポリシー、コンプライアンスを効率的に管理できます。 管理グループ レベルで適用されるガバナンス条件は、継承によって関連付けられているすべてのサブスクリプションに連鎖します。
管理グループとサブスクリプションに関する重要な事実:
1 つのディレクトリでサポートされる管理グループは 10,000 個までです。
管理グループ ツリーでは、6 レベルの深さがサポートされます。
各管理グループとサブスクリプションに設定できる親は 1 つのみです。
各管理グループには複数の子を含めることができます。
すべてのサブスクリプションと管理グループは、各ディレクトリ内の 1 つの階層内にあります。
管理グループあたりのサブスクリプション数は無制限です。
ルート管理グループは、各ディレクトリに関連付けられている最上位の管理グループです。 すべての管理グループとサブスクリプションがルート管理グループにロールアップされます。 この設計により、グローバル ポリシーと Azure ロールの割り当てをディレクトリ レベルで実装できます。
サービス制御ポリシーと Azure Policy
AWS のサービス制御ポリシー (SCP) の主な目標は、AWS アカウント内の有効な最大アクセス許可を制限することです。 Azure では、最大アクセス許可は Microsoft Entra で定義され、テナント、サブスクリプション、またはリソース グループ レベルで適用できます。 Azure Policy にはさまざまなユース ケースがあり、その一部は一般的な SCP の使用パターンと一致します。 SCP と Azure ポリシーの両方を使用して、タグ付けや特定の SKU の使用など、エンタープライズ標準への準拠を強制できます。 SCP と Azure ポリシーの両方で、コンプライアンス要件を満たしていないリソースのデプロイをブロックできます。 Azure ポリシーは、SCP よりもプロアクティブになり、修復をトリガーしてリソースをコンプライアンスに取り込むことができます。 Azure ポリシーでは、既存のリソースと将来のデプロイの両方を評価することもできます。
AWS アカウントと Azure サブスクリプションの構造と所有権の比較
Azure アカウントは課金関係を表し、Azure サブスクリプションは Azure リソースへのアクセスを整理するのに役立ちます。 アカウント管理者、サービス管理者、および共同管理者は、Azure での従来からある 3 つのサブスクリプション管理者ロールです。
アカウント管理者。 サブスクリプション所有者であり、サブスクリプションで使用されたリソースの課金所有者です。 アカウント管理者は、サブスクリプションの所有権を譲渡することでのみ変更できます。 Azure アカウントごとに割り当てられるアカウント管理者は 1 人だけです。
サービス管理者。 このユーザーには、サブスクリプション内のリソースを作成および管理する権限がありますが、課金の責任はありません。 既定で、新しいサブスクリプションのアカウント管理者はサービス管理者でもあります。 アカウント管理者は、サブスクリプションの技術と運用面を管理するサービス管理者に別のユーザーを割り当てることができます。 サブスクリプションごとに割り当てられるサービス管理者は 1 人だけです。
共同管理者。 1 つのサブスクリプションに複数の共同管理者が割り当てられている場合があります。 共同管理者はサービス管理者と同じアクセス権限を持っていますが、サービス管理者を変更することはできません。
サブスクリプション レベルの下では、AWS の IAM ユーザーとグループにアクセス許可を付与する方法と同様に、ユーザー ロールと個々のアクセス許可を特定のリソースに割り当てることもできます。 Azure では、すべてのユーザー アカウントが Microsoft アカウントまたは組織アカウント (Microsoft Entra ID で管理されるアカウント) に関連付けられます。
AWS アカウントと同じように、サブスクリプションには既定のサービスのクォータと制限があります。 これらの制限の完全な一覧については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。 これらの制限は、管理ポータルでのサポート リクエストの申し込みによって、最大値まで増やすことができまです。
寄稿者
この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。
プリンシパル作成者:
- スリニヴァサロ トゥマラ |シニア カスタマー エンジニア
その他の共同作成者:
- アダム・セリーニ |パートナー テクノロジーストラテジスト ディレクター
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
- Azure ロール、Microsoft Entra ロール、従来のサブスクリプション管理者ロール
- Azure サブスクリプション管理者の追加または変更
- Azure 課金請求書 をダウンロードまたは表示する