2026.10.18 AWS

API Gatewayのタイムアウト：29秒の上限を引き上げる手順と504の切り分け・非同期化

Q: タイムアウトの値を変更したのに反映されないのはなぜですか？

REST APIでは、統合の設定を変えた後にステージへデプロイし直さないと、公開中のAPIには反映されません。 create-deployment を実行してから確かめてください。29秒より長い値が入力できない場合は、Service Quotasの申請がまだ承認されていないか、edge-optimizedのAPIである可能性があります。

API Gatewayのタイムアウト：29秒の上限を引き上げる手順と504の切り分け・非同期化

Amazon API Gatewayのタイムアウトは、バックエンドの応答を待つ「統合タイムアウト」が既定29秒で、超えるとクライアントに504が返ります。2024年6月からはREST APIに限って29秒より長く設定できるようになりましたが、HTTP APIやWebSocket API、edge-optimizedのエンドポイントでは引き上げられません。本記事では、APIの種類ごとの上限値、504の原因をログで切り分ける手順、引き上げ申請とCLIでの設定、非同期化とレスポンスストリーミングによる回避策を、動かせるコードとともにまとめました。APIゲートウェイという仕組みそのものはAPIゲートウェイとは？役割・機能とリバースプロキシ／サービスメッシュとの違い・導入判断を解説で扱っています。上限値は2026年10月時点の公式ドキュメントで確認した値です。

まとめ：29秒を超えられるのはRegionalとprivateのREST APIだけ

統合タイムアウトを29秒より長くできるのは、RegionalまたはprivateエンドポイントのREST APIだけです。Service Quotasで上限の引き上げを申請し、承認後に統合ごとのtimeoutInMillisを変えて再デプロイします。HTTP APIは30秒、WebSocket APIは29秒が固定の上限で、申請はできません。

引き上げは手軽ですが、アカウント全体のスロットル上限を下げられる場合があります。数分かかる処理では、受付だけ返して結果を後で取りに来させる非同期化への切り替えが基本です。生成AIの逐次出力のように少しずつ返せる処理なら、2025年11月に追加されたレスポンスストリーミングで最大15分まで応答を続けられます。504が出たら、まずアクセスログの応答種別で、時間切れなのか接続の失敗なのかを分けてください。

API Gatewayの統合タイムアウト上限｜API種類とエンドポイント別の値

上限値はAPIの種類ごとに別のクォータ表で定められています。ここではREST、HTTP、WebSocketの3種類を並べ、引き上げの可否まで整理します。

REST・HTTP・WebSocketの上限値と29秒超へ引き上げられる条件の一覧

REST APIのクォータ表では、統合タイムアウトはLambda、HTTP、AWSサービスのどの統合でも50ミリ秒から29秒です。Regionalとprivateには引き上げ可の印が付き、edge-optimizedは不可です。

APIとエンドポイント	既定の上限	29秒超への引き上げ
REST（Regional）	29秒	申請で可
REST（private）	29秒	申請で可
REST（edge-optimized）	29秒	不可
HTTP API	30秒	不可
WebSocket API	29秒	不可

HTTP APIのクォータ表は最大統合タイムアウトを30秒、WebSocket APIのクォータ表は29秒とし、どちらも引き上げ不可です。WebSocketの接続自体は最大2時間保てますが、1回のルート処理でバックエンドを待てる時間は29秒で変わりません。

統合タイムアウトとLambdaの最大900秒・CloudFrontの30秒の関係

API Gatewayの後ろにLambdaを置く場合、待ち時間を決めるのは短い方の値です。Lambdaのタイムアウトは既定3秒で最大900秒（15分）まで延ばせますが、API Gatewayが29秒で接続を切れば、クライアントには504が返ります。Lambdaの値だけを延ばしても症状は変わりません。

前段にCloudFrontを置く構成では、もう1段の制限が加わります。CloudFrontのオリジン設定では、オリジンの応答を待つレスポンスタイムアウトの既定が30秒です。API Gatewayを60秒に延ばしても、CloudFront側が30秒のままなら先に切れます。CloudFrontを前に置く構成の組み方はCloudFront×API Gateway×Lambdaの連携構成で解説しています。

504の原因調査｜アクセスログとCloudWatchで時間切れと接続失敗を切り分ける

API Gatewayが返す504には2つの種類があります。時間切れなのか、バックエンドへの接続そのものが失敗したのかで、打つ手がまったく違います。

INTEGRATION_TIMEOUTとINTEGRATION_FAILUREの判別

ゲートウェイレスポンスの一覧では、INTEGRATION_TIMEOUT（統合の時間切れ）とINTEGRATION_FAILURE（統合の失敗）のどちらも既定のステータスが504です。ステータスコードだけを見ていると区別できません。

