この記事とは？

以下の記事の日本語訳になります。AWSが出している翻訳がわかりにくかったので、学習も兼ねて私なりに翻訳してみました。誤訳等ありましたらご指摘いただけると嬉しいです。

AWS Organizations terminology and concepts

以下翻訳です。

AWS Organizations の専門用語とその概念

このトピックではAWS Organizationsの学習に役立つ、重要な概念について解説します。

次の図は、基本的な組織を示しています。この組織は、7 つのメンバーアカウントで構成され、そのアカウントは、ルートアカウントを親として、4つの組織単位 (OU) に分類されています。

一部の組織単位(OU)やアカウントに複数のポリシーがアタッチされています。

これらの各項目の詳細については、以下に記述するこのトピックの定義を参照してください。

※注意
AWS Organizationsは、「マスターアカウント」の名前を「管理アカウント」に変更しています。これは名前の変更のみであり、機能に変更はありません。

組織 / Organization

AWSアカウントを一つの単位として管理できるように統合されたもの。

AWS Organizations consoleを使うと、組織(Organization)配下に存在する複数のアカウントを一元管理することができます。

組織(Organization)は一つのマネジメントアカウントを持ち、それらは0個以上のメンバーアカウントで構成されます。

ルートアカウントを頂点として複数のアカウントを階層構造で管理することができます。

各アカウントは、ルートアカウントに直接含めるか、組織単位(OU)内の のいずれかに配置することができます。

ルートアカウント / Root

全てのアカウントの親となるアカウント。もしルートにポリシーをアタッチすると、配下の組織単位(OU)やアカウントにそのポリシーが適応される。

※注意
現在、ひとつのルートアカウントしか作れません。ルートアカウントは組織を作成時に自動的に作成されます。

組織単位 (OU) / Organization Unit(OU)

ルートアカウント配下のアカウントを統合する単位。
組織単位 (OU) は他の組織単位 (OU) を含めることができます。

ルートアカウントを木の頂点として、組織単位 (OU)は下に向かって伸びる枝、メンバーアカウントが葉を表すような、上下反転したツリー構造で管理することができます。

ポリシーをアタッチすると、下の階層の組織単位 (OU)やアカウントに同じく適応されます。

組織単位 (OU)は必ずルートアカウントをもち、メンバーアカウントは組織単位 (OU)を必ずひとつもつ構造になります。

アカウント / Account

AWSリソースを含む標準のAWSアカウントのこと。1つのアカウントにポリシーをアタッチすると、そのアカウントのみに適応されることになります。

アカウントは2種類あります。マネジメントアカウントとメンバーアカウントです。

マネジメントアカウント / Management Account

マネジメントアカウントは組織を作成できるアカウントです。以下のことができます。

• 組織内にアカウントを作成する
• 組織に他のアカウントを招待する
• 組織からアカウントを削除する
• 招待を管理する
• 組織内に存在するルートアカウント、組織単位(OU)、アカウントに対してポリシーをアタッチする

マネジメントアカウントは支払いの責務を持つアカウントであり、またメンバーアカウントによって発生したすべての料金を支払う責任があります。

組織のマネジメントアカウントを変更することはできません。

メンバーアカウント / Member Accounts

残りのアカウントはメンバーアカウントと呼ばれます。
アカウントが組織のメンバーになることができるのは、一度に 1つのみです。

招待 / Invitation

別のアカウントを自分の組織に招待するプロセスのことです。

招待は、組織のマスターアカウントでのみ発行できます。

招待はアカウントIDまたは招待されるアカウントに登録されたEメールアドレスに送られます。

招待されたアカウントが招待を承認すると、そのアカウントが、組織内のメンバーアカウントになります。

招待は組織が全てのメンバーに対して、一括請求機能のみのサポートから、組織の持つすべての機能のサポートへの変更をする必要が出てきた時に、現在のすべてのメンバーアカウントに対して招待を送信することもできます。

AWS Organizations コンソールで作業している場合は、ハンドシェイクが表示されないことがあります。

ただし、AWS CLI 、またはAWS Organizations API を使用する場合は、ハンドシェイクを直接操作する必要があります。

ハンドシェイク / Handshake

情報を2者間で交換する複数ステップを持つプロセスのことです。

AWS Organizationsの主な用途の1つは、招待の基盤実装です。

ハンドシェイクメッセージは、ハンドシェイクの開始者と受信者の間で受け渡しと応答が行われます。

メッセージは、両者が確実に現在のステータスを把握できる方法で渡されます。

また、ハンドシェイクは、組織を一括請求機能のみのサポートから、AWS Organizationsで提供される組織の持つすべての機能のサポートへ変更する際にも使用されます。

通常ハンドシェイクは、AWS Organizations APIまたはAWS CLI などのコマンドラインツールを使用する場合にのみ、直接交換する必要があります。

利用可能な機能セット / Available feature sets

すべての機能

AWS Organizations で利用できるデフォルトの機能セットです。

