Lambda Web Functionsの上限を実測する

400MiBのbody、timeout、同時処理数、環境IDをAWSで比較します。HTTP 200でも全量を受信できない例と、設定した上限を使うときの条件を実測から確認します。

Series: Try Lambda Web Functions (4 articles)

1
Lambda Web FunctionsでHTTP serverを動かしてみる
…
4
Lambda Web Functionsの上限を実測する This article

Shiro Seike

Senior Evangelist

Published Oct 21, 2026

Last modified Oct 21, 2026

Lambda Web Functionsで大きなbodyを送るとき、何を上限として見積もればよいでしょうか。HTTPで送受信する本文データがbodyです。今回は400MiBのbody、同時処理数の設定、requestを送らない間の環境IDをAWSで比較しました。1MiBは1,048,576 bytesです。
400MiBのresponseはtimeoutを30秒にした試行で全量を受信できませんでした。それでもHTTP 200とcurlの終了値0が返りました。900秒では全量を受信できたため、成功を判断するには受信したbytes数も必要でした。
上限の設定を確認する HTTP仕様のページ には、request line、header、末尾の空行を合わせた128KiBの上限があります。一方、このページにはbodyの上限bytes数が記載されていません。400MiBが通るか、長い転送がどの条件で切れるかを実測します。
利用者が設定する上限もあります。revisionはcodeと実行設定を固定した版で、timeoutと maxConcurrencyPerEnvironment を持ちます。endpointはrequestを受けるURLで、 maxEnvironments を設定できます。
設定
設定先
今回の値
 timeoutSeconds 
revision
30秒、900秒
 maxConcurrencyPerEnvironment 
revision
4、64
 maxEnvironments 
endpoint
4
concurrencyは同時に処理中のrequest数です。 scalingの仕様 では、環境ごとの実際の上限をLambdaが調整します。 maxConcurrencyPerEnvironment はその上限を抑える設定で、指定した数をいつでも使えるという保証ではありません。
検証用のHTTP server東京regionの検証用Web Functionで、依存のないNode.js HTTP serverを動かしました。runtimeは nodejs24.x です。2026年10月19日の実測に、10月20日の受信結果と環境IDの比較を追加しました。
今回使ったrouteは4つです。 /echo-size は受信したbytes数を返し、 /big-response?mb=400 は400MiBを流します。 /wait?ms=8000 は8秒待機し、 /env は起動時に作ったIDと process.uptime() の値を返します。
﻿
図は後で説明する30並行試験の構成です。bodyと環境IDの試験では同じ検証用endpointを使い、revisionと呼び出し条件を分けました。
bodyとtimeoutを比べるrequestでは400MiBを送り、アプリが受け取ったbytes数を確認しました。結果は419,430,400 bytesでした。この試行のtimeoutは900秒です。今回分かるのは、400MiBのrequestを受け取れたことまでです。
﻿
responseでは同じcodeを使う30秒と900秒のrevisionを比べました。両方とも環境あたりの同時処理数上限は4、endpointの環境数上限は4です。requestは1本ずつ送り、応答headerの lambda-web-logstream でも実際に応えたrevisionを確認しました。
長い転送を比較するため、curlの受信速度を --limit-rate 8M で8MiB/sまでに抑えました。アプリが流す量はどちらも419,430,400 bytesです。表の値はclientで受信した量です。
timeout
受信bytes
所要時間
HTTP status
curl終了値
全量受信
30秒
252,438,470
32.47秒
200
0
できなかった
900秒
419,430,400
52.66秒
200
0
できた
﻿
この画像は、計測clientが保存した結果を、そのままCloudWatch Logsの専用streamへ送って表示した画面です。アプリの「送った」というログとは分けています。 completed は、curlの終了値が0で、受信量も期待した419,430,400 bytesと一致したときだけ1です。
比較に使ったcurlの指定は次のとおりです。 WEB_FUNCTION_URL には検証用endpointのURLを設定します。revisionの切り替えはrequestを送る前に行いました。
sh
curl --http1.1 --limit-rate 8M --max-time 120 \
  --output /dev/null \
  --write-out 'status=%{http_code} bytes=%{size_download} seconds=%{time_total}\n' \
  "$WEB_FUNCTION_URL/big-response?mb=400"
