Share
Embed
LambdaWebFunctionsを試してみた / exploring-lambda-web-functions
JAWS-UG 彩の国埼玉支部 #12 AWS re:Invent 2026 準備会 登壇資料です。
koukihosaka
October 18, 2026
Transcript
14 slides
-
自己紹介 保坂 光希 NTT ME株式会社(NTT東日本グループ) 気になるサービス: Lambda Web Functions 表彰など:
2026 AWS Community Builders (Serverless) 2026 Japan AWS Top Engineers (Services) 2025 - 2026 Japan All AWS Certifications Engineers ほうき星 𝕏 @H0ukiStar 2 / 16 -
Lambda Web Functions とは • コードが HTTP リクエストを直接受け取れる新しい Lambda 関数
• Express / Hono / 素の Node.js 等をアダプター不要でそのまま動かせる const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':'); // ランタイムが listen 先を環境変数 で渡す app.listen(port, host); // 受け取った listen 先を使用して 普通の HTTP サーバを起動 • 展開もワンコマンド aws lambda-web deploy • 1 環境あたり最大 128(デフォルト 64)リクエストを同時に処理 • 選べるランタイムは現状 Node.js 24 のみ • 環境も現状 Arm64 / 2vCPU / 2GB 固定 4 / 16 -
既存 Lambda は “Event Functions” に改名 • 従来の Lambda は
Event Functions に改名(名称のみ) event(辞書)を受け取って処理するモデルなのでいい命名だと思う(上から目線) export const handler = async (event) => {…} • 従来は Lambda Web Adapter が以下のような event を変換していた ※関数 URL の event 例、一部省略 { "requestContext": { "http": { "method": "GET", "path": "/" } }, "rawPath": "/", "rawQueryString": "", "headers": {…}, "isBase64Encoded": false } 5 / 16 -
Web Functions 3 つのコンポーネント構成 • Web Functions: 名前や Arn を持つ最上位の箱
• Endpoint: HTTP トラフィックを Revision にルーティングするエ ントリーポイント、Event Functions のエイリアス相当 • Revision: コード+設定を保持する不変のスナップショット デプロイごとに増え、Event Functions の関数バージョ ン相当 6 / 16 -
料金 課金要素は 3 つ ※参考価格は東京リージョン、他にデータ転送費もかかる • リクエスト: $ 0.30 /
100 万リクエスト $ 0.0000042688 / GB - second • メモリ: • アクティブ vCPU: $ 0.0000322421 / vCPU - second アクティブな CPU 時間に対する課金のため、DB・外部 API・AI 推論などの待ち時間には課金され ないのが特徴 ※Event Functions の参考 • リクエスト: $ 0.20 / 100 万リクエスト $ 0.0000133334 / GB - second • メモリ: ※ Armの場合、CPU料金も含まれる 7 / 16 -
1 環境が複数リクエストを処理できることを確認する • SSE(Server-Sent Events)も用いて、 継続した複数の接続を観測するデモを作成 • 接続を開きっぱにし、サーバ側より「今、この環境が何本の接続を抱えている か」を 2
秒ごとにクライアントへ push • Event Functions(LWA)と Web Functions で比較 9 / 16 -
Event Functions の場合のデモ • 1 環境あたりの同時接続数:1 増やした接続はすべて instanceId が異な り、activeConnections
もすべて 1 • 最大環境数: 同時に捌けるリクエストの上限はアカウ ントの concurrency 依存 10 / 16 -
Web Functions の場合のデモ • 1 環境あたりの同時接続数: Revision の設定項目 “maxConcurrencyPerEnvironment” が同時に受け付けられるリクエストの最
大値 デモでは “2” にしているため、各環境の activeConnections は “2” で頭打ちも、1 環境で複数のリクエストを捌けることが わかる • 最大環境数: Endpoint の設定項目 “Maximum environments” が最大環境数 デモでは “2” にしているため、 5 接続目 以降は 429 となってる 11 / 16 -
環境のライフサイクル • Event Functions は 1 環境 = 1 リクエスト
同時に複数リクエストがくる場合は同時実行数を上限に環境がコールドスタート リクエスト#3 リクエスト#1 環境 1 EXECUTION INIT RUNTIME INIT FUNCTION INIT INVOKE#1 INVOKE#3 ・・・ RUNTIME SHUTDOWN EXECUTION SHUTDOWN ・・・ RUNTIME SHUTDOWN EXECUTION SHUTDOWN リクエスト#2 環境 2 EXECUTION INIT RUNTIME INIT FUNCTION INIT INVOKE#2 • Web Functions は 1 環境で複数リクエストを同時に処理 デフォルト 64、最大 128 を同時に処理、その分コールドスタートを低減 リクエスト#1 リクエスト#2 リクエスト#3 Request#1 Request#2 環境 1 Initialize Ready Request#3 ・・・ Shutdown 12 / 16 -
まとめ HTTP を直接待ち受ける Lambda 従来 Event Functions で必要だった Lambda Web
Adapter が不要 複数のリクエストを同時に処理 1 環境が複数リクエストを同時に処理でき、 その分コールドスタートを低減 アクティブ CPU 課金 I/O 待ちに強く、SSE / ストリーミング系との相性も良い 13 / 16