一括請求の機能だけでなく、高度な機能を使用して、組織のアカウントを詳細に制御できます。

たとえば、すべての機能が有効になっている場合、マネジメントアカウントは、メンバーアカウントができることを全て制御できます。

マネジメントアカウントはIAMユーザーやIAMロールが利用可能なサービスやアクションをコントロールするためにサービスコントロールポリシー(SCP)を適応できます。

マネジメントアカウントは、メンバーアカウントが組織から削除されるのを防ぐこともできます。

組織を作成する際に、すべての機能を有効にするか、一括請求のみのサポートにするのか選ぶことができます。変更も可能です。

すべての機能を有効にするには、すべての招待されたメンバーアカウントが、マネジメントアカウントから送信される招待を承諾して、変更を承認する必要があります。

一括請求

この機能を利用すると、請求機能を共有できますが、AWS Organizationsの高度な機能は利用できません。

たとえば、ポリシーを使用して、異なるアカウントのIAMユーザーとIAMロールの実行範囲を制限することはできません。

高度なAWS Organizations機能を使用するには、組織のすべての機能を有効にする必要があります。

サービスコントロールポリシー / Service control policy (SCP)

SCPを適応されたアカウントにおいて、IAMユーザーやIAMロールが使用できるサービスやアクションを指定するポリシーです。

SCPは、アクセス許可を付与しない点を除き、IAMポリシーと似ています。
代わりに、組織、組織単位 (OU) またはアカウントの最大アクセス許可を指定します。

SCPを組織のルートアカウントあるいは組織単位(OU)にアタッチすると、SCPはメンバーアカウント内のアクセス権限を制限します。

許可リスト vs 拒否リスト / Allow lists vs. deny lists

許可リストと拒否リストは、アカウントがSCPを利用して、使用可能なアクセス許可をフィルタリングするために使える戦略です。

許可リスト

許可されるアクセスを明示的に指定します。その他のアクセス権限はすべて暗黙的にブロックされます。

デフォルトでは、AWS OrganizationsはFullAWSAccessと呼ばれるポリシーを、組織単位(OU)、そしてアカウントに付与しています。

これにより、新たな組織を作成した際には、設定しない限りアクセスは一切ブロックされません。つまり、デフォルトではすべてのアクセスが許可されます。

アクセスを制限する場合は、FullAWSAccessポリシーを、一連の権限のみ使用できるポリシーに変更します。

アカウントのIAMユーザーやIAMロールは、ポリシーですべてのアクションを実行できる権限を付与されていたとしてもに、SCPで制限された対象アクセスレベルしか実行できません。

ルートアカウントのポリシーを変更する場合、組織内のアカウントはすべて、制限が適用されます。

SCPはアクセス許可を付与することができないため、下の階層でアクセス権限を追加するできません。フィルタ処理のみを行うのです。

拒否リスト

許可されないアクセスを明示的に指定します。その他のアクセス権限はすべて有効になります。

この場合、明示的にブロックしない限り、すべてのアクセス権限が有効です。これがAWS Organizationsのデフォルトの動作です。

デフォルトでは、AWS OrganizationsはFullAWSAccessと呼ばれるポリシーを、組織単位(OU)、そしてアカウントに付与しています。

そのため、どのアカウントでも、AWS Organizationsの制限が適用されることなく、サービスやオペレーションにアクセスできます。

上記の許可リスト手法とは異なり、拒否リストを使用する場合は、デフォルトの FullAWSAccessポリシーをそのまま使用します。

ただし、その際は不要なサービスやアクションへのアクセスを明示的に拒否する追加のポリシーをアタッチします。

IAMポリシーを使用するのと同様に、SCPで特定のサービスやアクションを明示的に拒否すると、許可されているアクションも上書きされ使用できなくなります。

Artificial intelligence (AI) services opt-out policy

組織内のすべてのアカウント間で AWS AIサービスのオプトアウト設定を標準化するのに役立つポリシー。

特定の AWS AIサービスは、Amazon AIサービスおよびテクノロジーの開発と継続的な改善する目的のために、それらのサービスによって処理されたお客様の情報を保存および使用します。

AWSのお客様は、AI サービスのオプトアウトポリシーを使用することで、AWSがコンテンツの保存やサービスの改善のための使用を拒否することができます。

Backup policy

組織内のすべてのアカウント全体でリソースのバックアップ戦略を標準化し、実装するために役立つポリシーのタイプ。バックアップポリシーでは、リソースのバックアップ設定を調整し、デプロイできます。

Tag policy

組織内のすべてのアカウント間でリソース間でタグを標準化するのに役立つポリシー。タグポリシーでは、特定のリソースのタグ付けルールを指定できます。

あとがき

AWSソリューションアーキテクトプロフェッショナルの資格勉強でこの辺を覚えるのが難しかったので、こつこつ訳しながら理解していきました。
AWS Organizationsの理解にはBlack Beltの資料も役に立ちますのでみてみるといいかと思います！
20180214 AWS Black Belt Online Seminar AWS Organizations