AWS Organizations OU設計難易度 標準無料
新規にランディングゾーンを設計する企業が、OU構成の方針についてアドバイスを求めている。AWSのマルチアカウント戦略のベストプラクティスに沿ったOU設計方針として最も適切なものを選べ。（単一選択）
- A基盤（Security/Infrastructure等）を格納するFoundational OUと、実際のワークロードを格納するWorkloads OUを分け、Workloads OU配下をさらにProd/NonProdのように環境単位で分割し、それぞれに適したSCP/ガードレールを適用する
- B社内の人事上の組織図（部署・チーム構成）をそのままOU階層としてミラーリングし、部署異動があるたびにOU構成も追随して変更する
- C全アカウントを1つのフラットなOUにまとめ、SCPは各アカウントへ個別にアタッチすることで柔軟性を最大化する
- DリージョンごとにOUを分割し、東京リージョン用OU・バージニアリージョン用OUのようにリージョン単位でガードレールを管理する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
AWSが推奨するOU設計のベストプラクティスは、まず「基盤（Foundational）OU」と「ワークロード（Workloads）OU」を分ける ことから始める。
- Foundational OU：
Security（ログ集約・セキュリティツール用アカウント）、Infrastructure（共有ネットワーク等）のような、組織全体を横断して必要になる基盤アカウントを格納する。ほぼ全組織で共通の構成になる。 - Workloads OU：実際のビジネスアプリケーションが稼働するアカウント群。この配下をさらに
Prod/NonProd（あるいは事業部・システム単位）に分割し、環境ごとに異なる強度のSCP・ガードレールを適用する。 - OUの分割粒度は「組織構造そのものを模倣する」のではなく、ポリシー（SCP・ガードレール）の適用単位として意味のある分割 （同じポリシーを当てたいアカウント群をまとめる）を優先すべきとされる。
- B組織図と1対1対応させると、人事異動のたびにOU再編・SCP再適用が発生し運用が破綻しやすい。OUはポリシー適用単位で設計すべきで、組織図の反映が目的ではない。
- Cフラット構成では環境（本番/非本番等）ごとに異なる強度のガバナンスを一括適用できず、アカウント数が増えるほど個別管理の運用負荷が線形に増大する。
- DOUはアカウント単位のグルーピングであり、リージョンという粒度とは直接対応しない。リージョン制御はSCPの
aws:RequestedRegion条件キー等で行うのが適切。
ひっかけ： 「組織図（部署構造）をそのままOU構成に反映する（誤答の1つ）」という発想はよくある誤設計。
OUは「同じガードレール/SCPを当てたい単位」でグルーピングするものであり、人事上の組織図と1対1対応させる必要はない
（むしろ部署異動のたびにOU再編が必要になり運用が破綻しやすい）。
公式ドキュメント・関連AWS Prescriptive Guidance ― Organizing your AWS environment using multiple accounts (OU design)↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）