AWSのみで完結する色々なCDパイプラインパターン

はじめに

この記事は AWS Advent Calendar 2020 その2 15日目の記事です。

書いてあること

AWSのみだけでシステムのコード管理とCDを管理したい要望ってそれなりにあると思いませんか？
AWSのエコシステムを最大活用できるのは魅力的です。

そこで、CodeCommitでソースコードを管理して、CodePipelineで開発環境と本番環境へのリリースをハンドリングしたいと思います。
これは色々なパターンで実現できるので、CDパイプラインデザインパターンとして記録しておきます。

前提

- ソースコードは開発環境のCodeCmmitでバージョン管理する
- devブランチのソースコードを開発環境にデプロイする
- masterブランチのソースコードを本番環境にデプロイする
- デプロイはECRへのコンテナイメージ格納までとする

CDパイプラインのパターン

1. 単一アカウントで完結

メリット
・構成が単純でわかりやすい
・多少コストが低い

デメリット
・アカウントのリソースを2環境で食い合う可能性がある
・動作環境、運用環境ともにセキュリティレベルをわけられない

2. 環境でアカウントを分割し、開発環境でパイプラインを動かす（ECRコピー）

メリット
・動作環境はセキュリティレベルをわけられる

デメリット
・開発アカウントのIAMで本番環境用CodePipelineを実行できる（セキュリティレベルをわけられない）
・コピー元の開発アカウントのECRが汚染されると本番アカウントも汚染される

3. 環境でアカウントを分割し、開発環境でパイプラインを動かす（ECR直接）

メリット
・動作環境はセキュリティレベルをわけられる

デメリット
・開発アカウントのIAMで本番環境用CodePipelineを実行できる（セキュリティレベルをわけられない）

4. 環境でアカウントを分割し、本番環境でパイプラインを動かす

メリット
・動作環境、運用環境ともにセキュリティレベルをわけられる

デメリット
・構成が複雑

自動起動のパターン

1. CodePipelineの機能でCodeCmmitの変更をポーリング（AWSは非推奨）

2. CloudWatch Eventsから直接CodePipelineを起動

3. CloudWatch EventsからSNS、Lambda経由でCodePipelineを起動

4. CloudWatch EventsからLambda経由でCodePipelineを起動

【番外編】最近構築したパイプラインパターン

最後に、以下の制約がある中で構築したパイプラインパターンがトリッキーだったので記載しておく。

- CloudWatch Eventsのクロスアカウント連携がNG
- 機能単位でCodeCmmitがわかれていてかつリリース先が複数アカウント