AWS Organizations の使用を開始する

AWS Organizations を試用する

すべての AWS のお客様は、追加料金なしで AWS Organizations を利用できます。

Q: AWS Organizations とは何ですか?

AWS Organizations では、複数の AWS アカウントをポリシーベースで管理できます。AWS Organizations を使用して、アカウントのグループを作成し、グループにポリシーを適用できます。また、カスタムスクリプトや手動処理なしで、複数のアカウントに適用するポリシーを集中管理できます。

Q: AWS Organizations ではどのような管理アクションを実行できますか?

AWS Organizations では、以下のような管理アクションを実行できます。

  • AWS アカウントを作成して組織に追加する。または既存の AWS アカウントを組織に追加する。
  • AWS アカウントを整理して、組織単位 (OU) と呼ばれるグループに割り振る。
  • OU を会社の構造を反映した階層に整理する。
  • 組織全体、OU、個別の AWS アカウントに対するポリシーを一元的に管理およびアタッチする。

Q: 今回のリリースにより、AWS Organizations でどのようなコントロールを行えるようになりますか?

今回のリリースにより、Amazon EC2 RunInstance といった AWS のサービスアクションを定義して実行し、組織内にある別々の AWS アカウントで使用できるようになりました。

Q: 一括請求 (コンソリデーティッドビリング) ファミリーから AWS Organizations に移行する必要はありますか?

いいえ。AWS では、一括請求 (コンソリデーティッドビリング) ファミリーから AWS Organizations に自動的に移行されます。一括請求 (コンソリデーティッドビリング) の機能のみが利用できます。

Q: 使用を開始する方法を教えてください。

使用を開始するには、まずマスターアカウントになる AWS アカウントを決める必要があります。一括請求 (コンソリデーティッドビリング) ファミリーを使用しているお客様については、一括請求 (コンソリデーティッドビリング) の支払人 AWS アカウントがマスターアカウントに既に変換されています。一括請求 (コンソリデーティッドビリング) ファミリーを使用していない場合は、新しい AWS アカウントを作成するか、既存の AWS アカウントを選択してください。

一括請求 (コンソリデーティッドビリング) を使用しているお客様向けのステップ

  1. 一括請求コンソールを開きます。新しく開設された AWS Organizations コンソールにリダイレクトされます。
  2. 一括請求 (コンソリデーティッドビリング) ファミリーが自動的に変換されているため、この新しい組織機能をすぐに活用できます。
一括請求 (コンソリデーティッドビリング) を使用していないお客様向けのステップ
 
以下のシンプルなステップにそって、新しい組織を作成する必要があります。
 
  1. 組織を管理するのに使用する AWS アカウントを使って、管理者としてAWS マネジメントコンソールにサインインします。
  2. AWS Organizations コンソールを開きます。
  3. [Create Organization] を選択します。
  4. 組織に対して有効にする機能を選択します。一括請求 (コンソリデーティッドビリング) の機能のみを選択することも、すべての機能を利用することもできます。
  5. 以下の 2 つの方法のいずれかを使用して、AWS アカウントを組織に追加します。
    1. 既存の AWS アカウントの ID かそのアカウントに関連付けられた E メールアドレスを使用して、組織に参加するように招待する。
    2. 新しい AWS アカウントを作成する。
  6. OU に所属する AWS アカウントをグループ化することにより、組織階層をモデル化します。
  7. 組織ですべての機能を有効にすることにした場合は、コントロールを記述して、OU に割り当てることができます。

AWS CLI (コマンドラインによるアクセス) または AWS SDK (プログラムによるアクセス) を使用して、新しい組織を作成するステップを実行することもできます。

注意: 新しい組織を作成できるのは、別の組織のメンバーではない AWS アカウントを使用しているときのみです。
 
詳細については、 Getting Started with AWS Organizations を参照してください。

Q: 組織とは何ですか?

組織は AWS アカウントのコレクションで、階層化して一元管理できます。

Q: AWS アカウントとは何ですか?

AWS アカウントは AWS リソースのコンテナです。AWS リソースは AWS アカウント内で作成と管理が行われます。AWS アカウントにはアクセスと請求の管理機能もあります。

