Amplifyのタイムアウトとサイズ制限の整理 | 413, 504の切り分け

AWS Amplify Hostingで動かしているフロントエンドが、ある日突然413 Request Entity Too Large・502 Bad Gateway・504 Gateway Timeoutを返し始めることがあります。原因の多くは「Amplify本体」ではなく、Amplifyが内部で使うAmazon CloudFrontや、その奥にいるLambda（SSR Compute）の上限に当たっていることです。

本記事は、実際のサービス開発で本番のAPIが413・504を返した事例をもとに、原因の切り分けと回避設計を整理した実務メモです。Amplify Hosting・CloudFront・Lambda@Edgeのそれぞれが持つタイムアウトとサイズ制限と、エラーから層を切り分ける順序を整理します。

01.事例：CloudFront + Amplify + Next.js + Laravel で 413 と 504 の両方が出た話

本記事は、次の構成で動かしているサービスで、運用中に 413 Content Too Large と 504 Gateway Timeout の両方に遭遇し、原因の切り分けと回避設計を整理した実務メモです。

事象1：検索系APIで413（レスポンスサイズ超過）

先に発生したのは 413 でした。検索系の API で取得件数を増やしたり、レコードあたりのサイズが大きいデータを含む条件を指定したりすると、レスポンスが大きくなり 413 Content Too Large が返るようになりました。

切り分けで効いたのは、Amplify のデフォルトドメイン（amplifyapp.com）に直接 curl を打って同じ症状を再現できるかを確認した点です。再現したため、前段のカスタム CloudFront ではなく Amplify 内部のレイヤー（内部 CloudFront）が 413 を返しているとわかりました。limit パラメータを変えながら計測すると、サイズと結果の対応関係はおおむね次のとおりでした。

Amplify 内部の設定はユーザー側で変更できないため、回避はレスポンスを軽くする方向で対処することになります。具体的には、limit の最大値を実用的な水準に絞る／データ種別ごとに 1 件あたりサイズが偏ることを前提に動的に件数を制御する／一覧 API と詳細 API を分けて応答そのものを軽くする、といった打ち手の組み合わせで、上限に当たらないラインに収めました。

事象2：集計系APIで504（30秒タイムアウト）

もう一つ出たのが 504 です。別フローの集計系 API では、Next.js の Server Actions から Laravel の重い集計処理を呼ぶと、504 Gateway Timeout が返るケースがありました。Laravel 側のログでは処理は完走しているのに、リクエストが消えてしまったように見える、という症状です。

切り分けの結果、原因は Amplify SSR Compute（Lambda）の 30 秒タイムアウトでした。Laravel 側で 30 秒を超えた時点で、Amplify が SSR Lambda の接続を切ってクライアントには 504 だけが届いていたわけです。Amplify SSR の 30 秒は、後述するとおりユーザー側で延長できません。そのため、本処理を 30 秒以内に収める方向には組み直さず、「受付」と「結果取得」の 2 段階に分けたポーリング型に再設計しました。

実装の流れは次の 3 ステップです。

1. 受付フェーズ：クライアントは Next.js の Server Actions を叩き、SSR は Laravel の /start-async エンドポイントを即座に呼んで 受付ID だけ返す。SSR 側の処理時間は数百ミリ秒で、30 秒の壁に当たりません。
2. 非同期処理フェーズ：Laravel は受付IDを Queue ジョブに積み、Worker が本処理（集計・検索など）を実行。結果は DB に 受付ID をキーに保存します。Amplify SSR は介在しないため、処理時間の上限は Worker 側の設定次第（Lambda なら 15 分、サーバなら任意）に伸ばせます。
3. ポーリングフェーズ：クライアントは受付IDを使って Next.js の /polling 経由で Laravel の /status を 10 秒間隔で叩き、状態が完了になったら結果を取得します。各リクエストは 1 秒以内で返るため、30 秒の壁にはぶつかりません。

共通の学び：Amplify SSR には「サイズ」と「時間」の二重の上限がある

この 2 つの事象から見えてきた整理は、Amplify SSR Compute にはレスポンスサイズ（5.72MB）と処理時間（30 秒）の二重の上限があり、どちらもユーザー側で延長・変更ができないということです。413 はレスポンスを軽くする方向、504 は非同期＋ポーリングへの再設計、というように、それぞれの上限ごとに回避の型は別物です。切り分けでは、Amplify のデフォルトドメインで再現するかを最初に確認するのが共通の手順として効きます。再現するなら原因は Amplify 内部の層なので、前段のカスタム CloudFront や WAF を疑う前に Amplify 側の上限を当たる、という順序になります。

以降の章では、ここで触れた Amplify SSR の上限を含めて、各層の上限値と切り分けの順序を整理します。

