アカウント分離戦略難易度 高無料
ある企業は現在、開発・ステージング・本番の3環境を1つのAWSアカウント内でVPCとタグだけで分離運用している。過去に開発環境の作業ミスで本番用IAMロールに誤って過剰な権限が付与される事故が起きた。今後同種の事故を防ぎ、かつ環境間のブラストラディウス（影響範囲）を最小化したい。最も適切な再設計方針を選べ。（単一選択）
- A開発・ステージング・本番をそれぞれ独立したAWSアカウントに分離し、OrganizationsのOU構成（Prod OU / NonProd OU）で環境ごとに異なる強度のSCPを適用する。環境間の正規連携はクロスアカウントロールの明示的な引き受けに限定する
- B単一アカウントは維持したまま、IAMポリシーの条件キーとリソースタグの命名規則をより厳密化し、レビュー体制を強化することで同種の事故を防ぐ
- C本番環境用に新しいAWS Organizationsの組織を別途作成し、開発・ステージングの既存組織とは完全に無関係な独立組織として運用する
- D本番用IAMロールにMFA必須の条件を追加するだけで、アカウント構成自体は変更しない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
AWSのマルチアカウント戦略のベストプラクティスでは、環境（開発/ステージング/本番）はアカウントレベルで分離することが推奨される。 同一アカウント内でVPC・タグ・IAMポリシーの条件だけで環境を分けるアプローチは、IAM設定の1つのミスが全環境に波及しうるという 根本的な弱点を抱える。
- アカウントごとの分離により、IAMポリシー・SCP・課金・サービスクォータ・CloudTrail証跡がアカウント境界で完全に独立し、 ある環境での設定ミスが他環境のリソースへ直接影響しなくなる（ブラストラディウスの限定）。
- OrganizationsのOU構成で「Prod OU」「NonProd OU」のように分け、Prod OUには本番専用の厳格なSCP （例：特定のCLIプロファイル/踏み台からのみ許可等）を適用し、NonProd OUにはより緩やかな開発用SCPを適用するなど、 OU単位でガードレールの強度を差別化できる。
- アカウント間の正規のデータ連携（例：ステージングから本番の匿名化データ取得等）が必要な場合は、 クロスアカウントIAMロール引き受けなど明示的な最小権限の経路のみを許可する。
これにより、単一アカウント内でタグ/条件キーだけに依存する脆い分離から、AWSの構造的な境界（アカウント）を使った堅牢な分離へ移行できる。
- B運用改善にはなるが、構造的にはIAM設定1つのミスが全環境（同一アカウント内）に波及しうるリスクの根本原因が残る。ブラストラディウスの最小化にはアカウント境界による分離が必要。
- C別組織にすると一元課金・一元ログ・SCPによる統一ガバナンスが分断され、全社的な可視性・管理性が低下する。通常は単一組織内でOUによって分離する。
- DMFA強制は認証強化として有効だが、「環境間のブラストラディウス最小化」という要件には直接応えておらず、同一アカウント内の設定ミス波及リスクは解消しない。
ひっかけ： 「IAMポリシーの条件キー（タグ等）をより厳密に書けば同一アカウントのままでも防げる（B）」は運用上は改善だが、
1つのポリシーミス・タグ付け忘れが即座に全環境へ波及するリスクの構造自体は解消されない点がProfessionalレベルで問われる急所。
アカウント分離は「うっかりミスの影響範囲をAWSの構造的な境界で断つ」設計であることを理解する。
公式ドキュメント・関連AWS Organizations User Guide ― Best practices for AWS Organizations↗AWS Prescriptive Guidance ― Organizing your AWS environment using multiple accounts↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）