30秒の試行はHTTP statusとcurlの終了値だけを見ると成功に見えます。今回の固定サイズの転送では、受信したbytes数との比較で不足を見つけられました。response headerを返した後の切断を扱う設計では、何をもって全量受信とするかも決めます。
400MiBより大きいbodyや、別の転送速度での上限は測っていません。今回の比較は、400MiBの転送がtimeoutの設定によって途中で終わる例です。bodyにbyte数の上限がないことを証明するものではありません。
concurrencyの設定を比べる次は10月19日の30並行試験です。 maxConcurrencyPerEnvironment=4 と maxEnvironments=4 の下で、8秒待機するrequestを30本送りました。結果は成功16本、429が14本でした。
成功した16本は4つの環境IDへ4本ずつ分かれました。応答の inflight にはNode.jsの起動後に観測した最大同時処理数を返しています。応答した瞬間の同時処理数ではありません。今回の各環境では、この最大値が4でした。
﻿
待つだけの軽い処理では、設定値の積である16本が成功しました。拒否された応答では、 lambda-web-error-type: Platform.EndpointMaxEnvThrottle を確認しています。 エラー一覧 で、環境数の上限による拒否を区別できます。429にはrequest rateやaccount quotaによるものもあるため、statusだけでは原因を決めません。
環境あたりの設定を既定の64にした試行では、12秒待つrequestを80本送り、全て200でした。環境IDごとの本数は31、18、31です。3環境に分かれたことは確認できましたが、この1回だけで振り分けの規則や実際の動的上限は分かりません。
16や64は、今回の待機処理の条件で読む値です。CPUを使い続ける処理やDB接続を伴う処理では、同じ設定でも別の結果になる可能性があります。
空き時間と環境IDを比べる最後に、requestを送らない時間を置いてIDを比べました。ここで環境IDと呼ぶ値はNode.jsの起動時に作った8桁の乱数です。AWSが付けた環境識別子ではなく、同じプロセスから応答を受けたかを読む目印です。
10月20日の追加試験では、 /env を1回呼び、5分待って再び呼びました。その後は8分待ってから、3回目を呼びました。この間に同じendpointへ別のHTTP requestは送りませんでした。
応答
前回の応答後に置いた待機
環境ID
uptimeMs
開始時
なし
 fe092f98 
80,735.89
2回目
5分
 fe092f98 
381,308.48
3回目
8分
 9b40e873 
183.72
﻿
5分後は同じIDの fe092f98 が応え、さらに8分空けた後は 9b40e873 が応えました。3回目のuptimeは約184msでした。これは、この3応答で確認した結果です。
応答からは、前の環境が終了した時刻や、ほかの環境が残っていたかは分かりません。 環境のライフサイクル にも、環境が残る時間の保証はありません。scalingの仕様では、最低限の環境数を予約する設定もありません。
測定結果の読み方今回のbody試験で分かったのは、400MiBを扱える条件と、受信量が不足する条件です。ファイルのように期待するサイズが決まる転送なら、HTTP statusに加えて受信量を照合できます。長く流し続ける応答では、timeoutと、途中で終わったと判断する方法を先に決めます。
同時処理数の設定値の積は処理の性能保証には使えません。待機処理で16本が成功しても、負荷を変えたときの動的上限は別に確かめる必要があります。429が返ったら、今回のようにエラーの種類を読み、設定と実際の応答を対応付けます。
環境IDの比較は同じIDから応答を受け続けられるという保証にはなりません。次のrequestで別のIDが返っても処理を続けられることを、設計の前提にします。
まとめLambda Web Functionsの上限を見積もるには、設定値とHTTPの成功だけでは足りませんでした。今回の400MiB転送では受信したbytes数、同時処理数の試験では処理の軽さと429の種類、環境の試験ではIDが示す範囲まで確認しました。
今回の値を別の処理へそのまま当てはめず、必要なbodyの大きさ、処理の負荷、requestの間隔をそろえて比較することが、採用する条件を決めるために必要です。