キュー駆動のECS workerで、サービスの desired count と running count が一致していても、アプリケーションが最新とは限らない。新しいtask definitionが登録されただけで、サービス更新の対象から漏れていると、旧イメージのタスクが正常にRUNNINGし続ける。旧イメージにworker実装や起動設定がなければ、キューにはメッセージが滞留し、受信回数はゼロ、業務タスクは開始前の状態に残る。

切り分けでは、まずキューの送信・受信・削除回数、可視・非可視件数、DLQ件数を確認する。送信済み、可視メッセージあり、受信ゼロ、非可視ゼロなら、処理中エラーより前に「consumerが受信APIへ到達していない」と判断できる。次にECSサービスが参照するtask definitionのrevisionと、同familyの最新登録revisionを比較し、それぞれのコンテナイメージ識別子、worker名、キューURLを照合する。最新revisionだけが新イメージで、サービスが旧revisionを参照していれば、IAMやネットワークを深掘りする前にデプロイ対象漏れを疑う。

RUNNINGはプロセス生存の確認であり、最新コードの稼働やキュー消費の確認ではない。デプロイ完了条件には、対象サービスが最新task definitionを参照していることと、キューの受信メトリクスが動くことを含める。サービス一覧を手書きで管理する場合、新しいworkerを追加したときはtask definition生成、サービス更新、安定待機、監視対象の全リストを同じ棚卸しで確認する。予防には、インフラ定義に存在するworkerサービスとデプロイスクリプトの対象集合を比較する静的テストが有効。