Q: マスターアカウントとは何ですか?

マスターアカウントは、組織の作成に使用する AWS アカウントのことです。マスターアカウントでは、組織内の他のアカウントの作成、他のアカウントが組織に参加するための招待の送信と管理、組織からのアカウントの削除を行うことができます。管理用ルート、組織単位 (OU)、組織内のアカウントといったエンティティにポリシーをアタッチすることもできます。マスターアカウントには支払人アカウントの役割もあり、組織内のアカウントによって発生した料金すべてに対する支払いの責任を負います。組織のマスターアカウントを変更することはできません。

Q: メンバーアカウントとは何ですか?

メンバーアカウントは、組織に所属する AWS アカウントのうち、マスターアカウントではないものです。組織の管理者は、組織内にメンバーアカウントを作成することや、組織に参加するよう既存のアカウントを招待することができます。メンバーアカウントにポリシーを適用することもできます。メンバーアカウントは、一度に 1 つの組織にのみ所属できます。

Q: 管理用ルートとは何ですか?

管理用ルートは、AWS アカウントを整理する開始点になります。管理用ルートは組織の階層内で一番上のコンテナです。このルートの下で、アカウントを論理的にグループ化するために OU を作成し、その OU をビジネスニーズに最適な階層に整理できます。

Q: 組織単位 (OU) とは何ですか?

組織単位 (OU) は組織内で作成した AWS アカウントのグループです。OU に他の OU をネストさせて階層化することもできます。例えば、同じ部門に所属するすべてのアカウントを部門 OU にグループ化できます。同様に、本番サービスを実行中のアカウントすべてを本番 OU にグループ化できます。OU は、同じコントロールを組織内のアカウントのサブセットに適用するために使用できます。OU をネストすると管理の単位を小さくすることができます。例えば、部門 OU の内部にチームレベル OU を作成し、各アカウントを個別のチームにグループ化できます。このような OU では、そのチームレベル OU に直接割り当てられたコントロールに加えて、親 OU から継承したポリシーも適用されます。

Q: ポリシーとは何ですか?

ポリシーは、AWS アカウントのグループに適用するコントロールを定義したステートメントが記述された "ドキュメント" です。今回のリリースにより、AWS Organizations で、サービスコントロールポリシー (SCP) という特別なタイプのポリシーがサポートされるようになりました。SCP では、Amazon EC2 RunInstance など、組織内の異なるアカウントで使用できる AWS のサービスアクションが定義されます。


Q: 組織をリージョン別に定義および管理することはできますか?

いいえ。Organizations のエンティティすべては、現在の AWS Identity and Access Management (IAM) の機能と同様に、グローバルにアクセスできるものです。組織の作成と管理の際にリージョンを指定する必要はありません。AWS アカウント内のユーザーは、そのサービスが利用できるリージョンであれば、どの地理的リージョンでも AWS のサービスを利用できます。

Q: マスターアカウントになる AWS アカウントは変更できますか?

いいえ。マスターアカウントになる AWS アカウントは変更できません。したがって、マスターアカウントは慎重に選択してください。

Q: 組織に AWS アカウントをどのように追加できますか?

以下の 2 つの方法のいずれかを使用して、AWS アカウントを組織に追加できます。

方法 1: 組織に参加するよう既存のアカウントを招待する

  1. マスターアカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。
  2. [Accounts] タブを選択します。
  3. [Add account] を選択してから、[Invite account] を選択します。
  4. 招待するアカウントの E メールアドレスまたはそのアカウントの AWS アカウント ID を入力します。

注意: 複数の E メールアドレスまたは AWS アカウント ID をカンマ区切りで入力することで、一度に複数の AWS アカウントを招待できます。

指定した AWS アカウントに組織への参加を招待する E メールが届きます。招待された AWS アカウントの管理者は、AWS Organizations コンソール、AWS CLI、Organizations API のいずれかでリクエストを承認または拒否する必要があります。招待された AWS アカウントの管理者が招待を承認すると、そのアカウントが組織のメンバーアカウントリストに表示されるようになります。新しく追加されたアカウントでは、SCP など該当するすべてのポリシーが自動的に適用されます。例えば、組織のルートに SCP がアタッチされている場合は、その SCP が新しく作成されたアカウントに直接適用されます。

