Lambda Web Functions を触ってみた〜SSE で「1 環境が複数リクエストをさばく」様子を Event Functions と比べる〜

Posted at 2026-10-27

はじめに

こんにちは、ほうき星 @H0ukiStar です。

2026 年 10 月 12 日に Lambda Web Functions が GA しました。コードが HTTP リクエストを直接受け取れる、新しいタイプの Lambda 関数です。

今回は、この Lambda Web Functions について概要を整理したうえで、実際に SSE を使ったデモで「1 環境が複数リクエストを同時に処理する」様子を従来の Lambda と比較してみましたので、その内容をご紹介します。

本記事は JAWS-UG 彩の国埼玉支部 #12 で登壇した内容をベースに、改めて記事としてまとめ直したものです。
LambdaWebFunctionsを試してみた

Lambda Web Functions とは

Lambda Web Functions は、コードが HTTP リクエストを直接受け取れる新しい Lambda 関数です。これまでの Lambda で Web フレームワークを動かす際の面倒ごとが、だいぶ解消されています。

特徴を整理すると以下のとおりです。

Express / Hono / 素の Node.js などを アダプター不要 でそのまま動かせる
デプロイも aws lambda-web deploy の ワンコマンド
1 環境あたり 最大 128（デフォルト 64）リクエストを同時に処理
選べるランタイムは現状 Node.js 24 のみ
実行環境も現状 Arm64 / 2vCPU / 2GB に固定

ランタイムや実行環境のスペックは GA 直後の仕様で、今後のアップデートで変わる可能性があります。
最新の対応状況は公式ドキュメントをご確認ください。

アプリケーション側で意識するのは、ランタイムから渡される待ち受け先で HTTP サーバを起動することくらいです。

// ランタイムが listen 先を環境変数 AWS_LAMBDA_HTTP_ENDPOINT で渡してくる
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

// 受け取った listen 先を使って、普通の HTTP サーバを起動するだけ
app.listen(port, host);

このように、普段どおりの Web サーバを書いてそのまま listen するだけで動きます。

既存の Lambda は "Event Functions" に改名

Lambda Web Functions の登場に合わせて、従来の Lambda は Event Functions に改名されました（名称のみの変更で、挙動は変わりません）。

従来の Lambda は event（辞書）を受け取って処理するモデルなので、個人的にはしっくりくる命名だと思います（上から目線）。

従来は Lambda Web Adapter が、以下のような event を HTTP リクエストへ変換してくれていました。

export const handler = async (event) => {…}

関数 URL の event 例（一部省略）

{
  "requestContext": {
    "http": {
      "method": "GET",
      "path": "/"
    }
  },
  "rawPath": "/",
  "rawQueryString": "",
  "headers": {…},
  "isBase64Encoded": false
}

Web Functions では、このような event の変換を意識する必要がなくなります。

3 つのコンポーネント構成

Lambda Web Functions は、3 つのコンポーネントで構成されています。Event Functions の概念と対応づけて理解すると分かりやすいです。

コンポーネント	役割	Event Functions での相当
Web Functions	名前や Arn を持つ最上位の箱	関数そのもの
Endpoint	HTTP トラフィックを Revision にルーティングするエントリーポイント	エイリアス
Revision	コード + 設定を保持する不変のスナップショット。デプロイごとに増える	関数バージョン

Revision がデプロイごとに積み上がっていく不変のスナップショットである点は、関数バージョンのイメージそのままですね。

この 3 つのコンポーネントの関係を図にすると、以下のようなイメージです。

料金

課金要素は 3 つです。

リクエスト：$0.30 / 100 万リクエスト
メモリ：$0.0000042688 / GB - second
アクティブ vCPU：$0.0000322421 / vCPU - second

ポイントは アクティブな CPU 時間に対して課金される ところです。そのため、DB アクセス・外部 API 呼び出し・AI 推論などの待ち時間には課金されないのが特徴です。

なお、これはあくまで CPU の話で、メモリは少し性質が異なります。CPU がアクティブな時間だけの課金なのに対し、メモリは実行環境が存在する間、リクエストの合間も含めて継続して課金される 点は意識しておくのが良いでしょう。

You pay for requests, the CPU time your code actively uses, and the memory consumed by each execution environment for as long as it runs.

参考までに、Event Functions の料金は以下のとおりです。

リクエスト：$0.20 / 100 万リクエスト
メモリ：$0.0000133334 / GB - second

数字だけを並べると、Event Functions のメモリ単価（GB-second）が Web Functions より高く見えてしまいますが、ここは単純に比較できないところです。Event Functions は割り当てたメモリ量に比例して CPU やその他のリソースが割り当てられる料金体系で、メモリ料金の中に実質的に CPU 分が含まれている ため、メモリ単価だけを横並びにした比較はできません。

上記はいずれも東京リージョンの参考価格で、別途データ転送費等もかかります。
最新かつ正確な価格は必ず公式の料金ページをご確認ください。

Lambda Web Functions を触ってみる

ここからがこの記事の本題です。「1 環境が複数リクエストを処理できること」を実際に確認してみます。

