AWS Control Tower / Landing Zone難易度 高無料
ある企業が、これから50アカウント規模へ拡大予定のマルチアカウント環境を新規構築する。要件は次の通り。
- ベースラインのガードレール（リージョン制限・ルート活動監視・暗号化必須等）を標準化して全アカウントに一貫適用したい
- 新規アカウントのプロビジョニングを自己サービス的（セルフサービス）に、標準化された形で素早く行いたい
- ガードレール違反や設定ドリフトを継続的に検知したい
- 社内に専任の大規模SCP/CloudTrail/Config運用チームは無く、運用負荷は極力抑えたい
このマルチアカウント基盤の構築方法として最も適切なものを選べ。（単一選択）
- AAWS Control Towerでランディングゾーンを構築し、事前定義済みのプリベンティブ/ディテクティブガードレールを有効化、Account Factoryで新規アカウントを標準化されたセルフサービスでプロビジョニングする
- BAWS Organizationsのみを有効化し、全アカウントに個別にカスタムSCPを手作業でアタッチする。ドリフト検知やアカウント払い出しの標準化は各チームが個別に実装する
- C各事業部に個別のAWSアカウントを作成させ、ガードレールの適用は各アカウント担当者の裁量に委ねる
- D単一のAWSアカウント内でVPCとIAMロールを事業部ごとに分離し、マルチアカウント化を回避する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
AWS Control Towerは、Organizations・SCP・CloudTrail組織証跡・Config・IAM Identity Centerなどの基盤サービスを ベストプラクティスに基づいて自動構成し、事前定義された「ガードレール（プリベンティブ＝SCPベース／ディテクティブ＝Configルールベース／プロアクティブ＝CloudFormation Hooksベース）」を 一括適用できるマネージドサービスである。
- Account Factoryにより、標準化されたネットワーク・IAM Identity Center・ガードレール適用済みの新規アカウントを セルフサービス（またはAccount Factory for Terraform経由）で払い出せる。
- ガードレールはプリベンティブ（SCPで拒否）・ディテクティブ（Config管理ルールで違反検知・ダッシュボード表示）・プロアクティブ（CloudFormation Hooksでプロビジョニング前にブロック）の3種を あらかじめ用意されたカタログから選んで有効化でき、自前でSCP文言やConfigルールを1から設計・保守する必要が大幅に減る。
- 組織全体のCloudTrail証跡・Config記録・集約ログ用S3バケットも自動構成されるため、運用負荷の小さいチームでも 一貫したガバナンス基盤を短期間で立ち上げられる。
「自前でOrganizations・SCP・CloudTrail組織証跡・Config Aggregatorを1から設計・実装する」アプローチも技術的には可能だが、 要件にある「運用負荷を抑えたい」「素早く標準化してセルフサービス化したい」に対してはControl Towerが本来の適用対象であり、 再発明を避けられる。
- BSCPによるプリベンティブ統制はできるが、ディテクティブ検知（Config管理ルール）・標準化されたセルフサービスのアカウント払い出しは別途1から構築が必要で、要件の「運用負荷を抑えたい」に反する。
- C一貫したガバナンス（要件の「標準化して全アカウントに一貫適用」）が担保できず、アカウントごとに設定がバラつくリスクが高い。
- D50アカウント規模への拡大が前提の要件に反する。単一アカウント内分離はセキュリティ境界・課金分離・爆発半径の観点で大規模組織には不十分。
ひっかけ： 「SCPだけ自前で書けば十分（B）」という発想は、ガードレールのプリベンティブ面はカバーできてもディテクティブ検知・
アカウントプロビジョニングの標準化・ドリフト検知までは自前実装が必要になり運用負荷が大きい。Control Towerは
Organizations＋SCP＋CloudTrail＋Config＋Account Factoryを束ねたガバナンスの「上位レイヤー」という位置づけを理解する。
公式ドキュメント・関連AWS Control Tower User Guide ― What is AWS Control Tower?↗AWS Control Tower User Guide ― Guardrails↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）