前者なら処理時間を縮めるか、上限を延ばすか、非同期化します。後者はVPCリンクの先のターゲットが落ちている、セキュリティグループで遮断されているなど、接続経路の問題です。タイムアウト値をいくら延ばしても解消しないので、先にどちらかを確定させます。

アクセスログにintegrationLatencyとresponseTypeを出す設定例

見分けるには、ステージのアクセスログに応答種別と統合の所要時間を出します。アクセスログの変数一覧から、調査に要る変数だけを選んだJSON形式の例です。ステージの「ログとトレース」でカスタムアクセスログを有効にし、形式欄に貼り付けます。

{"requestId":"$context.requestId","status":"$context.status","responseType":"$context.error.responseType","integrationLatency":"$context.integrationLatency","integrationStatus":"$context.integration.status","integrationError":"$context.integration.error","responseLatency":"$context.responseLatency","path":"$context.resourcePath"}

$context.error.responseTypeには先のINTEGRATION_TIMEOUTなどの種別名が入ります。$context.integrationLatencyはバックエンドの応答を待った時間（ミリ秒）で、29,000前後に張り付いていれば、原因は時間切れです。CloudWatch Logsへの書き込みには、アカウント単位でAPI Gateway用のIAMロールを設定しておく必要があります。ロールの登録手順とログ形式の全体はAPI Gatewayのログ設定：実行ログとアクセスログをCloudWatchに出す手順とX-Rayでの障害調査で解説しています。

CloudWatch Logs Insightsで504を種別と5分単位で集計するクエリ

ログが溜まったら、CloudWatch Logs Insightsでアクセスロググループを選び、次のクエリを実行します。504の件数を種別ごと、5分ごとに数えます。

fields @timestamp, requestId, path, responseType, integrationLatency
| filter status = "504"
| stats count() as cnt, max(integrationLatency) as maxLatency by responseType, path, bin(5m)
| sort cnt desc

特定のパスにINTEGRATION_TIMEOUTが集中していれば、そのエンドポイントの処理が遅い問題です。全パスに散らばっていれば、データベースや外部APIなど共通の依存先を疑います。メトリクス側では、API Gatewayのメトリクス定義どおりIntegrationLatencyがバックエンドの待ち時間、LatencyがAPI Gateway自体の処理を含む全体の時間です。両者の差が大きいならオーソライザーなどAPI Gateway側の処理を、差が小さいならバックエンドを調べます。Lambda側の実行時間やエラーはAWS Lambdaのログ運用ガイドの手順でCloudWatch Logsから追えます。

REST APIの統合タイムアウトを29秒より長くする手順｜クォータ申請とCLI設定

REST APIの引き上げは、アカウントの上限を上げる申請と、統合ごとの値の変更の2段階です。申請が通っただけでは、既存の統合は29秒のまま動きます。

Service QuotasでL-E5AE38E3を申請し統合を60秒に設定する

引き上げは2024年6月4日のAWSの発表で可能になった機能で、追加料金はかかりません。対象のクォータコードはREST APIのクォータ表のリンク先にあるL-E5AE38E3です。AWS CLIで申請から反映までを行う例を示します。IDは自分の環境の値に置き換えてください。

# 1) 現在の統合タイムアウト（ミリ秒）を確認する
aws apigateway get-integration \
  --rest-api-id a1b2c3d4e5 --resource-id a1b2c3 --http-method POST \
  --query timeoutInMillis

# 2) アカウントの上限値を確認し、60秒への引き上げを申請する
aws service-quotas get-service-quota \
  --service-code apigateway --quota-code L-E5AE38E3
aws service-quotas request-service-quota-increase \
  --service-code apigateway --quota-code L-E5AE38E3 --desired-value 60000

# 3) 承認後、統合ごとに値を変えてステージへ再デプロイする
aws apigateway update-integration \
  --rest-api-id a1b2c3d4e5 --resource-id a1b2c3 --http-method POST \
  --patch-operations op=replace,path=/timeoutInMillis,value=60000
aws apigateway create-deployment --rest-api-id a1b2c3d4e5 --stage-name prod

update-integrationのリファレンスでは、timeoutInMillisの既定値は29,000ミリ秒で、29秒より長くできるのはRegionalとprivateのAPIだけと明記されています。手順3の再デプロイを忘れると、ステージには古い設定が残ります。

Lambdaのタイムアウトは統合タイムアウトより短く設定する