方法 2: 組織に AWS アカウントを作成する

  1. マスターアカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。
  2. [Accounts] タブを選択します。
  3. [Add account] を選択してから、[Create account] を選択します。
  4. アカウント名とアカウントの E メールアドレスを入力します。

AWS SDK または AWS CLI を使用してアカウントを作成することもできます。どちらの場合も、新しいアカウントを作成した後に、アカウントを組織単位 (OU) に移動できます。その OU にアタッチされるポリシーは、新しいアカウントで自動的に継承されます。

Q: 1 つの AWS アカウントが複数の組織のメンバーになることはできますか?

いいえ。1 つの AWS アカウントが同時に複数の組織のメンバーになることはできません。

Q: 組織内で作成された AWS アカウントにアクセスするにはどうすればよいですか?

AWS アカウント作成の一環として、新しいアカウントで完全な管理権限を持つ IAM ロールが作成されます。マスターアカウント内で適切なアクセス許可を持つ IAM ユーザーと IAM ロールには、新しく作成されたアカウントにアクセスできるよう、この IAM ロールが割り当てられます。

Q: プログラムを使って、組織内に作成する AWS アカウントに多要素認証 (MFA) を設定できますか?

いいえ。現時点でこの機能はサポートされていません。

Q: AWS Organizations を使用して作成した AWS アカウントを別の組織に移すことはできますか?

いいえ。現時点でこの機能はサポートされていません。

Q: Organizations を使用して作成した AWS アカウントを削除して、スタンドアロンアカウントとして使用することはできますか?

はい。ただし、AWS Organizations コンソール、API、CLI コマンドを使用して組織内にアカウントを作成した場合、スタンドアロンアカウントの必須情報がすべて自動的に収集されるわけではありません。スタンドアロンとして使用する各アカウントについて、まずAWS カスタマーアグリーメントに同意し、サポートプランを選択し、必須の連絡先情報を入力および確認して、現在のお支払い方法を入力する必要があります。このお支払い方法は、アカウントが組織に関連付けられていない間に発生する AWS の課金対象 (AWS 無料利用枠外) のアクティビティに対して課金するために使用されます。詳細については、「To leave an organization when all required account information has not yet been provided (console)」をご覧ください。

Q: 組織内で管理できる AWS アカウントはいくつですか?

これは場合によって異なります。 アカウントの追加が必要な場合、AWS サポートセンターでサポートケースを開いて追加を依頼してください。

Q: 組織から AWS メンバーアカウントを削除するにはどうすればよいですか?

メンバーアカウントを削除するには、以下の 2 つの方法のうちいずれかを使用します。Organizations を使用して作成したアカウントを削除するには、情報の追加が必要になる場合があります。アカウントを削除できない場合は、AWS サポートセンターに問い合わせて、アカウントを削除するためのサポートを受けてください。

方法 1: マスターアカウントにサインインして、招待したメンバーアカウントを削除する

  1. マスターアカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。
  2. 左側のペインで [Accounts] を選択します。
  3. 削除するアカウントを選択してから、[Remove account] を選択します。
  4. そのアカウントに有効な支払い方法がない場合は、支払い方法を設定する必要があります。

方法 2: メンバーアカウントにサインインして、招待したメンバーアカウントを削除する

  1. 組織から削除するメンバーアカウントの管理者としてサインインします。
  2. AWS Organizations コンソールを表示します。
  3. [Leave organization] を選択します。
  4. そのアカウントに支払い方法がない場合は、支払い方法を設定する必要があります。

Q: 組織単位 (OU) はどのように作成できますか?

OU を作成するには、次の手順に従います。

  1. マスターアカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。
  2. [Organize accounts] タブを選択します。
  3. 階層内で OU を作成する場所に移動します。ルート直下に作成することも、別の OU 内に作成することもできます。
  4. [Create organizational unit] を選択し、OU に付ける名前を入力します。組織内の別の OU と同じ名前を付けることはできません。

