AWS Organizations の用語と概念

このトピックでは、AWS Organizations の使用開始に役立ついくつかの重要な概念について説明します。

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

組織

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

ルート

組織のすべてのアカウントが設定された親コンテナ ポリシーをルートに適用する場合は、組織内のすべての組織単位 (OU) とアカウントに適用されます。

注記

現在、ルートは 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 を使用する場合は、ハンドシェイクを直接操作する必要があります。

ハンドシェイク

二者間で情報を交換する複数ステップのプロセスです。AWS Organizations の主な用途の 1 つは、invitations の基盤実装として提供することです。ハンドシェイクメッセージは、ハンドシェイクの開始者と受信者の間で受け渡しと応答が行われます。メッセージは、両方の当事者が現在のステータスを確実に把握できる方法で受け渡しされます。また、ハンドシェイクは、一括請求機能のみのサポートから、 で提供されるすべての機能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 Organizations によって、FullAWSAccess と呼ばれる AWS 管理ポリシーがすべてのルート、OU、アカウントにアタッチされます。そのため、組織を構成する際は、設定しない限り一切ブロックされません。つまり、デフォルトではすべてのアクセス権限が許可されます。アクセス許可を制限する準備ができたら、FullAWSAccess ポリシーを、より限定的かつ適切な一連のアクセス許可だけを使用できるポリシーに変更します。影響を受けるアカウントのユーザーとロールは、IAM ポリシーではすべてのアクションが許可されている場合でも、指定されたレベルのアクセスだけが可能になります。ルートのデフォルトポリシーを変更する場合、組織内のアカウントはすべて、制限が適用されます。SCP は、アクセス許可を付与することができず、フィルタ処理のみを行うため、階層の下位レベルで追加し直すことはできません。

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

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

このタイプのポリシーは、AWS の AI サービスのオプトアウト設定を、組織内のアカウント全体で標準化するのに役立ちます。AWS の特定の AI サービスは、処理したお客様のコンテンツを Amazon の AI サービスおよびテクノロジーの開発と継続的改善のために保存、使用することがあります。AWS のお客様は、AI サービスのオプトアウトポリシーを使用し、サービスの改善のためにコンテンツが保存または使用されることをオプトアウトできます。

バックアップポリシー

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

タグポリシー

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