引き上げたら、Lambda側の値も合わせて見直します。順番は「Lambdaのタイムアウト＜統合タイムアウト」です。逆にすると、API Gatewayが504を返した後もLambdaが動き続け、結果は誰にも返らず実行時間の料金だけがかかります。

aws lambda update-function-configuration \
  --function-name order-export --timeout 55

統合タイムアウトを60秒にしたなら、Lambdaは55秒程度で自分から止まるようにします。こうしておけば時間切れの記録がLambdaのログに残り、どの処理で止まったかを後から追跡可能です。注文登録のように同じリクエストが再送されると困る処理では、リクエストIDで重複を弾く冪等性の仕組みも入れておきます。

引き上げでRegion単位のスロットル10,000rpsが下がる場合がある

REST APIのクォータ表には、29秒を超える値にするとRegionレベルのスロットル上限の引き下げが必要になる場合がある、という注記があります。アカウント単位のクォータでは、既定のスロットル上限はHTTP、REST、WebSocketのAPIを合計して毎秒10,000リクエスト、バーストは5,000です。

この上限は同じアカウントとRegionにある全APIで共有されます。1本のAPIのために延ばした結果、別のAPIが429で弾かれる可能性があるということです。ピーク時に毎秒数千リクエストを受けるアカウントでは、引き上げよりも非同期化を先に検討します。

29秒で収まらない処理の非同期化｜Lambda非同期呼び出しとジョブIDで返す構成

帳票の一括出力や外部システムとのデータ同期など、数分かかる処理を同期APIで待たせる設計は、上限を延ばしても破綻しやすい構成です。受付と処理を分けると、API Gatewayの上限に左右されなくなります。

X-Amz-Invocation-TypeにEventを渡して受付だけ即時に返す設定

Lambdaの非同期呼び出しの設定手順では、Lambdaの非プロキシ統合で統合リクエストにX-Amz-Invocation-Typeヘッダーを固定値'Event'で渡すと、API GatewayはLambdaの完了を待たずに応答します。OpenAPIで定義する場合の統合部分は次のとおりです。

"x-amazon-apigateway-integration": {
  "type": "aws",
  "httpMethod": "POST",
  "uri": "arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03-31/functions/arn:aws:lambda:ap-northeast-1:123456789012:function:order-export/invocations",
  "requestParameters": {
    "integration.request.header.X-Amz-Invocation-Type": "'Event'"
  },
  "responses": { "default": { "statusCode": "202" } },
  "passthroughBehavior": "when_no_match"
}

公式の例では応答コードを200にしていますが、受付だけを返すAPIなら202の方が意味が正確です。この設定はプロキシ統合（AWS_PROXY）では使えない点に注意してください。

ジョブIDを返し状態取得APIで完了を確認させる2本立ての設計

非同期化すると、処理結果はAPIの応答に載りません。そこで受付APIはジョブIDを発行してDynamoDBなどに「処理中」で記録し、そのIDを返します。クライアントはGET /jobs/{id}のような状態取得APIを数秒おきに呼び、完了したら結果の場所を受け取る仕組みです。大きな出力ファイルはS3に置き、署名付きURLで渡すと、10MBの応答サイズ上限も避けられます。

処理の受け渡しにSQSやEventBridgeを挟むと、失敗時の再試行や滞留の監視がしやすくなります。キューの設計とデッドレターキューの置き場所はEventBridgeとSQS・Lambdaの非同期構成にまとめました。処理自体がLambdaの15分を超える場合は、Lambda Durable Functionsで長時間のワークフローとして組む方法があります。

レスポンスストリーミングで最大15分まで応答を返す方法と使えない機能

結果を一度に返すのではなく、できた部分から順に返せる処理なら、非同期化よりも変更が小さく済む選択肢があります。

STREAMモードで15分・アイドル5分まで延びる条件とedgeの30秒

2025年11月19日の発表で、REST APIはレスポンスを段階的に返せるようになりました。レスポンスストリーミングの解説によると、統合の応答転送モードを既定のBUFFEREDからSTREAMに変えると、最大15分まで応答を流し続けられます。29秒を超えるのに上限の引き上げ申請は要りません。

ただし途中で送信が止まっている時間にはアイドルタイムアウトがかかり、RegionalとprivateのREST APIは5分、edge-optimizedは30秒です。対象はHTTP_PROXYとAWS_PROXYの統合だけで、HTTP APIとWebSocket APIでは使えません。チャットボットの生成結果を逐次表示する、SSEで進捗を送るといった用途が向いています。

キャッシュ・VTL変換・圧縮が使えず10MB超は毎秒2MBに絞られる制約

