AWS CodePipeline × ECS ネイティブ Blue/Green デプロイ完全ハンズオン（2025年版）

Last updated at 2025-10-16Posted at 2025-10-15

＜まえがき＞

AWSが2025年7月以降にECSネイティブ Blue/Green デプロイに正式対応し、従来のCodeDeployベースの方式から変更されました。Webサイトや動画サイトでの情報が少なく、初学者にはとても分かりずらく、混乱すると思いましたので、私なりにまとめてみました。本記事は2025年版として、最新のECSデプロイ方法に完全に対応しています。参考になればとても嬉しく思います。

🧭 概要

2025年7月以降、AWS CodePipelineはECS ネイティブ Blue/Green デプロイに正式対応しました。

これにより、従来のECS Blue/Greenデプロイで必須だったCodeDeployやその設定ファイルであるappspec.ymlが不要になりました。ECSサービス単体で、よりシンプルな構成で安全なゼロダウンタイムデプロイが可能になっています。

本記事では、以下のデプロイパイプラインを構築し、CodeDeployなしでBlue/Greenデプロイを実現します。

サービス	役割
GitHub	ソースコード管理
CodeBuild	コンテナイメージのビルド、ECRへのPush
CodePipeline	全体のオーケストレーション
ECS (Fargate)	コンテナ実行環境
ALB	トラフィックのBlue/Green切り替え

📘 構築するパイプラインの流れ

CodePipelineのステージ構成は以下の通りです

ステージ	プロバイダ	詳細
Source	GitHub	アプリソースを取得(経由)
Build	CodeBuild	`buildspec.yml`でECRにpushし、`imagedefinitions.json`を出力
Deploy	ECS	ECSクラスターとサービスを指定してBlue/Greenを実行

🧩 前提条件と環境設定

本ハンズオンの前提条件は以下の通りです

項目	説明
AWSアカウント	任意 (`Your-Account-ID`)
リージョン	`ap-northeast-1`（東京）
ECSタイプ	Fargate
ロードバランサー	ALB（ターゲットグループを2つ準備）
デプロイ方法	CodePipeline (ECS Provider)
コンテナレジストリ	Amazon ECR

📁 ディレクトリ構成

以下の3ファイルを作成します。


.
├── Dockerfile
├── index.html
└── buildspec.yml

🐳 コンテナイメージ関連ファイル

🧾 index.html

今回はシンプルなWebサーバーのコンテナをデプロイします。バージョンは5.0とします。

<h1>Hello World! version 5.0</h1>

🐳 Dockerfile

Nginxをベースにindex.htmlを配置するだけのシンプルな構成です。

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html

⚙️ buildspec.yml のポイント

CodeDeployが不要になったため、buildspec.ymlの役割はシンプルになりました。行うのは以下の2点のみです:

Amazon ECRへのDockerイメージのPush
CodePipelineのECS Deployステージが必要とするimagedefinitions.jsonの出力

appspec.ymlやtaskdef.jsonの出力は不要です。

version: 0.2
env:
  variables:
    ECR_REPO_NAME: your-repo-name

phases:
  pre_build:
    commands:
      - echo "Logging in to Amazon ECR..."
      - ECR_MAIN_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"
      # ECRログインコマンド
      - aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ECR_MAIN_URI} [cite: 6]
      - ECR_IMAGE_URI="${ECR_MAIN_URI}/${ECR_REPO_NAME}:latest"

  build:
    commands:
      - echo "Building Docker image..."
      - docker build -t ${ECR_REPO_NAME}:latest .
      
  post_build:
    commands:
      - echo "Pushing image to ECR..."
      - docker tag ${ECR_REPO_NAME}:latest ${ECR_IMAGE_URI}
      - docker push ${ECR_IMAGE_URI}
      - echo "Writing imagedefinitions.json..."
      # ECSデプロイに必須のイメージ定義ファイル
      - printf '[{"name":"your-container-name","imageUri":"%s"}]' ${ECR_IMAGE_URI} > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

🧠 ECS側の設定

ECSサービスを作成する際の設定が非常に重要です。

クラスター名: Your-ECS-Cluster
サービス名: Your-BlueGreen-Service
デプロイ方式: Blue/Green (powered by ECS)
ロードバランサー: ALB（ターゲットグループを2つ指定）
Deployment bake time: 15分（推奨値）

