AWS Organizations の用語と概念 - AWS Organizations

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Organizations の用語と概念

このトピックでは AWS Organizations、 の使用を開始するために、いくつかの主要な概念について説明します。

次の図は、基本的な組織を示しています。この組織は、5 つのアカウントで構成されており、そのアカウントは、ルートを親として、4 つの組織単位 (OU) に分類されています。この組織には、複数のポリシーがあり、OU の一部、またはアカウントに直接アタッチされています。これらの各項目の詳細については、このトピックの定義を参照してください。

基本的な組織の図
組織

AWS アカウントを 1 つのユニットとして管理できるようにアカウントを統合するために作成するエンティティ。AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織には、1 つの管理アカウントと、ゼロ以上のメンバーアカウントを含みます。最上部が ルートの階層ツリーを模擬した構造のアカウントや、ルート下に作られた組織単位を整理できます。各アカウントは、ルートに直接含めるか、階層内の OU のいずれかに配置することができます。組織には、有効にする機能セットによって決定された機能を含みます。

ルート

組織のすべてのアカウントが設定された親コンテナ ルートに承認ポリシーを適用すると、組織内のすべての組織単位 (OUsメンバーアカウントに適用されます。管理ポリシーをルートに適用すると、組織内のすべての組織単位 (OUsと、組織内の管理アカウントを含むアカウントに適用されます。

注記

現在、組織の作成時に root を 1 つだけ AWS Organizations 自動的に作成できます。

組織単位 (OU)

ルート内のアカウントのコンテナです。また、OU は他の OU に含めることもでき、上下反転したツリーのような階層を作成できます。最上部にはルートがあり、下に向かって OU の枝が広がり、先端にはツリーの葉であるアカウントがあります。階層内のノードのいずれかにポリシーをアタッチすると、その配下にあるすべての枝 (OU) や葉 (アカウント) に適用されます。OU は、厳密に親を 1 つ持つことができ、現在、各アカウントを厳密に 1 つの OU のメンバーにすることができます。

アカウント

Organizations のアカウントは、 AWS リソースと AWS アカウント 、それらのリソースにアクセスできる ID を含む標準です。

ヒント

AWS アカウントはユーザーアカウントと同じではありません。AWS ユーザーは、 AWS Identity and Access Management (IAM) を使用して作成する ID で、長期の認証情報を持つ IAM ユーザーか、短期の認証情報を持つ IAM ロールのどちらかの形態をとります。1 つの AWS アカウントには多数のユーザーとロールを含めることができ、通常は含まれます。

組織は 2 種類のアカウントで構成されます。一つは管理アカウントとして指定された単一のアカウント、もう一つは 1 つ以上のメンバーアカウントです。

  • 管理アカウントは、組織を作成するために使用するアカウントです。組織の管理アカウントから、以下のことができます。

    • 組織にアカウントを作成する

    • 組織に他の既存のアカウントを招待する

    • 組織からアカウントを削除する

    • 委任管理者アカウントを指定する

    • 招待を管理する

    • 組織内のエンティティ (ルート、OU、またはアカウント) にポリシーを適用する

    • サポートされている AWS サービスとの統合を有効にして、組織内のすべてのアカウントでサービス機能を提供します。

    管理アカウントには、支払いアカウントだけでなく、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。

  • 組織内の残りのアカウントは、すべてメンバーアカウントです。アカウントが組織のメンバーになることができるのは、一度に 1 つのみです。1 つのアカウントにポリシーをアタッチして、そのアカウントのみ制御することができます。

    注記

    一部のメンバーアカウントを委任管理者アカウントとして指定できます。下記の「委任管理者」を参照してください。

委任管理者

Organizations の管理アカウントとそのユーザーおよびロールは、そのアカウントで実行する必要のあるタスクのみに使用することをおすすめします。 AWS  リソースを組織内の他のメンバーアカウントに保存し、管理アカウントからは切り離すことをおすすめします。これは、Organizations のサービスコントロールポリシー (SCP) などのセキュリティ機能は、管理アカウントのどのユーザーやどのロールにも制限を加えることができないためです。また、リソースを管理アカウントから分離することで、請求書に記載される請求額が理解しやすくなります。組織の管理アカウントから、1 つ以上のメンバーアカウントを委任管理者アカウントとして指定すると、この推奨事項を実施するうえで役立ちます。委任管理者には次の 2 種類があります。

  • Organizations の委任管理者:これらのアカウントからは、組織のポリシーを管理したり、組織内のエンティティ(ルート、OU、またはアカウント)にポリシーをアタッチしたりできます。管理アカウントは、委任権限をきめ細かく制御できます。詳細については、「の委任管理者 AWS Organizations」を参照してください。

  • AWS サービスの委任管理者: これらのアカウントから、Organizations と統合する AWS サービスを管理できます。管理アカウントは、必要に応じて異なるメンバーアカウントをさまざまなサービスの委任管理者として登録できます。これらのアカウントには、特定のサービスの管理者権限と、Organizations の読み取り専用アクションの権限があります。詳細については、「 Organizations と連携する AWS サービスの委任管理者」を参照してください。

招待

別のアカウント組織に招待するプロセスです。招待は、組織の管理アカウントによってのみ発行できます。招待は、招待されるアカウントに関連付けられたアカウント ID または E メールアドレスに送られます。招待済みのアカウントによって招待が承認されると、そのアカウントが、組織のメンバーアカウントになります。一括請求機能のみのサポートから、組織のすべての機能のサポートへの変更にすべてのメンバーが承認する必要が出てきた場合に、現在のすべてのメンバーアカウントに招待を送信することもできます。招待は、ハンドシェイクを交換するアカウントによって行われます。 AWS Organizations コンソールで作業している場合、ハンドシェイクが表示されないことがあります。ただし、 AWS CLI または AWS Organizations API を使用する場合は、ハンドシェイクを直接操作する必要があります。

ハンドシェイク

二者間で情報を交換する複数ステップのプロセスです。の主な用途の 1 AWS Organizations つは、招待の基盤となる実装として機能することです。ハンドシェイクメッセージは、ハンドシェイクの開始者と受信者の間で受け渡しと応答が行われます。メッセージは、両方の当事者が現在のステータスを確実に把握できる方法で受け渡しされます。また、ハンドシェイクは、一括請求機能のみのサポートから、 で提供されるすべての機能 AWS Organizations のサポートへ組織を変更する際にも使用されます。通常、ハンドシェイクと直接やり取りする必要があるのは、 AWS Organizations API または などのコマンドラインツールを使用する場合のみです AWS CLI。

利用可能な機能セット
  • すべての機能 — で使用できるデフォルトの機能セット AWS Organizations。一括請求のすべての機能だけでなく、高度な機能を使用して、組織のアカウントを詳細に制御できます。例えば、すべての機能が有効な場合、組織の管理アカウントは、メンバーアカウントで行えることを完全に制御できます。管理アカウントでは、サービスやアクションを制限する SCP を適用し、アカウントのユーザー (ルートユーザーを含む) とロールがアクセスできるサービスおよびアクションを制限できます。管理アカウントは、メンバーアカウントが組織を離れるのを防ぐこともできます。また、サポートされている AWS サービスとの統合を有効にして、それらのサービスが組織内のすべてのアカウントで機能を提供できるようにすることもできます。

    すべての機能を有効にして組織を作成するか、組織の設定を一括請求機能 (コンソリデーティッドビリング) のみのサポートからすべての機能のサポートに変更することができます。すべての機能を有効にするには、招待済みのすべてのメンバーアカウントを使用して、管理アカウントでプロセスを開始する際に送信される招待を承認し、変更を承認する必要があります。

  • 一括請求 – この機能セットは共有請求機能を提供しますが、 のより高度な機能は含まれていません AWS Organizations。例えば、他の AWS のサービスが組織と統合してすべてのアカウントで動作するようにしたり、ポリシーを使用して異なるアカウントのユーザーとロールが実行できる操作を制限したりすることはできません。高度な AWS Organizations 機能を使用するには、組織内のすべての機能を有効にする必要があります。

サービスコントロールポリシー (SCP)

ユーザーやロールが、SCP による影響を受けるアカウントで使用できるサービスやアクションを指定するポリシーです。アクセス許可が付与されない点を除き、SCP は IAM 許可ポリシーと類似しています。代わりに、SCP は組織、組織単位 (OU) あるいはアカウントに最大アクセス権限を指定します。SCP を組織の root あるいは OU にアタッチすると、SCP はメンバーアカウント内のエントリのアクセス権限を制限します。

許可リストと拒否リスト

許可リストと拒否リストは、SCP を適用してアカウントで利用できるアクセス許可をフィルタ処理するための補足的な戦略です。

  • 許可リスト戦略 – 許可されるアクセスを明示的に指定します。その他のアクセス権限はすべて暗黙的にブロックされます。デフォルトでは、 は、 と呼ばれる AWS 管理ポリシーFullAWSAccessをすべてのルート、OUs、および アカウントにア AWS Organizations タッチします。そのため、組織を構成する際は、設定しない限り一切ブロックされません。つまり、デフォルトではすべてのアクセス権限が許可されます。アクセス許可を制限する準備ができたら、FullAWSAccess ポリシーを、より限定的かつ適切な一連のアクセス許可だけを使用できるポリシーに変更します。影響を受けるアカウントのユーザーとロールは、IAM ポリシーではすべてのアクションが許可されている場合でも、指定されたレベルのアクセスだけが可能になります。ルートのデフォルトポリシーを変更する場合、組織内のアカウントはすべて、制限が適用されます。SCP は、アクセス許可を付与することができず、フィルタ処理のみを行うため、階層の下位レベルで追加し直すことはできません。

  • 拒否リスト戦略 – 許可されないアクセスを明示的に指定します。その他のアクセス権限はすべて有効になります。このシナリオでは、明示的にブロックされる場合を除き、すべてのアクセス権限が有効です。これは のデフォルトの動作です AWS Organizations。デフォルトでは、 AWS Organizations は という AWS マネージドポリシーFullAWSAccessをすべてのルート、OUs、および アカウントにアタッチします。これにより、すべての アカウントは、 AWS Organizations課された制限なしで任意のサービスまたはオペレーションにアクセスできます。上記の許可リスト手法とは異なり、拒否リストを使用する場合は、デフォルトの FullAWSAccess ポリシー (「すべて」を許可する) をそのまま使用します。ただしその後、不要なサービスやアクションへのアクセスを明示的に拒否する追加のポリシーをアタッチします。IAM 許可ポリシーの場合と同様、サービスアクションの明示的拒否により、そのアクションに対するすべての許可は上書きされます。

人工知能 (AI) サービスのオプトアウトポリシー

組織内のすべてのアカウントで AWS AI サービスのオプトアウト設定を標準化するのに役立つタイプのポリシー。特定の AWS AI サービスは、Amazon AI サービスとテクノロジーの開発と継続的な改善のために、それらのサービスによって処理された顧客コンテンツを保存して使用できます。 AWS カスタマーは、AI サービスのオプトアウトポリシーを使用して、コンテンツの保存またはサービスの改善に使用されたことをオプトアウトできます。

バックアップポリシー

このタイプのポリシーは、組織内のアカウント全体で、リソースのバックアップ戦略を標準化、実装するのに役立ちます。リソースのバックアッププランの設定とデプロイは、バックアップポリシーで行うことができます。

タグポリシー

このタイプのポリシーは、組織のアカウント全体のリソース間でタグを標準化するのに役立ちます。タグポリシーでは、特定のリソースのタグ付けルールを指定できます。