注意: OU の名前は後から変更できます。

AWS アカウントを OU に追加できるようになりました。AWS CLI や AWS API でも OU の作成と管理を実行できます。

Q: AWS メンバーアカウントを OU に追加するにはどうすればよいですか?

OU にメンバーアカウントを追加するには、以下のステップを実行します。

  1. AWS Organizations コンソールで、[Organize accounts] タブを選択します。
  2. AWS アカウントを選択してから、[Move account] を選択します。
  3. ダイアログボックスで、AWS アカウントの追加先になる OU を選択します。

別の方法として、AWS CLI や AWS API を使用して OU に AWS アカウントを追加できます。

Q: 1 つの AWS アカウントが複数の OU のメンバーになることはできますか?

いいえ。1 つの AWS アカウントが同時に複数の OU のメンバーになることはできません。

Q: 1 つの OU が複数の OU のメンバーになることはできますか?

いいえ。1 つの OU が同時に複数の OU のメンバーになることはできません。

Q: OU で設定できる階層の数はいくつですか?

OU をネストできる階層の数は最大で 5 つです。ルートに加え、最下層の OU で作成された AWS アカウントも 1 つの階層と見なされます。


Q: 組織を管理できるユーザーを制御するにはどうすればよいですか?

組織とそのリソースを管理できるユーザーの制御は、他の AWS リソースへのアクセスの管理と同じ方法で実行します。マスターアカウント内で IAM ユーザー、IAM グループ、IAM ロールに IAM ポリシーをアタッチします。IAM ポリシーを使って、以下の点を制御できます。

  • 組織、組織単位 (OU)、AWS アカウントの作成。
  • 組織や OU での AWS アカウントの追加や削除、および組織と OU の間での AWS アカウントの移動。
  • ポリシーの作成、および組織のルート、OU、個別のアカウントへのポリシーのアタッチ。

Q: AWS Organizations で作成したすべてのアカウントに IAM ロールが定義されているのはなぜですか?

このロールは、マスターアカウントのユーザーが新しいメンバーアカウントにアクセスできるようにするためのものです。新しいメンバーアカウントには、最初はユーザーやパスワードがなく、このロールを使用する場合のみアクセスできます。このロールを使用してメンバーアカウントにアクセスし、管理者権限を持つ IAM ユーザーを少なくとも 1 人作成した後は、必要に応じてこのロールを削除しても問題ありません。IAM ロールとユーザーの詳細については、マスターアカウントのアクセスロールを持つメンバーアカウントへのアクセスを参照してください。

Q: 組織を管理する権限は、組織内のどの AWS メンバーアカウントの IAM ユーザーにも付与できますか?

はい。メンバーアカウント内の IAM ユーザーに組織全体または組織の一部の管理権限を付与する場合、IAM ロールを使用できます。マスターアカウントで適切なアクセス許可を持つロールを作成し、メンバーアカウント内のユーザーやロールにその新しいロールを割り当てます。これは、あるアカウント内の IAM ユーザーに別のアカウント内のリソース (Amazon DynamoDB テーブルなど) へのアクセス権を付与するときに使用するクロスアカウントの手法と同じです。

Q: メンバーアカウント内の IAM ユーザーは組織にサインインできますか?

いいえ。IAM ユーザーは、組織内の自分に関連付けられたメンバーアカウントにのみサインインできます。

Q:IAM ユーザーは組織内の OU にサインインできますか?

いいえ。IAM ユーザーは、組織内の自分に関連付けられた AWS アカウントにのみサインインできます。

Q: AWS アカウント内で組織の参加への招待を承認できるユーザーを制御できますか?

はい。IAM 権限を使用して、組織の参加への招待を承認または拒否する権限をアカウント内のユーザーに付与できます。以下のポリシーでは、ある AWS アカウントで招待の表示と管理を行うアクセス権が付与されます。

{

    "Version":"2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action":[

                "organizations:AcceptHandshake",

                "organizations:DeclineHandshake",

                "organizations:DescribeHandshake",

                "organizations:ListHandshakesForAccount"

            ],

            "Resource":" *"

        }

    ]

}

