はじめに
目的
本ドキュメントは、AWS環境で発生する504 Gateway Timeoutエラーについて、原因と対応方法を分かりやすく解説します。運用担当者や開発者が原因を特定し、速やかに対処できるように構成しています。
想定読者
主に次の方を想定しています。
– AWSでアプリを運用しているエンジニア
– 障害対応を担当する運用チーム
– 504エラーの原因を把握したい開発者
専門用語は最小限にし、具体例を交えて説明します。
504 Gateway Timeoutとは
504エラーは、ゲートウェイ（例：ロードバランサーやAPIゲートウェイ）が上流のサーバーから指定時間内に応答を受け取れなかったときに発生します。たとえば、ブラウザがページを要求し、ロードバランサーがバックエンドサーバーから応答を得られないケースです。画面には「504 Gateway Timeout」と表示されますが、実際の原因はネットワークやアプリケーション処理の遅延など多岐にわたります。
本ドキュメントで扱う内容
第2章で504エラーの動作と挙動を詳しく説明します。第3章で主な原因を整理し、第4章で具体的な対応方法と再発防止策を提示します。段階を追って確認すれば、原因の切り分けと復旧を効率よく行えます。
この章では全体像を示しました。次章から具体的な挙動と診断のポイントを見ていきます。
AWS 504エラーについて
概要
AWS環境での504 Gateway Timeoutは、ゲートウェイやロードバランサーが上流のサーバーから指定時間内に応答を受け取れないときに発生します。外部からのリクエストは受け取れても、内部処理が遅れるとタイムアウトでエラーを返します。
発生する仕組み（わかりやすく）
- クライアントがロードバランサーやAPI Gatewayにリクエストを送信します。
- その装置が、リクエストを背後のサーバー（EC2、ECS、Lambda、オンプレ等）に転送します。
- 背後のサーバーが決められた時間内に応答しないと、ゲートウェイ側が504を返します。
よく使われるAWSサービスと504の関係例
- Application Load Balancer(ALB): ターゲットの応答が遅いと504を返します。
- API Gateway: 統合先（LambdaやHTTPエンドポイント）が応答しない場合に発生します。
- CloudFront: オリジンが応答しないときに504を返すことがあります。
普段見られる具体例
- 長時間処理するバッチリクエストが同期で呼ばれた。
- データベースが高負荷でクエリが遅延した。
- ネットワーク断やセッション切れで接続が確立できなかった。
最初に確認すべきこと（手早く確認）
- 対象サービスのログ（ALBログ、API Gatewayログ、Lambdaログ）を確認する。
- タイムアウト設定と背後サービスの処理時間を比較する。
- サービス間のネットワーク疎通を簡単に確認する（ヘルスチェック等）。
以上が、AWS環境で発生する504エラーの概要と発生の流れ、よくある例です。
主な原因
アプリケーション層の応答遅延
Webアプリの処理が長時間かかると504が返ります。大量データ処理や外部API呼び出しの待ちが典型例です。症状としては特定のリクエストだけ遅くなる、バックエンドログに処理時間の増加が残ります。まずはアプリケーションログと外部APIの応答時間を確認してください。
ALB（Application Load Balancer）の設定ミス
ターゲットグループのヘルスチェック失敗やポート不一致で通信が届かず504になります。ALBのアクセスログやターゲットのヘルス状態を見れば分かります。ターゲットのポート、ヘルスチェックパス、プロトコルを確認してください。
セキュリティグループの設定エラー
ロードバランサーとターゲット間の必要なポートが遮断されるとリクエストが届きません。特に送信元/宛先のルールを確認します。症状は接続拒否やタイムアウトで、セキュリティグループのルールを開けると解消する場合が多いです。
タイムアウト設定の不備
ALB、アプリ、外部サービスでタイムアウト値がばらばらだと途中で切断されます。例えばALBのタイムアウトが短くバックエンドが応答中の場合に504になります。各層のタイムアウトを合わせて検証してください。
リソース枯渇
CPUやメモリ、ネットワーク帯域が足りないと応答が遅れます。CloudWatchでCPU使用率、メモリ、ネットワークを確認し、スケールアウトやリソース増強を検討してください。
対応方法
目的と概略
CloudFrontで発生する504エラーは、まずログでOrigin側のエラーとタイムアウトを確認して切り分けることが有効です。本章では実務で使える順序立てた確認手順と対処例を示します。
1) CloudFrontログとCloudWatchの確認
- CloudFrontアクセスログ（またはCloudFrontのモニタリング）で”OriginError”やタイムアウト表記を探します。
- CloudWatchで4xx/5xxの増加やOriginLatencyの急上昇を確認します。これで問題がキャッシュ側かオリジン側か判断できます。
2) オリジン（ターゲット）の健全性確認
- ALB/NLBのターゲットグループでヘルスチェック状態、5xx率、レイテンシを見ます。
- バスチオンや内部から直接オリジン（ALBのDNSやEC2のIP）へcurlして応答時間とステータスを確認します。
3) ネットワークとセキュリティ設定の確認
- セキュリティグループやNACLがCloudFrontまたはALBからのトラフィックを許可しているか確認します。
- Routeやサブネットの設定が正しく、パブリック/プライベートの配置に齟齬がないかを確認します。
4) タイムアウトとリソース設定の調整
- CloudFrontとオリジン側（アプリ、ALB、Lambdaなど）のタイムアウト設定を確認し、必要なら適切に延長します。
- アプリケーションの処理時間やDBクエリを改善するか、インスタンス数を増やして負荷を分散します。
5) 応急処置と恒久対策
- 応急：CloudFrontでキャッシュを有効化して負荷を軽減する、カスタムエラーページで利用者向け案内を出す。
- 恒久：オートスケーリング、アプリ性能改善、詳細なログ収集とアラート設定を行います。
実行順のチェックリスト（簡潔）
- CloudFrontログ→2. Originに直接アクセス→3. ターゲットヘルスとメトリクス→4. ネットワーク設定→5. タイムアウト/スケール調整
これらを順に行えば原因の切り分けが早まり、適切な対処につながります。