⏰ Deployment bake time の役割

この設定は、トラフィックを新環境（Green）に切り替えた後も、旧環境（Blue）を維持しておく猶予時間です。

新環境に切り替え後も、設定された時間（例: 15分）だけ旧タスクが残ります。
この間にログ・CloudWatchなどで新環境の挙動を本番トラフィックで確認し、問題があれば即座にロールバックできます。
猶予期間（Bake time）が終了し、問題がなければECSが自動的に旧タスクを停止します。

🪄 CodePipeline構成とデプロイ設定

CodePipelineのDeployステージでは、プロバイダとしてECSを選択します。

ECS デプロイステージ設定

設定項目	値
プロバイダー	ECS
入力アーティファクト	`BuildArtifact`（Buildステージの出力）
クラスター名	`Your-ECS-Cluster`
サービス名	`Your-BlueGreen-Service`
イメージ定義ファイル名	`imagedefinitions.json`
Deployment bake time	15（分）

💡 ポイント: ECS新UI/ECSプロバイダでは、「タスク定義ファイル」の指定欄は存在しません。ECSが既存のタスク定義を自動で検出し、imagedefinitions.jsonの内容に基づいて新しいタスク定義を登録・更新します。

🧩 Blue/Green 切替の仕組み

デプロイは以下の流れで実行されます:

新タスク起動: 新タスク（Green）が起動。
トラフィック切替: ヘルスチェックに合格すると ALB のトラフィックがGreenに切り替わります。
ベイクタイム維持: ベイクタイム（例：15分）中は Blue を維持します。
旧タスク停止: 問題なければ ECS が旧タスク（Blue）を停止します。

🔍 新旧バージョンの確認方法

デプロイ中のBlue/Greenの状態は、以下の方法で確認できます

方法	手順
ECSコンソール	サービス →「デプロイ」タブ → PRIMARY=旧 / ACTIVE=新
ALBターゲットグループ	Blue/Green TG のターゲット一覧からIPやタスクを確認
curlで直接確認	各タスクのPrivate IPにアクセスしてバージョンを比較

✅ よくあるエラーと対処法

新しいデプロイ方式で発生しやすいエラーとその対処法をまとめました

エラー	原因	対応
`Did not find the image definition file imagedefinitions.json`	ファイル名不一致	`buildspec.yml`とECS設定を`imagedefinitions.json`で統一
`Exception while trying to read the AppSpec artifact file`	CodeDeployプロバイダを使用	ECSプロバイダに切替
`unable to pull registry auth from Amazon ECR`	NATまたはIAM設定不足	PrivateSubnet → NAT経路設定／`AmazonECSTaskExecutionRolePolicy`確認

📈 メリットまとめ

ECSネイティブ Blue/Green デプロイの主なメリットです

メリット	説明
🚫 ダウンタイムゼロ	Blue/Green切替で無停止更新
🧪 安全性	新環境を本番と同条件でテスト可能
🔄 簡単ロールバック	問題があればBlueへ即戻せる
⚙️ シンプル構成	CodeDeploy不要、ECSだけで完結

🪄 推奨IAMポリシー（CodePipeline実行ロール）

ECSサービスを更新するために、以下のIAMアクションが必要です。

{
  "Effect": "Allow",
  "Action": [
    "ecs:DescribeServices",
    "ecs:DescribeTaskDefinition",
    "ecs:RegisterTaskDefinition",
    "ecs:UpdateService",
    "iam:PassRole"
  ],
  "Resource": "*"
}

🎯 まとめ

✅ ECSネイティブ Blue/Green デプロイでは imagedefinitions.json だけでOKです。
✅ CodeDeploy や appspec.yml は不要となりました。
✅ ベイクタイムを活用して安全に移行・ロールバックが可能です。
✅ ALB + Fargate構成でゼロダウンタイム更新が実現できます。

この新しいデプロイ方式を活用し、皆さんの開発・運用がよりスムーズになることを願っています！

🧩 参考

✍️ Author: Trubo Sato（@hungryclimber）
💬 AWS Fargate / ECS / CodePipeline 実践研究ノート（2025年版）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up