はじめに
2025 年 10 月 30 日、AWS は Amazon Elastic Container Service（ECS）向けの新機能を発表しました。
ECS でリニア（段階的）と Canary（カナリア）デプロイ戦略がビルトインサポートされ、アプリケーションのリスクプロファイルや検証要件に応じて、より柔軟なトラフィック移行戦略を選択できるようになりました。
この機能は Amazon ECS が利用可能な全 AWS 商用リージョンで即座に利用可能となっています。
本記事では、新機能の詳細、従来との違い、実際の使い方、デプロイ戦略の選び方、ベストプラクティス、コストや制限事項についてまとめています。
新機能の概要
今回発表された新機能により、ECS のデプロイ戦略が拡充されました。
主な特徴
主な特徴としては以下の 2 つです。
- リニアと Canary デプロイのビルトインサポート
- CloudWatch Alarms との連携による自動ロールバック
リニアと Canary デプロイのビルトインサポート
ECS がリニアと Canary デプロイ戦略をネイティブでサポートするようになりました。
ECS コンソール、SDK、CLI、CloudFormation、CDK、Terraform から直接設定でき、CodeDeploy の追加設定は不要です。
CloudWatch Alarms との連携による自動ロールバック
CloudWatch Alarms と統合し、メトリクス異常時の自動ロールバックに対応しています。
デプロイライフサイクルフックを使用したカスタム検証も可能です。
対応リソース
リニアおよび Canary デプロイは、以下のリソースで利用可能です。
- Application Load Balancer（ALB）を使用する ECS サービス
- ECS Service Connect を使用する ECS サービス
何が変わったのか
今回発表された新機能により、ECS のデプロイ戦略が大きく変わりました。
従来の課題と新機能による変化を見ていきましょう。
従来の課題
主な課題としては以下の 3 つがありました。
- CodeDeploy の追加設定が必要
- 複数コンソール間の管理
- インフラ構成の複雑化
CodeDeploy の追加設定が必要
段階的デプロイを実現するには、AWS CodeDeploy を別途設定する必要があり、以下の手順が必要でした。
- CodeDeploy アプリケーションとデプロイメントグループの作成
- 適切な IAM ロールとポリシーの構成
- ターゲットグループの設定
複数コンソール間の管理
デプロイの監視や管理に、ECS コンソール → CodeDeploy コンソールと複数コンソール間の移動が発生していました。
デプロイ状態の一元的な把握が困難で、トラブルシューティング時の効率が低下していました。
インフラ構成の複雑化
ECS、CodeDeploy など複数のサービスを連携させる必要があり、Infrastructure as Code（IaC）の定義が複雑になっていました。
特に Terraform や CloudFormation での管理が煩雑で、保守性が低下していました。
新機能による変化
新機能により、従来の課題がすべて解決されました。
設定の簡素化
CodeDeploy アプリケーション、デプロイメントグループなどの追加設定が不要になりました。
ECS サービスの作成・更新時にデプロイ戦略を選択するだけで、段階的デプロイを実現できます。
ECS コンソール内で完結
デプロイ戦略の設定から監視まで、すべて ECS コンソール内で完結します。
CodeDeploy コンソールへの移動が不要になり、運用が大幅に簡素化されました。
Infrastructure as Code の簡素化
ECS サービス定義にデプロイ戦略を直接記述できるようになりました。
CloudFormation、CDK、Terraform での管理がシンプルになり、コードの可読性と保守性が向上します。
使い方
新機能の使い方を設定手順と設定項目を中心に説明します。
デプロイ戦略の設定
- ECS コンソールでサービス作成/更新画面を開く
- 「デプロイ設定」セクションに移動
- 「デプロイオプション」>「デプロイ戦略」でデプロイ戦略を選択
Canary デプロイの設定項目
デプロイ戦略で「Canary」を選択すると、以下のパラメータを設定できます。
Canary パーセント
初期カナリアフェーズで新バージョンに流すトラフィックの割合（0.1 ~ 100）を指定します。
例えば、10 を設定すると最初に 10% のトラフィックのみが新バージョンへ流れます。
Canary ベイク時間
カナリアフェーズの検証期間を分単位（0 ~ 1,440）で指定します。
この期間中に問題がなければ、残りのトラフィックを一度に移行します。
デプロイベイク時間
全トラフィック移行後の最終検証期間を分単位（0 ~ 1,440）で指定します。
この期間中は旧バージョンを保持し、問題が検出されれば迅速なロールバックが可能です。
リニアデプロイの設定項目
デプロイ戦略で「リニア」を選択すると、以下のパラメータを設定できます。
リニアステップ割合
リニアデプロイ戦略における各デプロイ間隔で置き換えるタスクの割合（3 ~ 100）を指定します。
例えば、10 を設定するとトラフィックは 10%、20%、30% と段階的に移行し、100% に達するまで続きます。
リニアステップベイク時間
デプロイステップ間の一時停止時間を分単位（0 ~ 1,440）で指定します。
これにより、次のトラフィック増加へ進む前にパフォーマンスと健全性を監視する時間が確保されます。
デプロイベイク時間
全トラフィック移行後の最終検証期間を分単位（0 ~ 1,440）で指定します。
この期間中は旧バージョンを保持し、問題が検出されれば迅速なロールバックが可能です。
デプロイ戦略の選び方
新機能により、4 つのデプロイ戦略から選択できるようになりました。
アプリケーションの特性に応じて、最適なデプロイ戦略を選択できます。
デプロイ戦略の詳細
ローリングアップデート
タスクを 1 つずつ置き換え、以前のバージョンから新しいバージョンに更新します。
最もシンプルなデプロイ方式で、追加のインフラは不要です。
トラフィックの段階的な制御はできませんが、設定が簡単で迅速なデプロイが可能です。
ブルー/グリーンデプロイ
青 (現行) バージョンと緑 (新規) バージョンで並列環境を実行し、すべてのトラフィックを一度に移行します。
十分にテストされた更新や、即座の切り替えが必要な場合に適しています。
Canary デプロイ
トラフィックを 2 段階に分けて新しいバージョンに移行します。
最初はテスト用に指定された割合だけ移行し、その後に残りを移行します。
ミッションクリティカルなシステムや、大規模なトラフィックを扱うアプリケーションに適しています。
リニアデプロイ
指定した割合ずつ段階的にトラフィックを移行します。
段階的な負荷テストや、複数回の検証が必要な場合に適しています。
デプロイ戦略の比較
| 戦略 | トラフィック移行 | 検証段階 | デプロイ時間 |
|---|---|---|---|
| ローリングアップデート | タスクの順次置き換え | - | 短 |
| ブルー/グリーン | 一度に 100% 切り替え | 1 回 | 短 |
| リニア | 段階的に均等増加 | 複数回 | 長 |
| Canary | 少量 → 残り全て | 2 回 | 中 |
戦略選択のガイドライン
以下のアプリケーション特性を参考に、最適な戦略を選択してください。
ローリングアップデートを選ぶべき場合
- シンプルなデプロイで十分な場合
- ALB や Service Connect を使用していない環境
- トラフィック制御が不要な変更
- 小規模なアプリケーションや内部向けサービス
ブルー/グリーンデプロイを選ぶべき場合
- 十分にテストされた更新で信頼性が高い場合
- 即座の切り替えが必要な場合
- 迅速なロールバック機能は欲しいが、段階的検証は不要な場合
- ローリングアップデートより安全性を高めたいが、全ユーザーへの即時展開で問題ない場合
リニアデプロイを選ぶ場合
- 段階的な負荷テストが必要な場合
- 複数段階での詳細な検証が必要な場合
- パフォーマンスへの影響を段階的に確認したい場合
- 長時間のモニタリングが必要な変更
- 各段階で異なるメトリクスを確認したい場合
Canary デプロイを選ぶべき場合
- ミッションクリティカルなシステム（決済、認証など）で、問題検知前の影響を最小化したい
- 大規模トラフィックを扱うアプリケーションで、少数のユーザーで初期検証したい
- ダウンタイムが許されない本番環境
- 新機能の影響範囲が不確実な場合
- ビジネスへの影響が大きい変更で、慎重な展開が必要な場合
ベストプラクティス
実運用で新機能を活用する際の推奨事項について説明します。
トラフィック割合の選択
Canary デプロイでは、以下を考慮してトラフィック割合を決定してください。
- 少量から開始：問題発生時の影響を最小化するため、5 ~ 10% のトラフィックから開始
- アプリケーションの重要度：ミッションクリティカルなアプリケーションでは、より小さい割合を使用
- トラフィック量：Canary パーセントで十分な検証データを収集できるトラフィック量を確保
ベイク時間の設定
ベイク時間は以下を考慮して設定してください。
- 十分な時間を確保：通常 10 ~ 30 分程度のベイク時間を設定し、有意なパフォーマンスデータを収集
- トラフィックパターンの考慮：アプリケーションのトラフィックパターンやピーク時間を考慮
- 速度と安全性のバランス：長いベイク時間はより多くのデータを提供しますが、デプロイ速度は低下
監視するメトリクスの選択
デプロイ中は以下のメトリクスを監視してください。
- レスポンスタイム、エラー率、スループット：新旧両方のタスクセットで監視
- リソース使用率：CPU、メモリ使用率を監視
- ビジネスメトリクス：コンバージョン率やユーザーエンゲージメントなどのビジネス固有のメトリクス
CloudWatch Alarms の設定
メトリクス異常時の自動ロールバックを実現するために、CloudWatch Alarms を設定してください。
メトリクスが閾値を超えたときに自動的にロールバックがトリガーされるようにします。
ダッシュボードでの比較分析
新旧バージョンのメトリクスを並べて比較できるダッシュボードを設定してください。
両バージョンのパフォーマンスを視覚的に比較することで、問題を早期に発見できます。
コストと制限事項
新機能を利用する前に知っておくべきコストと制限事項について説明します。
料金体系
リニア/Canary デプロイ機能自体に追加料金は発生しません。
ただし、デプロイ中は旧バージョンと新バージョンのタスクが並行稼働するため、一時的にリソース使用量が増加します。
コスト構成要素
- ECS/Fargate タスク：デプロイ中は最大 2 倍のタスク数が稼働
- ALB：トラフィック増加による転送量課金（通常は微増）
- CloudWatch Alarms：アラーム数に応じた課金（$0.10/アラーム/月）
- CloudWatch Logs：アプリケーションログの増加（該当する場合）
コスト最適化のポイント
- ベイク時間の最適化：過度に長い待機時間は避け、必要十分な時間に設定する
- タスク数の適切な設定：必要最小限のタスク数で運用する
制限事項
機能面の制限
- Application Load Balancer（ALB） または ECS Service Connect を使用する ECS サービスのみ対応
- デプロイコントローラーが ECS である必要あり
運用上の注意点
- デプロイ中は旧・新バージョンのタスクが並行稼働し、リソース使用量が最大 2 倍
- 同一サービスでの複数デプロイの同時実行不可
- デプロイ中は手動でのタスク数変更を避ける
- 各ライフサイクルステージは最大 24 時間、CloudFormation デプロイ全体は 36 時間の制限
まとめ
今回発表された新機能により、ECS のデプロイ管理が大きく改善されました。
ECS ネイティブでリニア/Canary デプロイ戦略が利用可能になり、CodeDeploy の追加設定なしで段階的なデプロイを実現できるようになりました。
アプリケーションのリスクプロファイルに応じて、ローリングアップデート、ブルー/グリーン、Canary、リニアから最適な戦略を選択できます。
機能自体に追加料金はなく、デプロイ中の一時的なリソース増加のみがコストとなります。
まずは非本番環境で各デプロイ戦略を試し、自身のアプリケーション特性に最適な戦略を見つけることをお勧めします。
参考リンク
https://aws.amazon.com/jp/about-aws/whats-new/2025/10/amazon-ecs-built-in-linear-canary-deployments/
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/canary-deployment.html
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deployment-type-linear.html