詳細については、Using Identity-Based Policies (IAM Policies) for AWS Organizations を参照してください。


Q: ポリシーを適用できるのは組織のどのレベルですか?

ポリシーは、組織のルートにアタッチして組織内の全アカウントに適用することも、個別の組織単位 (OU) にアタッチして (ネストされた OU も含め) OU 内の全アカウントに適用することもできます。また、個別のアカウントにアタッチすることもできます。

Q: ポリシーをアタッチするにはどうすればよいですか?

ポリシーは、以下の 2 つの方法のいずれかでアタッチできます。

  • AWS Organizations コンソールで、ポリシーを割り当てる対象 (ルート、OU、アカウント) に移動してから、[Attach Policy] を選択します。
  • Organizations コンソールで [Policies] タブを選択し、以下のいずれかを実行します。
    • 既存のポリシーを選択して、[Actions] ドロップダウンの一覧から [Attach Policy] を選択し、ポリシーをアタッチするルート、OU、アカウントを選択します。
    • [Create Policy] を選択してから、ポリシー作成ワークフローの一環として、新しいポリシーをアタッチするルート、OU、アカウントを選択します。

詳細については、Managing Organization Policies を参照してください。

Q: ポリシーは組織の階層関係によって継承されますか?

はい。例えば、AWS アカウントをアプリケーションの開発段階に合わせて DEV、TEST、PROD という OU に編成したと仮定します。ポリシー P1 は組織のルートに、ポリシー P2 は DEV OU に、ポリシー P3 は DEV OU 内の AWS アカウント A1 にそれぞれアタッチされています。この設定では、アカウント A1 に P1 と P2 と P3 がすべて適用されます。

詳細については、About Service Control Policies を参照してください。

Q: AWS Organizations ではどのようなタイプのポリシーがサポートされていますか?

現時点で、AWS Organizations ではサービスコントロールポリシー (SCP) がサポートされています。SCP を使用して、SCP が適用されるアカウント内で IAM ユーザー、IAM グループ、IAM ロールが実行できるアクションを定義し、実行できます。

Q: サービスコントロールポリシー (SCP) とは何ですか?

サービスコントロールポリシー (SCP) により、組織のアカウントでプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) にアクセスできる AWS のサービスアクションを制御できます。SCP は必須ですが、アカウントでリソースにアクセスできるプリンシパルを決定する唯一のコントロールではありません。SCP がアタッチされたアカウント内のプリンシパルに対する有効なアクセス許可は、SCP で明示的に許可されたものと、プリンシパルにアタッチされたアクセス許可で明示的に許可されたものとの共通部分になります。例えば、アカウントに適用された SCP では Amazon EC2 アクションが許可される唯一のアクションと定義されており、同じ AWS アカウント内のプリンシパルでのアクセス許可では EC2 アクションと Amazon S3 アクションとが許可されている場合、プリンシパルからアクセスできるのは EC2 アクションのみになります。

メンバーアカウント内のプリンシパル (メンバーアカウントのルートユーザーを含む) は、そのアカウントに適用されている SCP の削除や変更を行うことができません。

Q: SCP はどのような形式ですか?

条件を指定できないことと、リソースセクションが "*" と等しくなければならないことを除き、SCP のルールと文法は IAM ポリシーと同じです。SCP を使用して、AWS のサービスアクションの拒否や許可が行えます。

ホワイトリストの例

以下の SCP では、AWS アカウント内のすべての EC2 および S3 サービスアクションへのアクセス権が付与されています。この SCP が適用されるアカウント内のすべてのプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) は、どのような IAM ポリシーが直接割り当てられているかにかかわらず、他のアクションにアクセスできません。プリンシパルが EC2 サービスアクションや S3 サービスアクションにアクセスするためには、このような IAM ポリシーでアクセス権を明示的に付与する必要があります。

{

    "Version":"2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action":["EC2:*","S3:*"],

            "Resource":"*"

        }

    ]

}

ブラックリストの例

