学んだ教訓とベストプラクティス

OU 構造設計は 1 回限りの作業ではありません。企業がクラウドの導入を増やし、追加のワークロードを AWS ランディングゾーンに移行するにつれて、その OU 設計 (および暗黙的にそのポリシーの概念) も自然に進化します。

OU をフォルダと間違えないでください。OU はポリシーの対象と考えてください。OU とその階層は AWS アカウント の構造化要素を提供し、常にポリシーのコンテナとして扱う必要があります。同じポリシーセットを必要とするすべての AWS アカウント を同じ OU に配置することをお勧めします。このガイドラインは、ネストされた OU (OU 内の OU) にも適用されます。

一元共有機能とクロスワークロードデータ共有機能 (エンタープライズデータプラットフォームで頻繁に見られる) を必要とする AWS 環境は、事業部門 (LOB) 関数分類に基づいていない OU 構造でより簡単に対応できます。例えば、製造アプリケーションの本番環境は、AWS Organizations のポリシーの観点から見れば、臨床試験分析アプリケーションの本番環境と変わりません。

継承を尊重して使用します。特定の OU にポリシーをアタッチすると、その OU の直下または子 OU の下にある AWS アカウント がポリシーを継承します。特定の AWS アカウント にポリシーをアタッチすると、ポリシーはその AWS アカウント にのみ影響します。

ある OU 構造から別の OU 構造への移行作業は、OU または AWS アカウント レベルで設定されている既存のポリシーの範囲によって異なります。もう 1 つの重要な要因は、既存の OU 階層でポリシー継承がどの程度使用されたか、また継承が壊れたかどうかです。移行の複雑さは、不規則な継承パスや逸脱した継承パスの実装に伴って増大します。例えば、ポリシーを個々の AWS アカウント レベルで適用する場合や、頻繁にポリシー例外 (継承が中断される) を行う場合、それらのポリシーを新しい構造に移行するには、かなりの労力がかかります。このように複雑度が高い場合は、移行計画中にポリシーの継承を確認して再設計することに時間をかけることをお勧めします。

AWS Organizations ポリシーと AWS Control Tower コントロールの両方に対処します。OU 構造は AWS Control Tower と AWS Organizations の間で共有されます。AWS Control Tower は独自の検出コントロールと予防コントロールのセットを提供します。これらのコントロールは AWS アカウント または OU レベルで適用されます。AWS Organizations は OU レベルでポリシーをオーケストレートします。OU 移行では、コンプライアンスの重みが増すため、まず AWS Organizations ポリシーを移行することをお勧めします。2 番目の移行ステップでは、新しい OU 構造に AWS Control Tower コントロールを適用することをお勧めします。

AWS アカウント の更新には時間がかかります。AWS Control Tower を使用して、既存の AWS アカウント を新しい OU 構造に個別に再登録する必要があります。これには時間がかかります。アカウントが多数ある場合は、自動化によってこの作業を合理化し、AWS アカウント の OU 配置を制御および自動化することをお勧めします。次の 2 つのシナリオの例を示します。