全般

AWS Organizations とは何ですか?

AWS Organizations は、AWS のワークロードを拡大しスケールする際に、環境を一元的に管理する場合に役立ちます。伸び盛りのスタートアップ企業でも大企業でも、Organizations があれば、請求の一元管理、アクセス、コンプライアンス、セキュリティの制御、そして AWS アカウント間でのリソース共有に大いに役立ちます。

AWS Organizations ではどの一元管理機能を有効にしますか?

AWS Organizations では、以下の機能を有効にすることができます。

  • 複数の AWS アカウントへの一括請求
  • AWS アカウントの作成と管理の自動化
  • AWS のサービス、リソース、リージョンへのアクセスを管理
  • 複数の AWS アカウントに適用するポリシーを集中管理
  • 複数アカウント間で AWS のサービスを設定

AWS Organizations はどのリージョンで利用できますか?

AWS Organizations は、すべての AWS 商用リージョンおよび AWS GovCloud (米国) で利用できます。AWS Organizations のサービスエンドポイントは、商業組織向けが米国東部 (バージニア北部) に、AWS GovCloud (米国) 組織向けが AWS GovCloud (米国西部) に配置されています。

開始する方法を教えてください。

使用を開始するには、まずマスターアカウントになる AWS アカウントを決める必要があります。新しい AWS アカウントを作成するか、既存のアカウントを選択することができます。

  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 アカウントを使用しているときのみです。

詳細については、AWS Organizations の使用開始を参照してください。

AWS Control Tower と AWS Organizations の違いは何ですか?

AWS Control Tower は複数の AWS のサービス (AWS Organizations を含む) を抽象化して、セキュアな Well-Architected 環境の設定を自動化します。AWS ベストプラクティスを使用してマルチアカウント環境を自動的にデプロイする場合は、AWS Control Tower が最適です。高度なガバナンスおよび管理の機能を備えた独自のカスタムマルチアカウント環境を定義したい場合は、AWS Organizations をお勧めします。

重要な概念

組織とは何ですか?

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

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

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

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

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

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

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

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

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

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

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

ポリシーとは何ですか?

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

AWS アカウントの整理

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

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

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

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

組織に 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 にアタッチされるポリシーは、新しいアカウントで自動的に継承されます。

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

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

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

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

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

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

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

はい。しかし、まずお客様の組織からアカウントを削除して、スタンドドアロンのアカウントにしておく必要があります (下参照)。アカウントをスタンドアロンにしてから、別の組織に加入するように招待できます。

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

はい。AWS Organizations コンソール、API、またはCLI コマンドを用いてアカウントを作成した場合、AWS はスタンドアロンアカウントに必要な情報をすべては集めません。スタンドアロンにしたい各アカウントに対して次の情報を更新してください: 連絡先情報、AWS カスタマーアグリーメントへの同意、有効な支払方法、サポートプランオプションの選択。このお支払い方法は、アカウントが組織に関連付けられていない間に発生する AWS の課金対象 (AWS 無料利用枠外) のアクティビティに対して課金するために使用されます。詳細については、組織からのメンバーアカウントの削除を参照してください。

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

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

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

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

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

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

組織単位 (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 の作成と管理を実行できます。

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

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

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

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

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

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

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

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

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

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

コントロールの管理

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

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

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

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

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

詳細については、ポリシーの管理を参照してください。

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

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

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

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

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

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

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

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

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

SCP は IAM ポリシーと同じルールと文法に従います。SCP の構文については、SCP の構文を参照してください。SCP の例については、サービスコントロールポリシーの例を参照してください。


{
"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":"*"
}
]
}

他の例については、SCP を使用した戦略を参照してください。

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

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

組織に 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 ポリシーでアクセス許可が付与されていない) を実行できません。

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

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

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

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

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

請求

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

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

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

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

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

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

統合された AWS サービス

AWS Organizations と統合された AWS サービスを有効にしなくてはならない理由は何ですか?

AWS サービスは AWS Organizations と統合されたことで、組織内のアカウント間で集中管理および設定を行う機能をお客様に提供します。これにより、アカウント全体のサービスを 1 か所で管理でき、デプロイメントと設定を簡単に行うことができます。

現在、どの AWS サービスが AWS Organizations と統合されていますか?

AWS Organizations と統合された AWS サービスの一覧については、AWS Organizations で使用できる AWS サービスを参照してください。

AWS サービス統合を有効にするには、どうすれば良いですか?

AWS Organization と統合された AWS サービスの使用を開始するには、そのサービスに移動して統合を有効にしてください。

AWS Organizations の詳細

特徴ページをご覧ください
構築の準備はできましたか?
AWS Organizations の開始方法
ご不明な点がおありですか?
お問い合わせ