ECSサービスの更新画面で目にする「新しいデプロイの強制(Force new deployment)」オプション。タスク定義を変えていないのになぜ必要なのか、疑問に思ったことはありませんか?
この記事では、Dockerイメージタグとダイジェストの関係から、ローリングアップデートの仕組み、安全な本番運用のベストプラクティスまでわかりやすく解説します。
AWSのECSを使い始めた方から、CI/CDパイプラインを整備したい方まで、ぜひ参考にしてください。
Force new deployment とは
AWS ECSのサービス更新画面にある「Force new deployment(新しいデプロイの強制)」は、タスク定義のリビジョンを変更しなくても、強制的に新しいデプロイを開始させるオプションです。

通常、ECSサービスは「タスク定義が変更された場合」にのみ新しいデプロイを実行します。そのため、タスク定義はそのままにイメージだけ更新したいケースでは、このオプションを使わないとECSは何も変更を検知できず、デプロイが走りません。
「タスク定義に変更がなくても、新しいタスクを起動して古いタスクと入れ替える」操作が Force new deployment です。
タスク入れ替えの仕組み(ローリングアップデート)
Force new deployment を実行すると、ECSはローリングアップデートの手順でタスクを順次入れ替えます。古いタスクはすべて最終的に停止・削除されます。以下は desiredCount: 2 の場合の流れです。

ローリングアップデート中は一時的にタスク数が増えます(デフォルト: maximumPercent=200%)。本番環境では事前に maximumPercent / minimumHealthyPercent の値を確認し、クラスターに十分なキャパシティがあることを確かめてから実行してください。
使いどころ3パターン
Force new deployment が役立つ代表的なシーンは以下の3つです。
- 同じイメージタグで Docker イメージを更新した場合:
:latestなど同じタグのまま ECR に新しいイメージを push した場合、ECSはタスク定義の変更を検知できません。Force new deployment を使うことで、ECSが改めて ECR からイメージを pull し直します。 - タスクが異常な状態(クラッシュループ等)になった場合:
タスクがクラッシュを繰り返していたり、ヘルスチェックが通らない状態が続く場合に、強制的にタスクを入れ替えてリセットする目的で使います。 - Fargate の基盤更新通知が来た場合:
AWSから「Fargateのプラットフォームバージョンを更新してください」という通知が届いた際に、Force new deployment でタスクを再起動することで基盤の更新を適用できます。
「同じタグで中身が変わる」はなぜ起こる?
Dockerイメージの実体を識別するのはタグ(ラベル)ではなく、イメージダイジェスト(sha256ハッシュ)です。タグはポインタに過ぎないため、同じ :latest タグが別の sha256 を指すことは普通に起こります。
# 1回目のビルド
myapp:latest → sha256:aaa111bbb222...
# コードを修正して再 build & push
myapp:latest → sha256:ccc333ddd444... # ← タグは同じでも別物!ECSのタスク定義に記録されるのはタグ文字列だけです。そのため、タグが同じであれば ECS は「変更なし」と判断し、通常の Update では何も起きません。
{
"image": "123456789.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest"
}
// タグ文字列が同じ → ECS は "変更なし" と判断
// → 通常の Update では何も起きない
// → Force new deployment で再 pull させる必要があるAWSドキュメントより:ECSはデプロイ時に最初のタスク起動を使ってイメージダイジェストを確立します。Force new deployment を使うと、更新されたダイジェストを新しいタスクの起動に使用できます。
通常の ECS サービス Update との比較
ここでの「通常の Update」とは、AWSコンソールの ECS サービス → 「更新(Update service)」画面から Force new deployment にチェックを入れずに更新を実行する操作を指します。

AWS CLI / コンソールでの実行方法
コンソールから実行する場合は、ECS サービス → 「更新」 → Deployment configuration の「Force new deployment」にチェックを入れて「更新を保存」をクリックします。
AWS CLI から実行する場合は以下のコマンドを使います。
aws ecs update-service
--cluster my-cluster
--service my-service
--force-new-deploymentPython(boto3)から実行する場合は以下のコードを使います。
import boto3
client = boto3.client('ecs')
client.update_service(
cluster='my-cluster',
service='my-service',
forceNewDeployment=True
)本番環境でのベストプラクティス
:latest タグ運用は「どのコードが動いているか追跡しにくい」という問題があります。CI/CDパイプラインでは、コミットSHAやバージョン番号をタグにする運用が推奨されます。
# コミット SHA をイメージタグにする
IMAGE_TAG=$(git rev-parse --short HEAD)
docker build -t myapp:${IMAGE_TAG} .
docker push 123456789.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:${IMAGE_TAG}
# タスク定義も毎回新リビジョンで更新
# → Force new deployment なしで自動デプロイが走る
# → どのコードがデプロイされているか追跡可能SHA タグ運用に切り替えると、以下のメリットが得られます。
- タスク定義のリビジョンが変わるたびに自動でデプロイが走り、Force new deployment が不要になる
- デプロイ履歴とコードの対応が明確になり、障害時の調査・ロールバックが容易になる
まとめ
Force new deployment は「タスク定義を変えずに新しいタスクを起動したいとき」の強力な手段です。ただし :latest タグ運用自体は追跡性が低いため、可能であれば SHA タグ+タスク定義の自動更新によるデプロイフローへの移行をおすすめします。
Force new deployment が必要な場面
- 同じタグで ECR イメージを更新した
- タスクが異常状態でリセットしたい
- Fargate 基盤更新通知が来た
- 外部リソース設定を再反映させたい
実行時の注意点
- ローリングアップデートで旧タスクが順次停止する
- 一時的にタスク数が増える可能性がある
maximumPercent/minimumHealthyPercentを事前に確認する- クラスターのキャパシティを事前に確認する
参考リソース
- タスクを置き換えて Amazon ECS サービスをデプロイする — AWS 公式ドキュメント:ローリングアップデートの詳細とイメージダイジェストの仕組みについての公式解説
- Amazon ECS サービスを更新する — AWS 公式ドキュメント:ECSサービス更新の手順と minimumHealthyPercent / maximumPercent の説明
- ECS サービスで「新しいデプロイの強制」を実行する方法 — DevelopersIO:AWS CLI での force-new-deployment コマンドの実例


コメント