02.結論：制限値は層ごとに別物なので、まず層を見る

413・504 が返ったときに最初に確かめたいのは、そのエラーがどの層から返ってきているかです。Amplify Hosting は外側から見ると1つのサービスに見えますが、実際にはリクエストは複数の層を通っており、それぞれが独立した上限を持っています。

とくに見落としやすいのが、Amplify の入口と SSR Lambda の間にも CloudFront が入っている点です。アプリ側で前段に CDN を別途立てていなくても、ここの上限はかかります。アプリ自体に変更を加えていないのに 413 が出始めた、ステージングでは再現しないのに本番では出る、といった現象の多くは、この内部 CloudFront か SSR Compute の上限に当たっていることが原因です。

Amplify ホスティングは AWS 公式ドキュメント にも書かれているとおり、内部で CloudFront を使う構成です。デフォルトでは次の図のような構成になっており、カスタムドメインを使っていなくても Amplify の中に CloudFront が居る状態が標準です。

したがって 413 や 504 を見たときの最初の判断は、「Amplify の何かが壊れた」と一括りにすることではなく、どの層が返したエラーかを絞り込むことです。L3 の Lambda が直接返したのか、L2 の CloudFront が返したのか、L4 のオリジン API 由来かで、当てるべき上限が変わります。

03.AWS Amplify Hosting（SSR Compute）の制限値

まずAmplify Hosting自体が公式に明記している制限値を押さえます。Next.js 12以降など、Amplifyが「Web Compute」と呼ぶSSR実行環境に乗っているアプリが対象です。

レスポンスサイズの上限は5.72MB

Amplifyの SSRトラブルシューティングのドキュメント は、Web Compute（Next.js 12以降）でサポートされるレスポンスサイズの上限を5.72MBと明記しています。これを超えると、Amplifyは504を返し、ボディは空になります。

The maximum response size that Amplify supports for Next.js 12 and later apps using the Web Compute platform is 5.72 MB. Responses over that limit return 504 errors with no content to clients.

AWS Amplify Hosting User Guide, Troubleshooting server-side rendered applications（太字は引用者）

実務的には、1リクエストで数MBの配列を返すSSRページや、検索結果を一括で返すAPI Routeでこの上限に当たります。例えばリストのlimitパラメータを大きく取った瞬間に504が出始めるなら、まず疑うべき層はここです。

SSR Compute のAPIタイムアウトは30秒

AmplifyのSSR Compute（Web Compute）には、リクエスト処理の30秒タイムアウトがかかります。Next.jsの node server に限らず、Amplify SSR Compute 上で動くサーバー側処理（Next.js・Nuxt など）に共通で適用される、Amplify側の制限です。リクエスト処理が30秒を超えると Amplify 側で接続が切られ、クライアントには504が返ります。

出典の注意点として、この30秒という値は Amplify SSR features や Troubleshooting SSR のような Amplify 公式ドキュメントには明示されていません（5.72MB の応答上限は明示されていますが、30秒側は別物です）。実態としては、 aws-amplify/amplify-hosting #3223 など複数の issue で AWS 側回答も含めて 30 秒制限が繰り返し確認されており、ユーザー側で延長する手段は提供されていない、というのが実装上の挙動です。Lambda 本体の上限（最大 15 分）よりはるかに短く設定されている層であることに注意してください。

実装側で対処する方向は、長時間処理を非同期化するか、結果をストリーミングするか、そもそも別のホスティングを選ぶかです。Amplifyに乗せたまま30秒超のリクエストを扱うのは、現状では難しいと割り切ったほうが運用は安定します。

ビルド出力・Lambdaパッケージの上限

ランタイムの上限とは別に、ビルド時にも上限があります。Amplify SSRがサポートするビルド出力サイズは220MB、内部で生成されるLambdaのデプロイパッケージは50MBまでです。ビルド中に「出力が大きすぎてデプロイできない」というエラーで気づく類の制限で、稼働中の413/504とは別物として扱います。

Lambdaの同期payloadの6MBは、 Lambda公式のクォータ に基づく値です。Amplify特有の5.72MBはこの6MBより少し小さく、間にCloudFrontの処理ぶんが乗っているためと整理できます。

04.Amazon CloudFront（Amplifyが内部で使うCDN）の制限値

次に、Amplifyの裏側にいるCloudFront側の上限です。Amplify側を一切いじっていなくても、ここでブロックされることがあります。

オリジン応答タイムアウト：既定30秒・標準で1〜120秒

CloudFrontには「オリジンが応答を返し始めるまでの待ち時間」の上限があります。 公式ドキュメント によれば、既定は30秒、設定で指定できるのは標準で1〜120秒です。120秒を超えて延ばす場合は、AWSへのクォータ引き上げ申請が必要になります。

