はじめに
AWS ECS（Fargate）でサービスをデプロイした後、
「アプリにアクセスできない」「すぐにタスクが落ちる」といったトラブルが起きた場合、
どこから確認すればよいのか分からず時間を浪費することがよくあります。
本記事では、ECS 起動後に必ず確認すべき 3 点を軸に、
AWS コンソール上の見る場所・判断基準・よくあるエラー例をまとめます。
この記事でわかる・できること
- ECS デプロイ直後に最優先で確認すべき場所
- 「ALB・ECS・アプリのどこが原因か」を最短で切り分ける方法
- ECS でタスクが落ちる典型パターンの見分け方
この記事の対象者
- ECS（Fargate）で Web アプリを運用している人
- ALB 経由で ECS サービスを公開している人
- デプロイ後のトラブルシューティングに時間がかかっている人
動作環境・使用するツールや言語
- AWS ECS（Fargate）
- Application Load Balancer（ALB）
- CloudWatch Logs
- Rails / Next.js などの Web アプリケーション
1. ECS Service の「イベント」（最優先で確認）
ECS トラブルの一次情報は、必ず Service の「イベント」にあります。
開き方
- ECS
- クラスター
- 対象クラスター
- サービス
- 対象サービス
- 「イベント」タブ
正常時
service ... has reached a steady state.
registered targets in target-group ...
✅ この2つが出ていれば ECS的には正常です。
異常時（よく出るログ）
Essential container in task exited
Task stopped unexpectedly
👉 上記のエラーメッセージが表示されると、アプリまたは ENTRYPOINT が途中で落ちている可能性が高いです。
(target-group ...) health checks failed
👉 ALB ヘルスチェックに失敗すると上記のエラーメッセージになります。
判定の目安
| 表示 | 状態 |
|---|---|
| steady state | 起動成功 |
| stopped | コンテナ異常終了 |
| deregistering | ALB ヘルスチェック失敗 |
2. ALB Target Group の Target health（ALB視点）
次に確認するのが ALB 側から見た起動状態です。
開き方
- EC2
- ターゲットグループ
- 対象ターゲットグループ
- 「ターゲット」タブ
正常時
IP: 10.x.x.x
Port: 3000
Health: Healthy
✅ 1台以上 Healthy が必要です。
異常時（よく出るログ）
404 Error
Health checks failed with codes:[404]
- ヘルスチェックパス間違い
例：/health、 /api/health など
Timeout
Request timed out
- アプリ未起動
- ポート不一致
- セキュリティグループ / NACL
Connection refused
Target failed to respond
- 0.0.0.0 で listen していない
- Web サーバ未起動
3. CloudWatch Logs（アプリのログ）
ECS や ALB が止めた理由は、最終的にログで確定します。
開き方
- CloudWatch
- ロググループ
- /ecs/
- 最新ログストリーム
正常時（Web起動成功）
Server listening on 0.0.0.0:3000
👉 上記のログが出ていれば、アプリが正しく起動できています。
異常時（よく出るログ）
SIGTERM
Error
UnhandledPromiseRejection
Signal received
👉 上記が主なエラーになります。アプリの設定を見直してみましょう。
参考資料
おわりに・まとめ
ECSデプロイ後は 必ずこの順番で確認します。
- ECS Service イベント
- ALB Target health
- CloudWatch Logs
この3点を見るだけで、
「AWS が止めたのか」
「ALB が弾いたのか」
「アプリが自爆したのか」
が即座に分かります。
ECS トラブル時に重要なのは、勘で触らず、AWS が出している「判断材料」を正しく見ることです。
この習慣を付けるだけで、ECS トラブルの大半は数分で切り分け可能になります。