ある企業が AWS Organizations を使って管理しているマルチアカウント環境で、各開発チームが自律的に AWS リソースを作成できるよう「セルフサービス型のアカウント払い出し」を実装したいと考えています。新しいアカウントが払い出される際には、自動的に企業標準のセキュリティ設定（CloudTrail 有効化、GuardDuty 有効化、デフォルト VPC の削除、ベースライン IAM ロールの作成）が適用される必要があります。最も適切な実装はどれですか？
- A. AWS Service Catalog でアカウントプロビジョニング製品を作成し、承認フローを経て新アカウントを作成する。CloudFormation で標準設定を手動デプロイする
- B. AWS Control Tower Account Factory または Account Factory for Terraform（AFT）を使用し、新しいアカウントのプロビジョニング時に標準設定を自動適用するカスタマイズ（Account Factory Customization: AFC）を定義する。CloudTrail、GuardDuty、VPC、IAM ロールのカスタマイズを AFT のカスタマイズパイプラインとして定義する
- C. 開発チームが Organizations のコンソールから直接アカウントを作成し、CloudFormation StackSets で標準設定を後から展開する
- D. 開発チームがアカウントを作成したら、セキュリティチームが手動で標準設定を適用する手順書を配布する
解答と解説を見る
正解: B
Control Tower Account Factory は新しいアカウントのプロビジョニングを標準化し、VPC/IAM/CloudTrail/GuardDuty などの設定を自動的に適用します。Account Factory for Terraform（AFT）を使うと、Terraform でカスタマイズを定義し、新アカウント作成時に自動的にパイプラインが実行されてすべての標準設定が適用されます。既存の Control Tower ガードレールとも統合されます。 D: 手動での設定適用は時間がかかり、設定漏れのリスクがあります。大規模なマルチアカウント環境では自動化が必須です。 A: Service Catalog + CloudFormation の手動デプロイは自動化が不完全です。アカウント作成後に CloudFormation を手動実行する必要があり、セルフサービスの自動化要件を満たしません。 C: StackSets での「後から」展開はアカウント作成から設定適用までの時間差が生じ、その間にセキュリティ設定なしのアカウントが存在することになります。
📚 関連サービスの解説: AWS CloudTrail ・ Amazon GuardDuty