ECS のローリングデプロイの新機能 「Early Success Criteria」を試してみた
はじめに
2026年9月4日、Amazon ECS のローリングデプロイに Early Success Criteria（早期成功条件）が追加されました。
新機能を試すため、検証用の Fargate サービスを用意し、早期成功の判定条件を変えてデプロイの所要時間を確認しました。
検証内容
検証環境
計測に使ったサービスの構成です。
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| クラスター起動タイプ | AWS Fargate |
| コンテナイメージ | public.ecr.aws/nginx/nginx:latest |
| CPU / メモリ | 256 (.25 vCPU) / 512 MiB |
| desired count | 5 |
| ELB / ヘルスチェック | なし |
Early Success Criteria とは
Early Success Criteria を有効にすると、healthyPercent で指定した割合の新しいタスクが健全になった時点でデプロイが完了します。旧リビジョンのタスクをクリーンアップするタイミングは sourceServiceRevisionCleanup で指定します。BLOCKING ではドレインの完了を待ってからデプロイを完了し、DEFERRED ではドレイン待ちをデプロイフローから切り離せます。
healthyPercent を 20% にする場合、デプロイ設定は次の内容になります。
{
"maximumPercent": 200,
"minimumHealthyPercent": 10,
"strategy": "ROLLING",
"earlySuccessCriteria": {
"enable": true,
"healthyPercent": 20,
"sourceServiceRevisionCleanup": "BLOCKING"
}
}
この設定を update-service で適用しました。
aws ecs update-service \
--cluster <クラスター名> \
--service <サービス名> \
--deployment-configuration '{
"maximumPercent": 200,
"minimumHealthyPercent": 10,
"strategy": "ROLLING",
"earlySuccessCriteria": {
"enable": true,
"healthyPercent": 20,
"sourceServiceRevisionCleanup": "BLOCKING"
}
}' \
--region ap-northeast-1
デプロイ時間の計測
healthyPercent を 100% から順に下げていきました。
| パターン | healthyPercent | minimumHealthyPercent | 所要時間 | ベースライン比 |
|---|---|---|---|---|
| ベースライン | 100%（デフォルト） | 50% | 170.0秒（2分50秒） | — |
| Early 60% | 60% | 50% | 123.6秒（2分3秒） | -27% |
| Early 40% | 40% | 30% | 124.7秒（2分4秒） | -27% |
| Early 20% | 20% | 10% | 88.9秒（1分28秒） | -48% |
ロードバランサーなしの構成のため、登録解除のドレイン待ちは所要時間に含まれていません。各パターン1回の計測値です。
最も短くなったのは Early 20% でした。40% と 20% のパターンで minimumHealthyPercent を下げているのは、前述の制約に合わせるためです。
60% と 40% の所要時間の差は約1秒でした。BLOCKING では旧タスクのドレイン待ちが長いため、healthyPercent の差は現れませんでした。
ベースライン、Early 60%、Early 20% の Action Logs に記録されたイベントを確認しました。
まずベースラインです。
| 経過時間 | eventName | statusReason |
|---|---|---|
| 0秒 | SERVICE_DEPLOYMENT_IN_PROGRESS | Service deployment in progress. |
| +25秒 | SERVICE_REVISION_STABLE | Service revision marked stable. |
| +170秒 | SERVICE_DEPLOYMENT_SUCCESSFUL | Service deployment completed successfully. |
Early 60% と Early 40% は所要時間がほぼ一致。statusReason が "met early success criteria." に変わりました。
| 経過時間 | eventName | statusReason |
|---|---|---|
| 0秒 | SERVICE_DEPLOYMENT_IN_PROGRESS | Service deployment in progress. |
| +30秒 | SERVICE_REVISION_STABLE | Service revision marked stable. |
| +124秒 | SERVICE_DEPLOYMENT_SUCCESSFUL | Service deployment met early success criteria. |
Early 20% では、サービスリビジョンが STABLE になるまでの時間が 37秒とやや長くなり、SUCCESSFUL は 89秒で記録されました。
| 経過時間 | eventName | statusReason |
|---|---|---|
| 0秒 | SERVICE_DEPLOYMENT_IN_PROGRESS | Service deployment in progress. |
| +37秒 | SERVICE_REVISION_STABLE | Service revision marked stable. |
| +89秒 | SERVICE_DEPLOYMENT_SUCCESSFUL | Service deployment met early success criteria. |
デプロイ完了時のイベント名は SERVICE_DEPLOYMENT_SUCCESSFUL のままで、変わるのは statusReason の文言です。通常の完了では "Service deployment completed successfully."、早期成功条件の達成による完了では "Service deployment met early success criteria." になります。Action Logs からどちらの経路で完了したかを区別できます。
DEFERRED との組み合わせ
Early 20% の設定で sourceServiceRevisionCleanup を BLOCKING から DEFERRED に変えて計測しました。
| パターン | minimumHealthyPercent | sourceServiceRevisionCleanup | 所要時間 |
|---|---|---|---|
| ベースライン | 50% | — | 170秒 |
| Early 20% BLOCKING | 10% | BLOCKING | 88.9秒 |
| Early 20% DEFERRED | 0% | DEFERRED | 80.3秒 |
ELB の登録解除待ちが発生する構成では、DEFERRED により待機をデプロイ完了の判定から切り離せるため、待ち時間の短縮が期待できます。今回の検証環境には ELB がないため、登録解除の待ち時間は発生せず、BLOCKING との差は約8秒にとどまりました。今回は未検証ですが、ALB で DeregistrationDelay を長く設定する構成では、より大きな差が出る可能性があります。
まとめ
Early Success Criteria を有効にすると、デプロイ完了までの時間は半分近くまで短くなりました。
複数のタスクを稼働させ、一時的なタスク数の減少を許容できる環境では、Early Success Criteria はデプロイ完了待ちを短縮する選択肢になります。特に、デプロイ完了を待つ CI/CD の後続工程を早く進めたい場合に有効です。
ただし、healthyPercent と minimumHealthyPercent を下げすぎると、稼働中のタスク数が不足し、サービスに影響するおそれがあります。
本番環境では、デプロイ待ち時間の短縮と可用性のバランスを見ながら、慎重に設定することをおすすめします。
