AWS Lambda Web Functionsとは？
短く答えると、Node.jsのWebアプリを「イベントを受け取る関数」ではなく「ポートで待ち受けるHTTPサーバー」のままLambdaへ載せる仕組みです。Express、Hono、Fastifyをはじめ、HTTPサーバーを起動するNode.jsフレームワークを使えます。Next.jsのstandaloneモードは、AWSが指定するホストとポートを渡す小さな起動ファイルが必要です。[1][2]
アプリはAWS_LAMBDA_HTTP_ENDPOINTという環境変数から待ち受け先を受け取り、通常のHTTPサーバーとして起動します。LambdaはHTTPSの入口、実行環境、トラフィックに応じた増減を管理し、アクセスがなければゼロまで縮退します。[3]
| 比較点 | Web Functions | Event Functions |
|---|---|---|
| プログラムの入口 | HTTPサーバーがポートで待機 | ハンドラーがイベントを受け取る |
| 1実行環境の同時処理 | 既定64、最大128リクエスト | 基本は1リクエストずつ |
| CPU課金 | アクティブなCPU時間 | 呼び出しの実行時間 |
| メモリー課金 | 環境が存在する間 | 呼び出しの実行時間に含む |
| 主な用途 | SSR、REST・GraphQL API、SSE、LLM配信 | キュー、ファイル処理、AWSイベント |
| 現行ランタイム | Node.js 24、Arm64 | 複数言語・構成 |
従来のLambdaも残り、役割が分かれます。AWSは既存方式をEvent Functionsと呼び分け、キュー処理やS3へのファイル追加など、イベント駆動の仕事には引き続きEvent Functionsを案内しています。[1][3]
料金は「待ち時間が無料」だけでは決まらない
Web Functionsの料金は、リクエスト数、アクティブCPU時間、実行環境が消費するメモリー、データ転送の4つで決まります。米国東部リージョンの例では、100万リクエストが0.30ドル、アクティブCPUが1 vCPU秒あたり0.0000276944ドル、メモリーが1GB秒あたり0.0000036667ドルです。地域や時期で変わるため、実際の見積もりは利用リージョンの料金表で確認する必要があります。[4]
AWSの料金例では月1500万リクエストのSSRアプリを、1件あたり150ミリ秒、うちCPU使用40ミリ秒、メモリー約500MBとして月25.78ドルと計算しています。別のLLMストリーミング例は1件3秒接続しても、CPU使用を200ミリ秒として見積もっています。いずれも米国東部、Arm、無料枠とデータ転送を除く仮定であり、実測値ではありません。[4]
「I/O待ちのCPUは課金されない」だけを見て、常に安くなると判断するのは早計です。実行環境のメモリーはリクエストの処理中に限らず、環境が存在する間に積算されます。CPUを長く使う画像変換や大きなJSON解析では利点も小さくなりがちです。同時処理が増えるほどメモリーを共有できますが、1件の重い処理がNode.jsのイベントループを塞ぐと、同じ環境にいる他のリクエストも待たされます。[2][3]
費用比較では次の4つを本番に近い負荷で測る必要があります。
- 1リクエストあたりの経過時間とCPU使用時間
- 実行環境の平均メモリー消費量
- ピーク時の同時リクエスト数
- CloudFront、データ転送、ログ、接続先サービスを含む総額
向くのはI/O待ちが多いHTTPワークロード
候補になりやすいのはデータベースや外部APIの応答を待つWeb API、サーバーサイドレンダリング、SSEで回答を少しずつ返すLLMの入口です。1つの環境で複数リクエストを処理し、CPUが動いていない待ち時間をCPU料金から分けられるためです。AWSの技術ブログは既定の同時実行数を64、上限を128と説明しています。上限超過時は別の実行環境へ広がり、設定した制限を超えたリクエストはHTTP 429になります。[5]
一方、次の仕事はそのまま移す理由が弱いと考えられます。
- S3、SQS、EventBridgeを起点にする非同期処理
- Python、Java、.NETなどNode.js以外で書かれたアプリ
- 1件ごとにCPUを長時間占有する処理
- 実行環境のローカル状態やセッション保持に依存する設計
- WebSocketのアップグレードが必要なアプリ
公式サンプルはExpress、Hono、SSE、マルチリージョン確認の4系統です。SSEには対応しますが、WebSocketアップグレードはサポートしないと明記されています。[6]
導入前に確認したい6つの制約
最初に確かめるべき点は言語です。2026年10月20日時点の公式ドキュメントでは、Web Functionsが対応するのはnodejs24.xだけ。実行環境はArm64、2 vCPU、2GBメモリーで、Node.jsのヒープは既定1024MBです。パッチ版の固定や自動パッチの停止はできません。[2][5]
次に、次の6点を確認します。
maxConcurrencyPerEnvironmentを既定64のまま始めてよいか- DB接続プールが複数リクエストの同時処理に耐えるか
- グローバル変数へ利用者ごとの状態を置いていないか
- カスタムドメイン、キャッシュ、WAFのためCloudFrontが必要か
- 公開エンドポイントをアプリ認証にするか、IAM認証にするか
- 東京以外への複製でデータ所在地や接続先に問題がないか
開始時の提供リージョンは米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）の5つです。独立したAWS技術者の検証でも、通常のNode.jsサーバーを配備できる点、Node.js 24とArm64のみという初期制約が確認されています。[7]
公開前にAWS SDKのサービス定義を追跡したクラスメソッドは、正式公開前後で状態が変わった経緯を整理しています。日付の古い記事では試験提供の記述が残る点に注意が必要です。[8]
移行は全面置換ではなく1経路で比べる
既存APIをすべて移す前に、I/O待ちが多く、状態を持たない1つの経路を選ぶのが現実的です。同じ入力と負荷でEvent Functions版とWeb Functions版を動かし、レイテンシ、429、CPU秒、メモリーGB秒、DB接続数、CloudFrontを含む総額を比べます。
AWSは300本のSSE接続を最大200本並行で送った例を示し、5環境、単一環境の最大同時接続59、全体のCPU使用約4.75秒と報告しています。ただし、これはAWSが用意したサンプルを特定条件で動かした結果です。一般的な業務APIの性能保証ではありません。[5]
運用ではCloudWatchの環境別ログで、リクエスト数、ピーク同時実行、CPU時間を追えます。監視基盤まで含めるなら、TechCreateのCloudWatch Omniの料金と導入条件も判断材料です。AI開発環境からデプロイを自動化する場合は、AWS AI/MLスキルの使い方と費用と役割を混同せず、Web Functionsは実行基盤、スキルは開発支援として評価を分けます。
まとめ
- AWS Lambda Web Functionsは、Node.jsのHTTPサーバーをイベントハンドラーへ変換せず、1環境で複数リクエストを処理する実行方式です。
- 料金はアクティブCPUだけではなく、リクエスト、環境存続中のメモリー、データ転送も含みます。I/O待ちが多いほど有利とは限らず、実負荷での比較が必要です。
- 現時点ではNode.js 24、Arm64、2GBメモリーなどの制約があります。全面移行より、状態を持たない1経路でEvent Functionsと並行検証するのが安全です。
出典・参考
- Amazon Web Services「AWS Lambda ウェブ関数の発表」2026年10月12日
- AWS Documentation「Lambda Web Function runtimes」2026年10月20日確認
- AWS Documentation「AWS Lambda Web Functions」2026年10月20日確認
- Amazon Web Services「AWS Lambda Pricing」2026年10月20日確認
- AWS Compute Blog「Exploring AWS Lambda Web Functions for building web applications」2026年10月13日
- AWS Documentation「Web Function sample applications」2026年10月20日確認
- Aidan Steele「Some notes on Lambda Web Functions」2026年10月12日
- DevelopersIO「リリース前のAWS Lambda Web Functions（lambda-web）の仕組みを公開ソースから読み解いてみた」2026年10月4日（10月13日追記）
読者のコメント (0)
コメントを残す