AWS Control Tower のネストされた OU - AWS Control Tower

AWS Control Tower のネストされた OU

この章では、AWS Control Tower でネストされた OU を操作する際に留意すべき想定事項と考慮事項を示します。ネストされた OU での操作は、ほとんどの点でフラットな OU 構造での操作と同じです。[Register] (登録) 機能と [Re-register] (再登録) 機能はネストされた OU で動作しますが、変更された動作もあり、それについてはこの章で説明します。

動画チュートリアル

この動画 (4:46) では、AWS Control Tower でネストされた OU デプロイを管理する方法について説明しています。動画の右下にあるアイコンを選択すると、全画面表示にできます。字幕を利用できます。

ネストされた OU とランディングゾーンのベストプラクティスに関するガイダンスについては、ブログ記事の「Organizing your AWS Control Tower landing zone with nested OUs」 (ネストされた OU による AWS Control Tower ランディングゾーンの編成) を参照してください。

フラットな OU 構造からネストされた OU 構造への拡張

フラットな OU 構造で AWS Control Tower ランディングゾーンを作成した場合は、それをネストされた OU 構造に拡張できます。

このプロセスには主に次の 4 つのステップがあります。

  1. AWS Control Tower で目的のネストされた OU 構造を作成します。

  2. AWS Organizations コンソールに移動し、一括移動機能を使用して、移動元の OU (フラット) から移動先の OU (ネスト) にアカウントを移動します。その方法は次のとおりです。

    1. アカウントの移動元となる OU に移動します。

    2. OU 内のすべてのアカウントを選択します。

    3. [Move] (移動) を選択します。

      注記

      AWS Control Tower には [Move] (移動) 機能がないため、このステップは AWS Organizations コンソールで実行する必要があります。

  3. AWS Control Tower のネストされた OU に移動し、[Register] (登録) または [Re-register] (再登録) の操作を行います。ネストされた OU 内のすべてのアカウントが登録されます。

    • AWS Control Tower に OU を作成した場合は、OU の [Re-register] (再登録) を行います。

    • AWS Organizations で OU を作成した場合は、初めに OU を登録します。

  4. アカウントを移動して登録したら、AWS Organizations コンソールまたは AWS Control Tower コンソールから、最上位の空の OU を削除します。

ネストされた OU の登録の事前チェック

ネストされた OU とそのメンバーアカウントを正常に登録できるように、AWS Control Tower では一連の事前チェックが実行されます。これと同じ事前チェックが、最上位の OU またはネストされた OU を登録するときにも実行されます。詳細については、「登録時または再登録時に発生する障害のよくある原因」を参照してください。

  • すべての事前チェックにパスすると、AWS Control Tower が自動的に OU の登録を開始します。

  • 事前チェックが失敗した場合、AWS Control Tower は登録プロセスを停止し、OU を登録する前に修正する必要がある項目のリストを示します。

ネストされた OU とロール

AWS Control Tower は、ターゲット OU の下にあるアカウントと、ターゲット OU の下にネストされたすべての OU にあるアカウントに対して、AWSControlTowerExecution ロールをデプロイします。これは、ターゲット OU のみを登録する場合でも同様です。管理アカウント [Administrator] (管理者) のすべてのユーザーに、AWSControlTowerExecution ロールを持つアカウントに対する許可が付与されます。このロールを使用すると、AWS Control Tower ガードレールでは通常許可されないアクションを実行できます。

このロールは、登録する予定がない未登録のアカウントから削除できます。このロールを削除すると、ロールをアカウントに復元しない限り、AWS Control Tower にアカウントを登録したり、直接の親 OU を登録したりすることはできません。アカウントから AWSControlTowerExecution ロールを削除するには、AWSControlTowerExecution ロールでサインインする必要があります。他の IAM プリンシパルには AWS Control Tower で管理されるロールの削除が許可されていないためです。

ロールへのアクセスを制限する方法については、「ロールの信頼関係のオプションの条件」を参照してください。

ネストされた OU とアカウントの登録時および再登録時の処理

ネストされた OU を登録または再登録すると、AWS Control Tower がターゲット OU の未登録アカウントをすべて登録し、登録済みのアカウントをすべて更新します。以下のような処理が発生すると想定されています。

AWS Control Tower が次のタスクを実行する

  • この OU の下にあるすべての未登録アカウントと、そのネストされた OU 内にあるすべての未登録アカウントに対して、AWSControlTowerExecution ロールを追加します。

  • 未登録のメンバーアカウントを登録します。

  • 登録済みのメンバーアカウントを再登録します。

  • 新しく登録されたメンバーアカウントの IAM Identity Center ログインを作成します。

  • 既存の登録済みのメンバーアカウントを更新して、ランディングゾーンへの変更を反映します。

  • この OU とそのメンバーアカウント用に設定されているガードレールを更新します。

ネストされた OU を登録する際の考慮事項

  • コア OU (セキュリティ OU) の下に OU を登録することはできません。

  • ネストされた OU は個別に登録する必要があります。

  • 親 OU が登録されていない限り、OU を登録することはできません。

  • ツリー内で上位にあるすべての OU がある時点で正常に登録されていない限り (既に削除されたものも含めます)、OU を登録することはできません。

  • 上位にあるドリフトされた OU の下に OU を登録することはできますが、そのアクションによってドリフトが修復されることはありません。

