ある企業が複数の事業部門のためにセキュリティと自律性のバランスを取ったマルチアカウント設計を策定しています。各事業部門はそれぞれ独自の AWS アカウントを持ち、独立して操作できますが、中央の IT チームはセキュリティ基準への準拠を強制し、一部の共有サービス（DNS、ネットワーク、セキュリティ監視）を提供する必要があります。最も適切な AWS Landing Zone 設計はどれですか？
- A. すべての事業部門を同一の OU に入れ、すべて同一の SCP を適用する
- B. Organizations に Management、Security、Shared Services、Log Archive、各事業部門の OU 構造を設計する。Management アカウントは Organizations の管理のみ使用し、Security アカウントに GuardDuty/Security Hub の委任管理者を設定し、Shared Services アカウントで DNS/VPC/Transit Gateway などの共有インフラを提供する。各事業部門アカウントには SCP で最低限のセキュリティ基準を強制しながら、日々のリソース管理は自律して実施できるようにする
- C. 各事業部門が独自の Organizations を持ち、中央の IT が各 Organizations を個別に管理する
- D. すべての事業部門が単一の AWS アカウントを共有し、IAM ポリシーで部門ごとのアクセスを制御する
解答と解説を見る
正解: B
AWS のベストプラクティスである Landing Zone 設計では、Management（管理）、Security（セキュリティ）、Shared Services（共有サービス）、Log Archive（ログ集約）の各機能用アカウントを分離します。Management アカウントは組織管理に専念し、Security アカウントで中央セキュリティ監視を行い、Shared Services アカウントで DNS/ネットワークを一元提供します。各事業部門 OU に SCP を適用しながら自律性を確保するバランスが実現できます。 D: 単一アカウント共有はセキュリティの分離がなく、事業部門間のリソース誤削除や権限エスカレーションのリスクが高く、スケールしません。 A: すべての OU への同一 SCP 適用は、事業部門ごとの異なる要件（本番/開発の差異など）に対応できません。 C: 複数の Organizations は AWS の設計に反し、Organizations の一括請求、セキュリティ委任、CloudTrail 組織トレイルなどの機能が使えなくなります。
📚 関連サービスの解説: AWS Organizations ・ Amazon GuardDuty