STREAMモードでは、応答全体を溜めてから処理する機能が使えません。ステージのキャッシュ、応答の圧縮、VTLによる応答の変換の3つです。既存のAPIでこれらを使っているなら、ストリーミングへの切り替えは設計の見直しを伴います。

応答の最初の10MBまでは帯域の制限がなく、それを超えた分は毎秒2MBに絞られます。接続がタイムアウトで切れた後もLambdaが実行を続ける場合がある点も、公式ドキュメントが明記している注意事項です。ストリーミングは別料金で、通常のリクエスト単価に上乗せされます。API Gatewayの単価の内訳はAPI Gatewayの料金を東京リージョンの実額で計算するで整理しています。

引き上げ・非同期化・ストリーミングの選び分け｜採用条件と見送る場面

3つの回避策は、処理時間の長さと、呼び出し側が結果をその場で受け取る必要があるかで選び分けます。

処理時間と呼び出し側の応答の待ち方で決める3つの回避策の採用条件

回避策	向く処理	前提
上限の引き上げ	30〜60秒で終わる同期処理	Regional・privateのREST
非同期化	数分以上かかる一括処理	状態取得APIを追加
ストリーミング	逐次出力できる処理	プロキシ統合のREST

判断はこの順で行います。処理が1分を超えるなら、迷わず非同期化を選びます。引き上げは「既存のクライアントが同期応答を前提にしていて、改修できない」場合の延命策です。生成AIの応答のように、待ち時間の大半が出力の生成に使われる処理だけがストリーミングの本命です。

引き上げを見送るべきHTTP API・edge-optimized・高スループットの場面

次の3つの場面では、引き上げ申請をしません。1つ目はHTTP APIとWebSocket APIで、上限が固定されているため申請の手段がありません。2つ目はedge-optimizedのREST APIです。Regionalに切り替えて自前のCloudFrontを前に置けば申請できますが、CloudFrontのタイムアウトとあわせて2か所を変える作業になります。カスタムドメインをRegionalで作り直す手順はAPI Gatewayのカスタムドメイン設定を解説した記事にまとめています。3つ目は、ピーク時のリクエスト数がアカウントのスロットル上限に近いワークロードです。

遅いSQLや外部APIの応答待ちが原因の504も、引き上げでは直りません。データが増えるたびに上限へ近づき、同じ障害が再発します。先にアクセスログで遅いパスを特定し、処理自体を縮められないか確かめてください。API Gatewayを含むAPI基盤の設計や既存APIの非同期化の進め方を外部に相談したい場合は、API開発・システム連携のページで支援内容を紹介しています。

API Gatewayのタイムアウトについてよくある質問と回答

API Gatewayのタイムアウトで、設定や障害対応の際によく出る質問に答えます。

API Gatewayのタイムアウトのデフォルト値は何秒ですか？

REST APIとWebSocket APIの統合タイムアウトは既定で29秒です。REST APIでは50ミリ秒から29秒の範囲で統合ごとに短くでき、Regionalとprivateなら申請を経て29秒より長くできます。HTTP APIは最大30秒で、それより長くはできません。値はいずれも2026年10月時点の公式クォータ表の記載です。

Lambdaのタイムアウトを延ばしたのに504が出るのはなぜですか？

API Gatewayの統合タイムアウトが先に切れているためです。Lambdaは最大15分まで動けますが、API Gatewayが29秒で接続を切ると、クライアントには504が返ります。Lambdaの値を延ばすのではなく、統合タイムアウトを引き上げるか、非同期化してください。Lambdaの値は統合タイムアウトより短くしておきます。

HTTP APIで30秒を超える処理を扱うにはどうすればよいですか？

HTTP APIの30秒は引き上げられないため、構成を変えます。数分かかる処理なら、受付だけを返してジョブIDで結果を取りに来させる非同期化が基本です。逐次出力したい場合はREST APIに移してレスポンスストリーミングを使います。同期のまま60秒程度まで延ばしたいなら、RegionalのREST APIへの移行が必要です。

統合タイムアウトの引き上げ申請に料金はかかりますか？

2024年6月の発表では、引き上げは追加料金なしで使えると案内されています。ただし長く待つほど、後ろにいるLambdaの実行時間の料金は増えます。また、Regionレベルのスロットル上限が引き下げられる場合があるため、同じアカウントで大量のリクエストを受けているAPIへの影響を先に確かめてください。

タイムアウトの値を変更したのに反映されないのはなぜですか？

REST APIでは、統合の設定を変えた後にステージへデプロイし直さないと、公開中のAPIには反映されません。create-deploymentを実行してから確かめてください。29秒より長い値が入力できない場合は、Service Quotasの申請がまだ承認されていないか、edge-optimizedのAPIである可能性があります。