ネストされた OU の制限

  • OU は、ルートの下に最大 5 レベルの深さでネストできます。

  • ターゲット OU の下にネストされる OU は、個別に登録または再登録する必要があります。

  • ターゲット OU が階層内のレベル 2 以下にある場合、つまり最上位の OU でない場合、上位にある OU で有効な予防ガードレールが、この OU とその下位にあるすべての OU に自動的に適用されます。

  • OU 登録の失敗は、階層ツリーの上位に伝播されません。親の OU 詳細ページで、ネストされた OU の状態に関する詳細を確認できます。

  • OU 登録の失敗は、階層ツリーの下位に伝播されません。

  • AWS Control Tower は、新規または既存のアカウントの VPC 設定を変更しません。

ネストされた OU とコンプライアンス

AWS Control Tower コンソールから、[Organization] (組織) ページで非準拠の OU とアカウントを表示できるため、広範囲にコンプライアンスを把握できます。

ネストされた OU およびアカウントのコンプライアンスに関する考慮事項

  • OU のコンプライアンスは、その下にネストされた OU のコンプライアンスに基づいて決定されません。

  • ガードレールのコンプライアンスステータスは、ネストされた OU を含め、ガードレールが有効になっているすべての OU で計算されます。「ガードレール、OU、アカウントの AWS Control Tower コンプライアンスステータス」を参照してください。

  • OU は、OU 階層内のどこに配置されているかにかかわらず、非準拠のアカウントがある場合にのみ非準拠として表示されます。

  • ネストされた OU が非準拠の場合、その親 OU は自動的に非準拠とは見なされません。

  • [OU detail] (OU の詳細) または [Account detail] (アカウントの詳細) ページで、OU またはアカウントが非準拠ステータスを示す原因となっている可能性のある非準拠リソースのリストを表示できます。

ネストされた OU とドリフト

状況によっては、ドリフトのためにネストされた OU を登録できないことがあります。

ドリフトとネストされた OU に対する想定

  • ドリフトされた親を持つ OU に対してガードレールを有効にすることはできますが、ドリフトされた OU に対して直接ガードレールを有効にすることはできません。

  • ドリフトされた OU の下で検出ガードレールを有効にすることができます。ただし、最上位のドリフトされた OU でない場合に限られます。

  • 必須ガードレールは、最上位の OU でのみ有効になります。ネストされた OU を登録するときには、必須ガードレールはスキップされます。

  • 1 つの必須ガードレールが AWS Config リソースを保護するため、ネストされた OU を登録するには、その必須ガードレールが非ドリフト状態である必要があります。ドリフトされている場合、AWS Control Tower はネストされた OU の登録をブロックします。

  • 最上位の OU がドリフト状態の場合は、AWS Config リソースを保護するガードレールがドリフト状態である可能性があります。この状況では、AWS Control Tower は、検出ガードレールのアプリケーションを含め、AWS Config リソースの作成または更新を必要とするすべてのアクションをブロックします。

ネストされた OU とガードレール

登録済みの OU でガードレールを有効にした場合、予防ガードレールと検出ガードレールでは動作が異なります。

予防ガードレール

  • 予防ガードレールは、ネストされた OU に適用されます。

  • 必須の予防ガードレールは、OU とそのネストされた OU の下にあるすべてのアカウントに適用されます。

  • 予防ガードレールは、ターゲット OU の下にネストされたすべてのアカウントと OU に影響します。そのアカウントと OU が登録されていない場合でも影響を受けます。

検出ガードレール

  • ネストされた OU は、検出ガードレールを自動的には継承しません。個別に有効にする必要があります。

  • 検出ガードレールは、ランディングゾーンの運用リージョンに登録されているアカウントにのみデプロイされます。

有効化されたガードレールの状態と継承

[OU details] (OU 詳細) ページでは、継承されたガードレールを OU ごとに表示できます。

ヒント

ガードレールの継承を利用して、OU の SCP クォータ内に収めることができます。例えば、ネストされた OU に対してガードレールを直接有効にする代わりに、OU 階層の最上位の OU で有効にすることができます。

ステータスの継承

  • ステータスが [Inherited] (継承済み) の場合、ガードレールが継承によってのみ有効になり、OU に直接適用されていないことを示します。

  • ステータスが [Enabled] (有効) の場合、他の OU での状態に関係なく、ガードレールがこの OU に適用されることを示します。

  • ステータスが [Failed] (失敗) の場合、他の OU での状態に関係なく、ガードレールがこの OU に適用されないことを示します。

注記

ステータスが [Inherited] (継承済み) の場合、ガードレールがツリー内の上位の OU に適用されたことと、この OU に適用されるものの直接には追加されなかったことを示します。

ランディングゾーンが現在のバージョンでない場合

[Enabled guardrails] (有効なガードレール) 表内の各行は、1 つの個別の OU にある 1 つの有効なガードレールを表します。

ネストされた OU とルート

ルートは OU ではなく、登録や再登録ができません。ルートにアカウントを直接作成することもできません。ルートが非準拠になったり、登録済みやドリフトなどのライフサイクル状態になったりすることはありません。

一方で、ルートはすべてのアカウントと OU の最上位のコンテナです。ネストされた OU のコンテキストでは、これは他のすべての OU がネストされているノードです。