以下の SCP では、S3 の PutObject アクションを除き、AWS のサービスアクションすべてに対するアクセス権が許可されています。すべてのプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) は、この SCP が適用されたアカウント内で適切なアクセス許可が直接割り当てられている場合、S3 の PutObject アクションを除くすべてのアクションにアクセスできます。

{

    "Version":"2012-10-17",

    "Statement":[

        {

            "Effect": "Allow",

            "Action": "*:*",

            "Resource":"*"

        },

        {

            "Effect": "Deny",

            "Action":"S3:PutObject",

            "Resource":"*"

        }

    ]

}

他の例については、Strategies for Using SCPs を参照してください。

Q: 空の SCP を AWS アカウントにアタッチした場合、その AWS アカウント内のすべての AWS のサービスアクションを許可したことになりますか?

いいえ。SCP は IAM ポリシーと同じように動作し、空の IAM ポリシーはデフォルトで拒否に相当します。アカウントに対する空の SCP のアタッチは、すべてのアクションを明示的に拒否するポリシーのアタッチに相当します。

Q: SCP でリソースとプリンシパルを指定できますか?

いいえ。現行のリリースでは、SCP で AWS のサービスとアクションのみを指定できます。リソースとプリンシパルは、AWS アカウント内で IAM アクセス許可ポリシーを使用することによって指定できます。詳細については、Service Control Policy Syntax を参照してください。

Q: 組織に SCP を適用したものの、プリンシパルに IAM ポリシーも適用されている場合、有効なアクセス許可はどうなりますか?

SCP が適用された AWS アカウントでのプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) に付与される有効なアクセス許可は、SCP でのアクセス許可と IAM アクセス許可ポリシーでプリンシパルに付与されたアクセス許可の共通部分になります。例えば、ある IAM ユーザーに "Allow": "ec2:* " および "Allow": "sqs:* " が指定されており、そのアカウントにアタッチされた SCP では "Allow": "ec2:* " および "Allow": "s3:* " が指定されている場合、その IAM ユーザーに対する最終的なアクセス許可は "Allow": "ec2:* " となります。このプリンシパルは Amazon SQS (SCP で許可されていない) や S3 アクション (IAM ポリシーでアクセス許可が付与されていない) を実行できません。

Q: AWS アカウントで SCP の影響をシミュレートすることはできますか?

はい。IAM Policy Simulator では SCP の影響も確認できます。Policy Simulator を組織内のメンバーアカウントで使用すると、そのアカウント内の個別のプリンシパルに対する影響を確認できます。AWS Organizations の適切なアクセス許可を持つメンバーアカウント内の管理者は、SCP がメンバーアカウント内のプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) に対するアクセスに影響しているかどうかを確認できます。

詳細については、サービスコントロールポリシーを参照してください。

Q: SCP の適用なしで組織の作成と管理を実行できますか。

はい。適用するポリシーは自分で決定できます。例えば、組織を作成して、一括請求 (コンソリデーティッドビリング) 機能のみを活用できます。これにより、組織内のすべてのアカウントに対して 1 つの支払人アカウントを持つことができ、デフォルトの階層化された料金を自動的に活用できます。


Q: AWS Organizations の費用はどれくらいですか?

AWS Organizations に追加料金は必要ありません。

Q: 組織内の AWS メンバーアカウントのユーザーによって発生した使用料は誰が支払いますか?

組織内のアカウントによって使用されたすべてのサービス、データ、リソースに対する支払いに責任があるのは、マスターアカウントの所有者です。

Q: 一括請求 (コンソリデーティッドビリング) と比較して AWS Organizations は何が違いますか?

一括請求 (コンソリデーティッドビリング) の機能は AWS Organizations に組み込まれました。Organizations では、お客様の社内で複数の AWS アカウントの 1 つを支払人アカウントに指定して、支払いをまとめることができます。詳細については、Consolidated Billing and AWS Organizations を参照してください。

Q: 組織内で作成した組織単位構造は請求書に反映されますか?

いいえ。現時点では、組織内で定義された構造は請求書に反映されません。個別の AWS アカウントでコスト配分タグを使用すれば、AWS のコストのカテゴリ分けと追跡ができ、この配分は組織の一括請求書で確認できます。