AWS Organizations のよくある質問

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

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

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

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

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

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

複数の AWS アカウントを使用することは、コストの自然な請求境界を提供し、セキュリティのためにリソースを分離し、個人やチームのために柔軟性を提供するだけでなく、新しいビジネスプロセスに適応できるため、環境をスケーリングするためのベストプラクティスです。

管理アカウントは、組織の作成に使用する AWS アカウントのことです。管理アカウントでは、組織内の他のアカウントの作成、他のアカウントが組織に参加するための招待の送信と管理、組織からのアカウントの削除を行うことができます。管理用ルート、組織単位 (OU)、組織内のアカウントといったエンティティにポリシーをアタッチすることもできます。管理アカウントは、組織の最終的な所有者であり、セキュリティ、インフラストラクチャ、および財務ポリシーについての最終的な管理権限を有しています。このアカウントには支払者アカウントの役割もあり、組織内のアカウントによって発生した料金すべてに対する支払いの責任を負います。組織の管理アカウントを変更することはできません。

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

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

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

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

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

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

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

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

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

1.管理アカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。

2.[Accounts] タブを選択します。

3.[Add account] を選択してから、[Invite account] を選択します。

4.招待するアカウントの E メールアドレスまたはそのアカウントの AWS アカウント ID を入力します。

注: 複数のメールアドレスまたは 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 アカウントが同時に複数の組織のメンバーになることはできません。

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

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

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

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

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

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

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

1.マスターアカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。

2.左側のペインで [アカウント] を選択します。

3.削除するアカウントを選択してから、[アカウントを削除] を選択します。

4.そのアカウントに有効な支払い方法がない場合は、支払い方法を設定する必要があります。

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

1.組織から削除するメンバーアカウントの管理者としてサインインします。

2.AWS Organizations コンソールを表示します。

3.[Leave organization] (組織を離れる) を選択します。

4.そのアカウントに支払い方法がない場合は、支払い方法を設定する必要があります。

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

1.管理アカウントの管理者としてサインインし、AWS Organizations コンソールに移動します。

2.[アカウントを整理] タブを選択します。

3.階層内で OU を作成する場所に移動します。ルート直下に作成することも、別の OU 内に作成することもできます。

4.[組織単位を作成] を選択し、OU に付ける名前を入力します。組織内の別の OU と同じ名前を付けることはできません。

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

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

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

1.AWS Organizations コンソールで、[Organize accounts] タブを選択します。

2.AWS アカウントを選択してから、[Move account] を選択します。

3.ダイアログボックスで、AWS アカウントの追加先になる OU を選択します。

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

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

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

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

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

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

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

詳細については、「ポリシーの管理」をご覧ください。

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

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

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

サービスコントロールポリシー (SCP) により、組織のアカウントでプリンシパル (アカウントルート、IAM ユーザー、IAM ロール) にアクセスできる AWS のサービスアクションを管理できます。SCP は必須ですが、アカウントでリソースにアクセスできるプリンシパルを決定する唯一のコントロールではありません。SCP がアタッチされたアカウント内のプリンシパルに対する有効なアクセス許可は、SCP で明示的に許可されたものと、プリンシパルにアタッチされたアクセス許可で明示的に許可されたものとの共通部分になります。たとえば、アカウントに適用された SCP では Amazon EC2 アクションが許可される唯一のアクションと定義されており、同じ AWS アカウント内のプリンシパルでのアクセス許可では EC2 アクションと Amazon S3 アクションとが許可されている場合、プリンシパルからアクセスできるのは EC2 アクションのみになります。
メンバーアカウント内のプリンシパル (メンバーアカウントのルートユーザーを含む) は、そのアカウントに適用されている 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 は IAM ポリシーと同じように動作し、空の IAM ポリシーはデフォルトで拒否に相当します。アカウントに対する空の SCP のアタッチは、すべてのアクションを明示的に拒否するポリシーのアタッチに相当します。

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

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

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

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

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

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

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

AWS Organizations と統合された AWS サービスの一覧については、「AWS Services That You Can Use with AWS Organizations」をご覧ください。

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