QUESTION

ある企業は、AWS CloudFormation のテンプレートを GitHub のリポジトリで管理しており、開発環境と本番環境のスタックを担当者が手作業で更新しています。同社は、main ブランチへのマージでテンプレートの変更が各スタックに自動的に反映されるようにする必要があります。 運用上のオーバーヘッドを最小限に抑えながら、この要件を満たすソリューションはどれですか。

1 / 1
回答を選択してください
正解A

解説

GitHub で管理する CloudFormation テンプレートの変更を、マージで各スタックに自動的に反映する

  • 1「テンプレートを GitHub のリポジトリで管理」変更の起点は GitHub のリポジトリです。リポジトリを監視できる仕組みが必要です。
  • 2「main ブランチへのマージでテンプレートの変更が各スタックに自動的に反映される」マージを検知して、CloudFormation のスタックを更新する仕組みが必要です。
  • 3「運用上のオーバーヘッドを最小限に抑えながら」パイプラインなどの仕組みを別に作らずに済む方法を選びます。
A正解

開発環境と本番環境のスタックに AWS CloudFormation の Git sync を設定し、GitHub のリポジトリとブランチを連携する。

Git sync は、スタックに連携したリポジトリとブランチを監視し、テンプレートファイルやパラメータを含むスタックデプロイファイルの変更がコミットされると、スタックを自動的に更新します。

ブランチに main を指定すれば、マージで入った変更が各スタックに反映されます。CloudFormation 側がリポジトリを監視するので、パイプラインやビルドの仕組みを別に作って管理する必要はありません。

B不正解

AWS CloudFormation StackSets でスタックセットを作成し、開発環境と本番環境のスタックをスタックインスタンスとしてまとめて管理する。

StackSets は、1 つのテンプレートから複数のアカウントとリージョンにスタックを作成・更新・削除する機能です。1 回の操作で複数のスタックを更新できます。

しかし StackSets は GitHub のリポジトリを監視しません。テンプレートを変更するたびに、担当者がスタックセットを更新する作業が残り、マージで自動的に反映するという要件を満たしません。

C不正解

AWS CodeDeploy のアプリケーションを作成し、GitHub のリポジトリにあるリビジョンを開発環境と本番環境のデプロイグループへデプロイする。

CodeDeploy は、GitHub のリポジトリや Amazon S3 にあるアプリケーションのリビジョンを、EC2 インスタンスなどのコンピューティング先へデプロイするサービスです。

しかし CodeDeploy がデプロイするのはアプリケーションで、CloudFormation のスタックは更新しません。テンプレートの変更をスタックに反映するという要件を満たしません。

D不正解

AWS CloudTrail の証跡を作成し、開発環境と本番環境のスタックを更新する API 呼び出しを記録する。

CloudTrail は、AWS アカウントで行われた API 呼び出しを記録するサービスです。証跡を作成すれば、誰がいつスタックを更新したかを確認できます。

しかし CloudTrail は操作を記録するだけで、スタックを更新しません。テンプレートの変更は各スタックに反映されません。

ポイント

Git のリポジトリから CloudFormation のスタックを自動的に更新する問題では、リポジトリを監視するかと、スタックを更新するかでサービスを見分けます。
・Git sync — スタックに連携したリポジトリとブランチを監視し、テンプレートファイルかパラメータを含むスタックデプロイファイルの変更がコミットされると、スタックを自動的に更新します。
・StackSets — 1 つのテンプレートから複数のアカウントとリージョンへスタックをデプロイします。リポジトリは監視しません。
・CodeDeploy — アプリケーションのリビジョンを EC2 インスタンスなどへデプロイします。スタックは更新しません。
・CloudTrail — API 呼び出しを記録します。