ある大手メディア企業が AWS Organizations でマルチアカウント環境を管理しており、開発・テスト・本番の各環境がそれぞれ異なる OU に整理されています。開発環境では Lambda のデプロイと S3 バケットの作成を自由に行えるようにしたいが、本番環境では承認ワークフローなしにこれらの変更を行えないようにしたいと考えています。また、本番環境での変更はすべて CloudTrail に記録し変更管理システムと統合する必要があります。最も適切なアーキテクチャはどれですか？
- A. IAM パーミッションバウンダリーを本番アカウントの全ロールに設定し、Lambda と S3 の変更 API をバウンダリーから除外する
- B. CloudFormation Stack ポリシーを本番環境のすべてのスタックに設定し、特定のリソースタイプの更新を制限する
- C. 本番 OU に SCP を設定して Lambda と S3 の作成/更新を全面的に Deny し、変更が必要な場合は管理アカウントの管理者が直接対応する
- D. AWS Service Catalog と AWS Config の組み合わせで変更管理を実装し、本番 OU では承認済みの Service Catalog 製品のみデプロイを許可する SCP を設定する。Lambda と S3 の変更は EventBridge と Step Functions を使った承認ワークフローに統合し、承認後に Systems Manager Automation で変更を適用する
解答と解説を見る
正解: D
承認ワークフローを含む変更管理には、Service Catalog と Step Functions を組み合わせた承認フロー統合が適切です。Service Catalog を使って承認済みテンプレートのみデプロイを許可し、SCP でカタログ外のデプロイを防止します。EventBridge で変更イベントを捕捉し Step Functions で承認フローを管理、Systems Manager Automation で承認後に変更を適用する構成が変更管理システムとの統合にも対応できます。 C: 全面的な Deny は業務を停止させてしまい、必要な変更も管理者を介する必要があるため運用負荷が非常に高くなります。 B: CloudFormation スタックポリシーはスタック内のリソース更新を保護しますが、スタック外での直接 API 呼び出しには対応できず、承認ワークフローの機能もありません。 A: パーミッションバウンダリーはロールの権限上限を制御しますが、承認ワークフローの実装や変更管理システムとの統合には対応していません。
📚 関連サービスの解説: AWS Config ・ AWS Organizations