問題の発生ECSサービスのデプロイを実行したものの、アプリケーションが起動せず、数秒以内にタスクが STOPPED 状態に切り替わってしまうことがあります。AWSコンソールには通常、Essential container in task exited という、曖昧でフラストレーションの溜まるメッセージが表示されます。これは、あなたが「Essential（必須）」としてマークしたプライマリコンテナが、ヘルスチェックに失敗したか、起動直後にクラッシュしたために発生します。
真の原因は Exit Code（終了コード） に隠されています。awslogs ドライバがログをCloudWatchに送信する前にコンテナがクラッシュしてしまうと、暗闇の中でデバッグしているような気分になるかもしれません。これらのコードを理解することが、サービスをオンラインに戻すための最短ルートです。
一般的な終了コードとその意味- Exit Code 1: 一般的なアプリケーションのクラッシュ。通常、実行時エラー、環境変数の不足、またはデータベース接続の失敗に起因します。- Exit Code 127: コマンドが見つからない。ENTRYPOINT または CMD が、コンテナイメージ内に存在しないスクリプトやバイナリを指しています。- Exit Code 137: メモリ不足 (OOM)。タスク定義で割り当てた512MBや1GB以上のRAMを使用しようとしたため、Fargateエージェントがコンテナを強制終了しました。## 根本原因の特定方法ハイレベルなサービスイベントを確認するのに時間を費やさないでください。そこには具体的なエラーが記載されていることは稀です。代わりに、失敗した個々のタスクを詳しく調べます。
- ECSクラスターを開き、対象のサービスを選択します。- **「タスク」**タブに移動し、フィルターを Stopped に変更します。- 直近の失敗したタスクの Task ID をクリックします。- **「コンテナ」**セクションを展開します。特に Exit Code と Reason フィールドを確認してください。## 実証済みの解決策### 1. 終了コード 1 の解決：アプリケーション実行時のクラッシュ終了コード 1 のエラーの多くは設定の問題です。例えば、Node.jsアプリが
DB_HOST変数を期待しているのにundefinedだった場合、ブートストラップフェーズでクラッシュする可能性が高くなります。 - CloudWatch Logsを確認する： "Module not found" やスタックトレースを探してください。ログが存在しない場合は、ロギングエージェントが開始される前にクラッシュが発生しています。- Secret Managerの権限を確認する： これはよくある落とし穴です。タスク実行ロール（タスクロールではありません）にシークレットを取得するための権限が必要です。
secretsmanager:GetSecretValue権限がないと、アプリは起動に必要な認証情報を取得できません。``` // タスク実行ロールに必要なポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "kms:Decrypt" ], "Resource": ["arn:aws:secretsmanager:region:account:secret:app-db-creds-*"] } ] }
### 2. 終了コード 127 の解決：パスと権限のエラーこのエラーは、コンテナは起動したものの、Linuxシェルが起動スクリプトを見つけられない場合に発生します。特にタスク定義でコマンドを上書きしている場合によく見られます。
- **絶対パスを使用する：** `./start.sh` ではなく、`/usr/src/app/start.sh` を使用してください。- **改行コードを修正する：** Windowsで作成されたスクリプトは通常 `CRLF` 改行コードを使用しますが、Linuxコンテナには `LF` が必要です。`sh: /start.sh: not found` と表示されているのにファイルが確実に存在する場合、改行コードが原因である可能性が高いです。イメージをビルドする前に、スクリプトに対して `dos2unix` を実行してください。- **権限を設定する：** Dockerfileに `RUN chmod +x /path/to/script.sh` が含まれていることを確認してください。### 3. 終了コード 137 の解決：メモリ制限FargateはローカルのDocker環境よりも厳格です。2GBのタスクでJava Spring Bootアプリが起動時に2.1GBまでスパイクした場合、Fargateは即座にそれを終了させます。
- **タスクサイズを上げる：** メモリ割り当てを2倍（例：2GBから4GB）に増やして、タスクが安定するか確認してください。- **JVMのチューニング：** Javaアプリケーションの場合は、`-XX:MaxRAMPercentage=75.0` を使用してください。これにより、JVMはホストマシン全体のメモリを確保しようとするのではなく、コンテナの制限を尊重するようになります。### 4. ネットワークの失敗（「ログなし」のシナリオ）タスクが `ResourceInitializationError: unable to pull secrets or registry auth` で停止する場合、コンテナは実際には一度も実行されていません。これはVPC内のネットワークのボトルネックです。
- **パブリックサブネット：** タスクがインターネット経由でECRサービスに到達できるように、**Auto-assign Public IP** を `ENABLED` に設定する必要があります。- **プライベートサブネット：** NAT Gatewayが配置されていることを確認してください。あるいは、トラフィックがAWSネットワーク内に留まるように、ECR、S3、CloudWatch用のVPC Endpoints（Interface Endpoints）を設定します。## 検証とデプロイIAMポリシーの更新やRAMの増設などの修正を適用した後は、変更を適切にデプロイする必要があります：
- タスク定義の**新しいリビジョン（New Revision）**を作成します。- 最新のリビジョンを使用するようにサービスを更新します。- **「タスク」**タブを監視します。デプロイが成功すると、状態が `PROVISIONING` から `RUNNING` に遷移し、その状態が維持されます。- **Health Status** が `HEALTHY` であることを確認します。これは、ロードバランサーまたはコンテナのヘルスチェックがついにレスポンスを受信したことを示します。## まとめチェックリスト- サービスイベントだけでなく、タスクの詳細にある **Stopped Reason** を確認する。- **タスク実行ロール**（イメージやシークレットのプル用）と**タスクロール**（アプリケーションロジック用）の違いを区別する。- 127エラーを防ぐために、Dockerコマンドでは常に絶対パスを使用する。- 実行時の最初の数秒間のstdout/stderrをキャプチャできるように、すぐに `awslogs` を設定する。