Amplify HostingではこのCloudFront側の値を直接いじれないため、SSRやAPI Routeで時間がかかる処理を投げると、L3（SSR Compute）の30秒の手前で、L2（CloudFront）側のタイムアウトに当たることもあります。「30秒で504が返るのが必ずSSR側」とは限らない点に注意します。

Lambda@Edge：Viewer 40KB／Origin 1MB

CloudFrontの前段にLambda@Edgeが噛んでいる構成では、レスポンスサイズの上限がさらに厳しくなります。 公式の制限 によれば、Viewer triggerのレスポンスは40KB、Origin triggerのレスポンスは1MBまでです。これを超えるとLambda@Edgeが応答を返せず、CloudFrontはクライアントに502を返します。

Amplifyを素で使っているだけならLambda@Edgeを書く機会は少ないものの、認証・リダイレクト・ヘッダー書き換えのために独自に挟むケースでは、ここが原因で502が出ることがあります。SSR ComputeのLambdaとは別物なので、混同しないようにします。

05.ステータスコードから層を切り分ける

実際の障害対応では、上限の表を覚えるよりも、「いま見ているステータスコードがどの層から返ってきているか」を最初に絞ることが効きます。

実務で効く切り分けの順序は次のとおりです。

• L4（オリジンAPI）に直接curlして同じ結果になるかを確認します。200が返るなら、L4は無罪です。
• Amplifyのデフォルトドメイン（amplifyapp.com）でも同じ症状になるかを確認します。カスタムドメイン用にユーザーが追加したCloudFrontがあるなら、その切り分けになります。
• レスポンス本文のサイズと、処理にかかった時間を計測します。Amplifyの5.72MB／30秒に近い数値が出ていれば、L3を疑います。
• Amplifyのデフォルトドメインでも再現するなら、L2の上限はAmplify内部のCloudFrontです。ユーザー側からは設定変更できないため、上限を超えない設計に戻す方向に切り替えます。
• どの層からのレスポンスかを、応答ヘッダとログで確認します。x-amz-cf-id・via・x-cache など CloudFront 経由のヘッダが付いていればその層を、Amplify／Lambda 側のログにリクエスト ID が残っていなければ SSR Compute に到達していない、といった切り分けができます。

06.設計段階で上限に当たらないためのチェック

本番で出てからの対処は手数がかかります。設計段階・初期実装段階で、次のチェックを通しておくと、後から「特定条件で413／504」に当たる確率を大きく下げられます。

実装側の打ち手としては、レスポンスサイズが線形に伸びるパラメータ（件数・期間・関連レコード）に上限を入れるのがもっとも素直です。クライアント側のlimitを最大100で受けていたところを、メディアやデータの種類によって動的に絞る、というだけでも、サイズ起因の事故は減らせます。

加えて、本番だけで再現する事故を避けるには、ステージング・本番のインフラ構成（CDN・WAF・カスタムドメイン・SSR Computeのバージョン）を設定単位で揃えておくことです。「STGでは出ないが本番で出る」のほとんどは、ここの差で説明がつきます。

07.Amplify に乗せたまま上限に当たらずに済ませる回避パターン

要件として 5.72MB／30 秒 を本当に超えなければいけないケースは、実は限られています。多くの 504／413 は、応答の組み立て方やジョブの分離方法を変えるだけで Amplify に乗せたまま回避できます。よく使う回避パターンを整理します。

ジョブキューで非同期にする場合は、「リクエスト即時応答（受付ID）」 → 「クライアントから結果ポーリング or 通知」の 2 段階に分けるのが定型です。SQS で受けて Amplify Functions の Lambda（SSR Compute とは別のもの）で処理し、結果は DynamoDB などに格納する形が、AWS 上で素直に組めます。30 秒の上限を超える処理は、これを前提に最初から設計に組み込んでおくと、後から上限に当たって慌てずに済みます。

08.よくある質問（FAQ）

09.まとめ

413・502・504 が返ったらまずどの層から返っているかを切り分け、当たっている上限を特定します。30 秒・5.72MB に当たりそうな処理は、Amplify Functions（別 Lambda）への分離と S3 + presigned URL の組み合わせが、Amplify に閉じた素直な回避策です。それでも要件が合わない場合は Cloudflare Workers のようなエッジ実行ランタイムへの移行が選択肢になります（数値は別記事『Cloudflare Workers のタイムアウトとサイズ制限を整理する』を参照）。

本記事で扱った制限値は、各サービスの公式ドキュメントを出典としています。クォータは時期によって緩和されることもあるため、本番に乗せる前には最新の公式ドキュメントで再確認してください。