今回は SSE（Server-Sent Events）を用いて、継続した複数の接続を観測するデモを作成しました。接続を開きっぱなしにしておき、サーバ側から「今、この環境が何本の接続を抱えているか」を 2 秒ごとにクライアントへ push します。

これを Event Functions（Lambda Web Adapter 構成）と Web Functions の両方で用意し、挙動を比較してみます。

なお、デモに使用したサンプルコード一式は以下のリポジトリに置いています、詳細はこちらを参照してください。

デモの構成

リポジトリには、同じ SSE デモを 2 つの方式で実装したサンプルを用意しています。

ディレクトリ	方式	概要
`web-functions-sse`	Lambda Web Functions	アダプター不要。標準の Node.js HTTP サーバが `AWS_LAMBDA_HTTP_ENDPOINT` を読んで listen するだけ。`aws lambda-web deploy` でデプロイ
`event-functions-web-adapter-sse`	Event Functions + Lambda Web Adapter	従来型 Lambda に Lambda Web Adapter をレイヤーとして足した構成。AWS SAM でデプロイ

どちらのサンプルも、以下の 3 つのエンドポイントを持つシンプルな作りです。

GET / … 接続状況を可視化するダッシュボード（ブラウザで開く）
GET /events … SSE ストリーム。2 秒ごとに instanceId と activeConnections を push
GET /status … 現在の instanceId / activeConnections を JSON で返す

ダッシュボードから接続を並行してまとめて増やすと、Web Functions では instanceId が揃ったまま activeConnections が増える（= 1 環境が相乗り）のに対し、Event Functions では instanceId が接続ごとに必ず別々になる（= 1 環境 = 1 リクエスト）様子が見えます。ここが両者のいちばんの違いです。

どちらのサンプルもエンドポイントは認証なしの公開設定です。評価用途にとどめ、不要になったら削除しておくのが良いでしょう。

Event Functions の場合

まず従来の Event Functions（LWA）でのデモです。実際に接続を増やしていく様子が以下になります。

1 環境あたりの同時接続数：1
- 並行して張った接続は instanceId が必ずすべて別々になり、各環境の activeConnections も必ず 1 になります
最大環境数：同時に捌けるリクエストの上限はアカウントの同時実行数（concurrency）に依存します

つまり 1 リクエスト = 1 環境で、接続を増やした分だけ別々の環境が立ち上がることが分かります。

Web Functions の場合

次に Web Functions でのデモです。同じように接続を増やしていくと、先ほどとは違う挙動が見られます。

1 環境あたりの同時接続数：Revision の設定項目 maxConcurrencyPerEnvironment が、同時に受け付けられるリクエストの最大値になります
- デモでは 2 にしているため、各環境の activeConnections は 2 で頭打ちになりますが、1 環境で複数のリクエストを捌けている ことが確認できます
最大環境数：Endpoint の設定項目 Maximum environments が最大環境数になります
- デモでは 2 にしているため、5 接続目以降は 429 が返ってきます

今回のデモで返ってくるのは、同時実行の上限に達したことを示す 429 Too Many Requests です。これとは別に、環境がまだ起動しておらず処理を引き受けられない場合などには 503 Service Unavailable が返ることもあります。クライアント側でリトライを実装する際は、この 2 つを区別してハンドリングしておくと安心です。

Event Functions では 1 接続につき 1 環境だったのに対し、Web Functions では 1 環境が複数の接続をまとめて抱えられる、という違いがはっきり見えました。

環境のライフサイクルの違い

この違いを環境のライフサイクルの観点で整理すると、以下のようになります。

Event Functions：1 環境 = 1 リクエスト
- 同時に複数リクエストが来た場合は、同時実行数を上限に環境がコールドスタートする

Web Functions：1 環境で複数リクエストを同時に処理
- デフォルト 64、最大 128 を同時に処理できる
- その分、コールドスタートを低減できる

リクエストが集中したときに、Event Functions は環境を次々に立ち上げてさばくのに対し、Web Functions は 1 つの環境で複数のリクエストをまとめてさばく、というイメージです。
結果としてコールドスタートの発生が抑えられます。

さいごに

今回は Lambda Web Functions について、概要の整理と SSE デモによる同時接続の比較を通してご紹介しました。

ポイントをまとめると以下のとおりです。

HTTP を直接待ち受ける Lambda で、従来 Event Functions で必要だった Lambda Web Adapter が不要になる
1 環境が複数のリクエストを同時に処理でき、その分コールドスタートを低減できる
アクティブ CPU 課金のため、I/O 待ちに強く、SSE / ストリーミング系との相性も良い

特に「1 環境で複数リクエストをさばける」「待ち時間に課金されない」という 2 点は、Web アプリケーションや外部 API・AI 推論を挟むようなワークロードと相性が良いと思います。実際にご自身のアプリケーションを aws lambda-web deploy で載せ替えてみると、挙動の違いが体感できて面白いかと思います。

この記事が、Lambda Web Functions を触ってみる際の一助になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Lambda Web Functions を触ってみた 〜SSE で「1 環境が複数リクエストをさばく」様子を Event Functions と比べる〜