はじめに

本記事では、AWS ALB（Application Load Balancer）と Fargate 上で稼働する FastAPI アプリケーションの構成において「502 Bad Gateway」エラーが発生した際の、原因特定と対処方法について整理します。

個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。

よくある原因と対処法

Fargate 環境では、0.0.0.0 でバインドしないと外部（ALB）からアクセスできません。

例：ターゲットグループのヘルスチェックパス /health を設定していて、FastAPI 側にそのエンドポイントが存在しない場合、ターゲットが常に unhealthy となり、結果として 502 エラーになる可能性が高い。

# FastAPI 側でのヘルスチェックエンドポイントの追加例
@app.get("/health")
def health_check():
    return {"status": "ok"}

ALB のセキュリティグループから、Fargate のセキュリティグループに対して TCP 8000 ポートのインバウンド通信が許可されていない場合、通信できずに 502 となります。

チェック項目	確認結果
FastAPI が `0.0.0.0` で待ち受けているか	✅
ポート8000で起動しているか	✅
ターゲットグループがポート8000に向いているか	✅
ターゲットグループのヘルスチェックパスが FastAPI 側にあるか	✅
セキュリティグループで ALB→Fargate 通信が許可されているか	✅
FastAPI のログにエラーがないか	✅

INFO ログしか出ていない場合でも、コンテナ内のアプリが正しく処理を返せていないケースがあります。

リクエストに対して 500 を返していたり、タイムアウトしている可能性も含めて、アプリケーションログと ALB のターゲットステータス（unhealthy）などを合わせて確認してみてください...！

本記事で紹介したように、ALB との組み合わせでよく発生する 502 Bad Gateway の多くは、「アプリが適切に公開されていない」「ヘルスチェック失敗」が原因です。

現時点では問題はまだ解消していませんが、これらの観点をもとに、引き続き原因を切り分けながら確認を進めていく予定です。

1つずつ設定を丁寧に見直すことで、安定したデプロイ環境を構築できるはずです。ALB との組み合わせでよく発生する 502 Bad Gateway の多くは、「アプリが適切に公開されていない」「ヘルスチェック失敗」が原因です...！