【Amazon ECS】組み込みのBlue/Greenデプロイを簡単にためしてみる

はじめに

こんにちは、サービスGの森です。
2025/07/17のアップデートでAmazon ECS(以下、ECS)組み込みのBlue/Greenデプロイが可能になりました。

CodeDeployのドキュメントでも「組み込みのBlue/Greenデプロイ」をお勧めしているくらいですので、今後はこちらのアップデートが活発化しそうです。

そこで、今回は新しいECSの組み込みのBlue/Greenデプロイをサクッと試していきたいと思います。

やりたいこと

Application Load Balancer(以下、ALB)配下のECSサービスでシンプルなアプリケーションを起動させておき、Blue/Greenデプロイによる更新をしたい！

先に結論！

ALBを使用したECS組み込みのBlue/Greenデプロイでやってくれること

• Green環境のサービスの起動 + ターゲットの登録
• Blue環境のサービスの終了 + ターゲットの登録解除（サービス更新の場合）
• リスナールールの重みづけを更新
• デプロイ中のAWS Lambda(以下、Lambda)関数のフック
• サーキットブレーカーによるロールバック
• Amazon CloudWatchアラームによるロールバック

など...

事前準備

極力シンプルな構成で検証をおこないます。

リソース	数量	主要設定要件
Application Load Balancer	1	パブリックサブネットの複数AZ配置
プライマリターゲットグループ（Blue）	1	TargetType: IP
代替ターゲットグループ（Green）	1	TargetType: IP
プロダクションリスナー	1	ポート80
プロダクションリスナールール	1	Blue環境に100%転送 Green環境に0%転送
ECSクラスター	1	-
ECSサービス	1	タスク定義を指定
ECRイメージ（Blue環境用）	1	Blue環境用イメージ
ECRイメージ（Green環境用）	1	Green環境用イメージ
ECSタスク定義（Blue環境用）	1	Blue環境用イメージを指定
ECSタスク定義（Green環境用）	1	Green環境用イメージを指定
ELB管理ロール	1	ELBリソース管理権限
タスク実行ロール	1	ECR、CloudWatch Logs権限
タスクロール	1	タスク固有の権限

Blueターゲットグループにはアクティブなターゲットが1つ、Greenターゲットグループにはターゲット無しの状態です。 リスナールールでは100%のトラフィックをBlueターゲットグループに転送しています。

ターゲットグループ: ecs-test-tg-blueでは、Blue Environmentと表示されるシンプルなサービスをターゲットにしておきます。
こちらをターゲットグループ: ecs-test-tg-greenの、Green Environmentと表示されるサービスに更新していきます。

\

ELB管理ロールとして、ECS ServiceがALBの設定変更をできるIAMロールを用意する必要があります。

• 許可ポリシー: AmazonECSInfrastructureRolePolicyForLoadBalancers ※AWSマネージドポリシー
• 信頼ポリシー: ※下記参照

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Principal": {
                "Service": "ecs.amazonaws.com"
            },
            "Effect": "Allow",
            "Action": "sts:AssumeRole"
        }
    ]
}

---

Blue/Greenデプロイの実行

いよいよBlue/Greenデプロイです。マネジメントコンソールから実施していきます。

1. ECSコンソールから対象の[クラスター] - [サービス]をクリックします。

2. [サービスを更新]をクリックします。

3. デプロイ設定を入力します。

設定項目	設定値	説明
新しいデプロイの強制	有効	-
タスク定義ファミリー	flask-test-app	Green環境のタスク定義
タスク定義のリビジョン	6	Green環境のタスク定義のリビジョン
デプロイ戦略	ブルー/グリーン	-
ベイク時間	5(分)	Greenサービス作成後、Blueサービスを終了させるまでの待機時間
デプロイライフサイクルフック - オプション	未設定	デプロイ時のテスト等を実行するLambda関数を指定可能
Amazon ECS デプロイサーキットブレーカーを使用する	有効	デプロイの失敗を検知する
失敗時のロールバック	有効	サーキットブレーカーでデプロイの失敗を検知した場合、Blue環境にロールバックする
CloudWatch アラームを使用	無効	設定したCloudWatchアラームの状態がALARMの時にロールバック可能

4. ロードバランシングを設定します。

設定項目	設定値	説明
ロードバランシングを使用	有効	-
VPC	既存のVPC	-
ロール	事前準備で作成したIAMロール	-
ロードバランサーの種類	Application Load Balancer	-
コンテナ	既存のコンテナ	-
ロードバランサー	既存のロードバランサー	-
リスナー	既存のリスナー	更新対象のリスナー
本番リスナールール	優先度: default	トラフィックをGreenターゲットに向けて移行するリスナールール
テストリスナー - オプション	未設定	トラフィックをGreenターゲットに向けてテストするリスナー
テストリスナールール - オプション、推奨	未設定	トラフィックをGreenターゲットに向けてテストするリスナールール
オプション	2 つの既存のターゲットグループを使用	新規作成も可能
ターゲットグループ	ecs-test-tg-blue	Blueターゲットグループ
代替ターゲットグループ	ecs-test-tg-green	Greenターゲットグループ

5. [更新]をクリックします。

Blue/Greenデプロイの実行中の挙動

1. Green環境のタスクが起動し、一時的に2つのタスクが起動している状態になります。

2. Green環境のタスクが起動後、すぐにリスナールールが書き換えられました。

• Blue環境のターゲットグループへのトラフィック: 100%→0%
• Green環境のターゲットグループへのトラフィック: 0%→100%

3. ウェブブラウザではGreen Environmentと表示され、Greenターゲットにルーティングされていることが確認できます。

4. Green環境の起動からベイク時間の5分経過後、Blue環境のタスクが自動削除されました。

5. ALBのリソースマップから、リスナールールとターゲットグループの関連付けが更新されたことが確認できます。

気づいたこと①

AWS CodeDeploy(以下、CodeDeploy)のLinearデプロイやCanaryデプロイと違い、少しずつ新環境にトラフィックを移行する事はできません。一度にすべてのトラフィックを移行する仕様となっています。

Lambda関数をフックしたり、別のターゲットグループに切り戻すといった用途に適しているため、「十分にテストコードを用意できているが、もしもの時にはすぐにロールバックしたい」という要件に適しているように思います。

これらはCodeDeployからの移行を考える際にネックになりそうですが、今後のアップデートに期待です。

気づいたこと②

ベイク時間の上限が1日（1,440分）となっており、1日以上のBlue環境の存続が出来ません。

しかしサービスの更新(UpdateService)ではなく、サービスの作成(CreateService)によりBlue/Greenデプロイを実行した場合、Blue環境のサービスは自動削除されません。

1日以上のテストを実施した後、リスナールール更新とBlueサービスの削除を行うことでアプリの更新が可能です。

これらをスクリプト化しておくと、1日以上のテスト+複数サービスの同時アップデートが必要な場合にも、ある程度コントロールできそうです。かなり力技ですが。

気づいたこと③

コンソール上に「ブルー/グリーンデプロイでは、ロードバランシングおよび/または Service Connect を設定することをお勧めします」とありますが...

実際は「お勧め」ではなく「必須」の設定です。同一画面上で矛盾した説明になってました。

おわりに

この記事がどなたかのお役に立てれば幸いです。

この記事は私が書きました

森 翔吾

記事一覧

最近はコンテナ・サーバレスを学習しています。 よろしくお願いします。