AWS Organizations のよくある質問

Q: AWS Organizations とは何ですか?

AWS Organizations は、AWS のワークロードをスケールする際に、環境を一元的に管理する場合に役立ちます。成長を続けるスタートアップでも大企業でも、Organizations は、プログラムを使用して新しいアカウントを作成してリソースを割り当て、すべてのアカウントに単一の支払い方法を設定して請求を簡素化し、アカウントのグループを作成してワークフローを整理し、ガバナンスのためにこれらのグループにポリシーを適用するのに役立ちます。加えて、AWS Organizations は他の AWS のサービスと統合しているため、中央での設定、セキュリティメカニズム、組織内のアカウント間でのリソース共有を定義できます。

Q: AWS Organizations ではどの一元管理機能を有効にしますか?
AWS Organizations では、以下の機能を有効にすることができます。

• AWS アカウントの作成と管理を自動化し、AWS CloudFormation スタックセットを使用してリソースをプロビジョニングする
• AWS セキュリティサービスのポリシーおよび管理を使用して、安全な環境を維持する
• AWS のサービス、リソース、リージョンへのアクセスを管理
• 複数の AWS アカウントに適用するポリシーを集中管理
• コンプライアンスについて環境を監査する 
• 一括請求 (コンソリデーティッドビリング) を使用して、コストを表示および管理する 
• 複数アカウント間で AWS のサービスを設定
  

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

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

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

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

1. 組織の管理に使用する AWS アカウントを使って、管理者として AWS マネジメントコンソールにサインインします。
2. AWS Organizations コンソールを開きます。
3. [Create Organization (組織の作成)] を選択します。
4. 組織に対して有効にする機能を選択します。すべての機能を利用することも、一括請求 (コンソリデーティッドビリング) の機能のみを選択することもできます。 AWS Organizations のすべての中央管理機能を利用する場合は、すべての機能を選択することをお勧めします。
5. 以下の 2 つの方法のいずれかを使用して、AWS アカウントを組織に追加します。 
   1. 既存の AWS アカウントの ID かそのアカウントに関連付けられた E メールアドレスを使用して、組織に招待する。
   2. 新しい AWS アカウントを作成する。
6. OU に所属する AWS アカウントをグループ化することにより、組織階層をモデル化します。
7. OU、アカウント、または組織 (すべての機能を備えた組織でのみ使用可能) のポリシー (サービスコントロールポリシーやバックアップポリシーなど) を作成します。
8. AWS Organizations と統合されている AWS のサービスを有効にします。
   

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

注: 新しい組織を作成できるのは、別の組織のメンバーではない AWS アカウントを使用しているときのみです。

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

Q: AWS Control Tower とは?

AWS Organizations などの AWS のサービスに基づいて構築された AWS Control Tower は、新しい安全なマルチアカウント AWS 環境をセットアップおよび管理するための最も簡単な方法を提供します。これは、ベストプラクティスの青写真に基づいて Well-Architected でマルチアカウントの環境であるランディングゾーンを確立し、選択可能なガードレールを使用したガバナンスを可能にします。ガードレールは、セキュリティ、コンプライアンス、および運用のガバナンスを実装する SCP および AWS Config ルールです。

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

AWS Control Tower は、AWS Organizations に加えて、抽象化され、自動化された、規範的なエクスペリエンスを提供します。アカウントを整理するための基盤となる AWS のサービスとしてAWS Organizations を自動的に設定し、SCP を使用して予防ガードレールを実装します。Control Tower と Organizations は連携して機能します。Control Tower を使用して環境をセットアップし、ガードレールを設定してから、AWS Organizations を使用して、複数の AWS アカウント間で AWS のサービスとリソースの使用を一元的に管理するカスタムポリシー (タグ、バックアップ、SCP など) をさらに作成できます。

Q: AWS Control Tower はガードレールを使用しています。ガードレールとは何ですか?

ガードレールは、セキュリティ、オペレーション、コンプライアンス向けの事前にパッケージ化された SCP および AWS Config ガバナンスルールです。これらは、お客様が選択し、企業全体または特定のアカウントのグループに適用できます。ガードレールは簡単な英語で表現されています。これを使用することで、特定のガバナンスポリシーが AWS 環境に適用され、組織単位 (OU) 内で有効になります。

Q: AWS Control Tower はどのような場合に使用する必要がありますか?

AWS Control Tower は、組み込みのベストプラクティスを使用してマルチアカウント AWS 環境を作成または管理したいお客様のためのものです。AWS 環境を大規模に管理するための規範的なガイダンスを提供し、AWS がビルダーに提供する速度と俊敏性を犠牲にすることなく環境を管理できるようにします。新しい AWS 環境を構築する場合、AWS でのジャーニーを始める場合、新しいクラウドイニシアチブを開始する場合、AWS を初めて使用する場合、または既存のマルチアカウント AWS 環境がある場合は、AWS Control Tower の恩恵を享受できます。

Q: 組織とは何ですか?

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

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

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 に 2 つのネストされた OU を作成して、本番ワークロードと本番前のワークロードを分割できます。このような OU では、そのチームレベル OU に直接割り当てられたコントロールに加えて、親 OU から継承したポリシーも適用されます。

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

ポリシーは、AWS アカウントのグループに適用するコントロールを定義したステートメントが記述された "ドキュメント" です。AWS Organizations は、次のポリシーをサポートしています。

• バックアップポリシー — 指定されたケイデンスで AWS バックアップが必要です
• タグポリシー — タグキーと許可される値を定義します
• AI サービスのオプトアウトポリシー — AI サービスがコンテンツを保存または使用する方法を管理します
• Service Control Policies (SCPs) — SCP では、Amazon EC2 RunInstance など、組織内の異なるアカウントで使用できる AWS のサービスアクションが定義されます。
  

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

組織のエンティティすべては、現在の AWS Identity and Access Management (IAM) の機能と同様に、中国で管理される組織を除き、グローバルにアクセスできるものです。組織を作成および管理するときに AWS リージョンを指定する必要はありませんが、中国で使用されるアカウント用に別の組織を作成する必要があります。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 アカウント作成の一環として、AWS Organizations は、新しいアカウントで完全な管理アクセス許可を持つ IAM ロールを作成します。マスターアカウント内で適切なアクセス許可を持つ IAM ユーザーと IAM ロールには、新しく作成されたアカウントにアクセスできるよう、この IAM ロールが割り当てられます。

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

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

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

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

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

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

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: ポリシーを適用できるのは組織のどのレベルですか?

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

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

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

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

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

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

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

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

現在、AWS Organizations は次のポリシーをサポートしています。

• バックアップポリシー — AWS Backup を使用して指定されたケイデンスでバックアップが必要です
• タグポリシー — タグキーと許可される値を定義します
• AI サービスのオプトアウトポリシー — AI サービスが組織のコンテンツを保存または使用する方法を管理します
• Service Control Policies (SCPs) — 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 の構文については、「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 を使用した戦略を参照してください。

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

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

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 アカウントでコスト配分タグを使用すれば、AWS のコストのカテゴリ分けと追跡ができ、この配分は組織の一括請求書で確認できます。

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

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

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

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

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

AWS Organization と統合された AWS サービスの使用を開始するには、AWS マネジメントコンソールでそのサービスに移動して統合を有効にしてください。