本ページでは、Amazon ECS (Fargate) 上のWebサービスをBlue/Greenデプロイで運用する構成について、 AWSサービスの特性と配置意図、設計上の制約と対処を概要レベルで解説する。 CodeDeploy標準構成の特徴と制約を整理した上で、承認制御の柔軟化やインフラ管理とデプロイの責務分離といった 本構成での設計判断を紹介する。
ページ構成
- CodeDeploy ECS Blue/Green の標準構成
- 標準構成と本構成の俯瞰
- 本構成の設計判断
- 本構成での運用フロー
- まとめ
1. CodeDeploy ECS Blue/Green の標準構成
CodeDeploy + ECS Blue/Green を選択する意味
ECS (Fargate) 上のWebサービスをBlue/Greenでデプロイする方法として、AWS CodeDeployによるネイティブサポートがある。 CodeDeployはALB・ECSの各サービスをオーケストレーションし、リスナー切替・タスクセット管理・ロールバックを一体的に制御する。 この選択にはトレードオフがある。
得られるもの
- コンテナ運用の簡素化: ALBリスナー切替、ターゲットグループ管理、タスクセットの入れ替え、ロールバックをCodeDeployが一括で制御する。個別にALBとECSを操作する必要がない
- 無停止デプロイ: ALBリスナーレベルでの切替のため、エンドユーザーへの影響なくバージョンを移行できる
- 本番環境上での事前確認: Previewリスナーにより、本番と同一の環境・データで新バージョンを検証できる。従来dev/stg/prodの3面で段階的に検証していた運用を、stg/prodの2面に集約できる可能性がある（Previewリスナーでの確認をstg相当の検証として扱う運用方針が前提）
- 自動ロールバック: ヘルスチェック失敗やアラーム発火時に自動で旧バージョンに戻せる
- 切替方式の選択: AllAtOnce（即時）、Linear（段階的）、Canary（少量先行）から選択可能
引き換えに受け入れるもの
- AWSベンダーロックイン: ECSはAWS固有のコンテナオーケストレーターであり、Kubernetesベース（EKS）のようなポータビリティはない。CodeDeployもAWS固有のデプロイサービスである
- CodeDeployの制約を受ける: ALBとECSを個別に操作する場合と比べ、CodeDeployのオーケストレーションに従う必要がある。承認制御の柔軟性、デプロイ中のリソース操作、設定変更の反映タイミングなどに制限が生じる
- 抽象化による見通しの低下: CodeDeployがALB・ECSの操作を隠蔽するため、デプロイ中に何が起きているかの把握にはCodeDeployの仕様理解が必要になる
デプロイの基本的な仕組み
CodeDeployによるECS Blue/Greenデプロイでは、ALBのリスナーとターゲットグループの切替によってトラフィック移行を行う。 現行バージョンが稼働するターゲットグループ（Blue）とは別に、新バージョン用のターゲットグループ（Green）を用意し、 CodeDeployがALBリスナーの向き先を切り替えることで無停止デプロイを実現する。
- 新バージョンのデプロイ: 新しいタスク定義に基づくタスクセットがGreen側のターゲットグループに配置される
- プレビュー確認: Previewリスナー経由で新バージョンへの疎通・動作確認が可能になる
- トラフィック切替: Activeリスナーのターゲットを Blue → Green に切り替え、本番トラフィックが新バージョンに流れる
- 旧バージョンの停止: 一定の待機時間後、旧タスクセット（Blue側）が停止される
なお、EC2やオンプレミスを対象としたCodeDeploy Blue/Greenでは、インスタンスの入れ替えによってデプロイを行う。 ECSの場合はインスタンスではなくALBターゲットグループの切替が単位となる点が異なる。
標準構成で使用するAWSリソース
| AWSサービス | 役割 |
|---|---|
| ALB | Active/Previewの2リスナーとBlue/Greenの2ターゲットグループを持ち、CodeDeployがリスナーの向き先を切り替えることでトラフィックを移行する |
| ECS Fargate | コンテナ化されたWebサービスの実行基盤。CodeDeploy管理下でタスクセットの入れ替えが行われる |
| CodeDeploy | Blue/Greenデプロイの本体。ALBリスナー切替、タスクセット管理、ロールバックを制御する |
| ECR | ビルド済みコンテナイメージの保管先。デプロイ時に最新イメージを取得する |
| CloudWatch Alarm | ECS/ALBのメトリクス監視。CodeDeployの自動ロールバック判定にも利用される |
| Cloud Map | Private DNSによるサービス登録（オプション） |
2. 標準構成と本構成の俯瞰
本構成で追加しているリソース
標準構成に対して、本構成では以下のリソースを追加している。それぞれの追加理由を後続のセクションで詳述する。
| AWSサービス | 追加理由 |
|---|---|
| CodeBuild | 外部CIからトリガーされ、本番用タスク定義を動的に組み立てる。タスク定義の更新をインフラ管理から分離し、CI/CDに寄せるために使用している |
| Secrets Manager | アプリケーションの環境変数・シークレットとデプロイ用パラメータの管理に使用。AWSコンソール上のJSON編集GUIにより、運用担当者がインフラ管理を介さずに値を変更できる（詳細はセクション3） |
| SSM Parameter Store | コンテナイメージタグの受け渡しに使用。CI（イメージビルド）とCD（デプロイ）を疎結合にするために追加している |
| S3 | デプロイスクリプトの配置先。複数のアプリケーションから共通のデプロイ手順を参照できるようにするために追加している |
| Step Functions | CodeDeployの承認制御には「自動/手動をデプロイごとに切り替えられない」という制約がある。Step FunctionsでCodeDeployをラッピングし、実行時パラメータで承認方式を動的に分岐させるために追加している（詳細はセクション3） |
標準構成の図と比較すると、以下の差分が見える。
- CI/CD層: 外部CIがCodeDeployを直接呼ぶのではなく、CodeBuild Runnerがタスク定義を組み立てた上でStep Functionsを起動する
- デプロイ制御層: CodeDeployの前段にStep Functionsが入り、承認制御を柔軟化している
- パラメータ管理: Secrets ManagerとECRからCodeBuild Runnerが値を収集し、タスク定義を動的に組み立てる
3. 本構成の設計判断
本構成では、CodeDeploy標準構成の2つの制約に対して、追加のAWSサービスで対処している。
承認制御の柔軟化（Step Functions）
CodeDeploy標準の制約
CodeDeployのDeployment Groupでは、デプロイがREADY状態（新バージョンがPreviewリスナーで確認可能な状態）に到達した際の挙動として、 「自動的に切替を続行する」か「手動承認を待つ」かを設定できる。 しかし、この設定はDeployment Groupに固定されており、デプロイ実行ごとに動的に切り替えることができない。 タイムアウト時の挙動も同様に固定される。
本構成での対処
Step FunctionsでCodeDeployをラッピングし、以下の責任切り分けを実現している。
- インフラ管理の責任: Deployment Groupのタイムアウト時挙動を常に「停止（ロールバック）」に固定。承認設定は手動承認待ちに固定し、実際の承認制御はStep Functionsに委ねる
- 運用担当の責任: デプロイ実行時にStep Functionsへの入力パラメータで承認方式を選択する。通常デプロイは自動承認、重要リリースは手動承認
Step Functionsのオーケストレーションフローは以下の通りである。
- デプロイ起動: CodeDeployのデプロイを開始する
- READY待ち: 新バージョンがPreviewリスナーで確認可能になるまで待機する
- 承認判定: 実行時パラメータに基づき、自動承認か手動承認かを分岐する
- 切替続行: 承認後、トラフィック切替を続行する
この設計により、インフラ管理で定義したDeployment Groupの設定を変更することなく、運用担当がデプロイごとに承認方式を柔軟に切り替えられる。
設定値管理の分離（Secrets Manager）
ECSタスク定義の2つの指定方式
ECS Fargateでは、コンテナの環境変数はタスク定義に含まれる。 タスク定義はイミュータブルであり、一度登録されたリビジョンの内容は変更できない。 環境変数の指定方式には2種類ある。
- Value（値の直接埋め込み）: 環境変数の値がタスク定義リビジョンに直接記録される。値を変更するには、新しいタスク定義リビジョンを作成して再デプロイする必要がある
- ValueFrom（ARN参照）: タスク定義にはSecrets ManagerのARNだけが記録され、実際の値はコンテナ起動時に解決される。ARN参照先の値を変更した場合、タスク定義の新規作成は不要であり、既存のタスク定義のまま再デプロイすれば新しいタスクが最新の値を取得する
この違いは、値の変更時にタスク定義リビジョンの新規作成が必要かどうかを決定する。 ValueFromを使用すれば、値の変更のたびに無駄なタスク定義リビジョンが増えることを避けられる。
Terraformとの制約
インフラ管理にTerraformを使用する場合、もう一つの制約が加わる。
Terraformで管理する値はtfstate（状態ファイル）やplan/applyログに平文で記録される。
APIキーやパスワードなどの機密値をTerraformで直接管理すると、これらの経路から流出するリスクがある。
一方で、Terraformの lifecycle { ignore_changes } を使えば、リソース（箱）の作成だけをTerraformが行い、値の変更はTerraformの管理外に置くことができる。
3系統の分類
上記のECSとTerraformの制約を組み合わせると、環境変数・シークレットは以下の3系統に分類される。 本構成ではSecrets Managerを使用してこの3系統を実現している。 SSM Parameter Storeではなく Secrets Managerを選択した理由は、AWSコンソール上にキーバリュー形式のJSON編集GUIが用意されており、 運用担当者がブラウザから直感的に値を確認・編集できる点にある。
| 系統 | タスク定義での指定 | 値の管理者 | Terraformの扱い | 値変更時のタスク定義 |
|---|---|---|---|---|
| インフラ管理値 | Value（値の埋め込み） | インフラ管理 | 箱も値も管理 | 新規作成が必要 |
| 運用設定値（非機密） | Value（値の埋め込み） | 運用担当者 | 箱だけ作成（ignore_changes） | 新規作成が必要 |
| 機密値 | ValueFrom（ARN参照） | 運用担当者 | ARN文字列のみ管理（実値はignore_changes） | 不要（再デプロイのみ） |
責務分離の成立
この3系統の使い分けにより、以下の責任切り分けが成立する。
- インフラ管理の責任: Secrets Managerリソース（箱）の作成と、インフラ管理値の維持。運用設定値・機密値の実値は管理しない。Terraformのignore_changesにより、運用担当者の値変更がTerraformの差分として検出されない設計とする
- CI/CDの責任: 本番用タスク定義を動的に組み立てる。Secrets Managerから最新値を取得し、コンテナイメージとともに新しいタスク定義に組み込む
- 運用担当の責任: 運用設定値と機密値をSecrets ManagerのGUIで管理する。特に機密値の変更はタスク定義の新規作成が不要であり、再デプロイだけで反映される。インフラ管理の変更は不要
この分離により、運用担当はインフラ管理を介さずに環境変数・シークレットの変更とデプロイを完結できる。 同時に、機密値がTerraformのtfstateやログに記録されることを防ぎ、セキュリティ上の安全性も確保している。
4. 本構成での運用フロー
初期構築から運用デプロイまでの全体フローは、3つのフェーズに分かれる。各フェーズの責任主体が異なる。
フェーズ1: 初期構築（インフラ管理の責任）
インフラ管理が以下を作成する。
- 最小構成のタスク定義（起動確認用）
- ECSクラスタ / サービス
- ALBリスナー（Active / Preview）とターゲットグループ（Blue / Green）
- CodeDeployアプリケーション / デプロイメントグループ
- Step Functionsステートマシン
- デプロイ用パラメータ（Secrets Manager）
- デプロイスクリプト（S3）
このフェーズの目的は、サービスの起動を先に成立させることにある。初期タスク定義は最小構成であり、本番運用で使用するものとは異なる。
フェーズ2: CI/CDによるタスク定義更新（CI/CD / 運用担当の責任）
運用担当がCI/CDパイプラインをトリガーし、以下が実行される。
- コンテナイメージの取得
- 環境変数・シークレット・デプロイ用パラメータの収集
- 新しいタスク定義の組み立てと登録
- Step Functionsオーケストレーターの起動
CI/CDはCodeDeployを直接呼び出さず、Step Functionsを起動する。これにより、デプロイの承認制御がStep Functions側に集約される。
フェーズ3: Blue/Green切替（Step Functions / CodeDeployの責任）
Step Functionsが以下のフローを自動実行する。
- CodeDeployデプロイの起動
- READY状態の待機
- 承認判定（自動承認 or 手動承認待ち — 運用担当が実行時に選択）
- トラフィック切替の続行
- 旧タスクセットの停止
5. まとめ
標準構成と本構成の対比
| 観点 | CodeDeploy標準構成 | 本構成での拡張 |
|---|---|---|
| 承認制御 | Deployment Groupに固定（自動 or 手動） | Step Functionsで実行時に動的切替 |
| タスク定義の更新 | 手動またはCI/CDで直接登録 | CI/CDが動的に組み立て、インフラ管理とは分離 |
| デプロイ起動 | CodeDeployを直接呼び出し | CI/CD → Step Functions → CodeDeploy の経路 |
| 設定値の管理 | 任意の方法 | Secrets Manager + SSM Parameter Store で集約 |
| デプロイスクリプト | 各リポジトリに配置 | 共通ストレージに配置し、複数アプリケーションから参照 |
責任切り分けの全体像
| 責任主体 | 担当範囲 |
|---|---|
| インフラ管理 | インフラの初期構築と状態管理。Deployment Groupの安全設定（タイムアウト時停止）の固定。シークレットリソース（箱）の作成 |
| CI/CD | 本番用タスク定義の動的組み立て。イメージ・環境変数・シークレット・デプロイパラメータの収集と統合 |
| 運用担当 | シークレット値の管理（インフラ管理の変更不要）、CI/CDパイプラインのトリガー、デプロイ時の承認方式選択 |
| Step Functions | デプロイのオーケストレーション。承認方式の動的分岐、通知、切替続行の実行 |
| CodeDeploy | ALBリスナー切替、タスクセット管理、ロールバック |
設計判断の要約
本構成は、CodeDeploy ECS Blue/Greenの標準機能を基盤としつつ、運用上の制約に対して追加のAWSサービスで対処する設計をとっている。
- 承認制御の柔軟化: CodeDeployの承認モード固定制約をStep Functionsで吸収し、インフラ管理の設定変更なしにデプロイごとの承認方式切替を実現した
- 設定反映の明示化: 環境変数・シークレットの変更は再デプロイでのみ反映されることを前提とし、Secrets ManagerのGUIによる運用担当の直接管理とCI/CDによる反映を組み合わせた
- 責務の分離: インフラ管理（初期構築・状態管理）、CI/CD（タスク定義更新）、Step Functions（デプロイ制御）、運用担当（設定値管理・デプロイ判断）の責任境界を明確にした
これらの設計判断は、CodeDeployの制約を回避するためだけでなく、インフラ管理と運用の責任を分離し、 運用担当がインフラ管理を介さずにデプロイと設定変更を完結できる構成を目指したものである。