AWS Lambda Web Functionsとは何か——Node.jsアプリをそのままデプロイできる新方式の条件と判断基準

AWSは2026年10月12日、Lambda Web Functionsの一般提供を開始しました。ExpressやFastify、Next.jsなどで書いたNode.jsのHTTPサーバーを、Lambda用のイベントハンドラーへ書き換えずにデプロイできる新しい実行方式です。アダプターは不要で、必要なコード変更は実質「Lambdaが指定するホストとポートで待ち受ける」ことだけです。一方で、提供開始時点のランタイムはArm64上のNode.js 24のみ、提供リージョンは東京を含む5つ、メモリ課金は実行環境が存在する間ずっと発生します。この記事では、採用を判断するために必要な仕様・上限・料金の考え方を整理します。

Lambdaは3つの形態に整理された

今回の発表に合わせて、従来のLambda関数はLambda Event Functionsという呼称になりました。AWSによれば名称変更のみで、既存関数のコード修正や再デプロイは不要です。現在のLambdaは次の3形態に整理されています。

• Event Functions: 従来どおりイベントをハンドラーで受け取る。キュー消費や他サービス起点の処理向け。課金は割り当てメモリ×実行時間
• Web Functions: コードがポートで待ち受けHTTPリクエストを直接処理する。1つの実行環境が複数リクエストを同時に扱い、アクティブCPU時間で課金
• MicroVMs: ライフサイクルを利用者が管理する隔離サンドボックス。信頼できないコードやユーザー生成コードの実行向け

3つは排他ではありません。AWSは、非同期のバックエンド処理をEvent Functions、ユーザー向けAPIとサーバーサイドレンダリング（SSR）をWeb Functions、対話的なコード実行をMicroVMsに割り当てるといった組み合わせを例示しています。Web Functionsの用途として挙がっているのは、SSRのWebアプリ、REST/GraphQL APIバックエンド、マイクロサービス、Webhook、LLMの応答を逐次返すストリーミングです。

コード側で必要になる変更

アプリケーションは、環境変数 AWS_LAMBDA_HTTP_ENDPOINT が示す host:port で待ち受ける必要があります。ここが一致しないとリクエストは届きません。公式ドキュメントのサンプルは、この変数を分解して app.listen(port, host) に渡すだけの数行です。ローカル実行時はこの変数が設定されないため、フォールバック値を書いておくか自分で変数を指定します。

そのほか、実装前に確認しておきたい仕様は次のとおりです。

• デプロイパッケージは.zip。既定ではルートの index.js を読み込み、変更するには AWS_LAMBDA_NODEJS_ENTRYPOINT を設定する
• Next.jsのstandaloneモードのように独自の環境変数で待受先を決めるフレームワークは、index.jsでAWS_LAMBDA_HTTP_ENDPOINTから値を渡してからサーバーを起動する
• サーバーは起動から10秒以内に待ち受けを開始する必要がある。各リクエストはリビジョンの timeoutSeconds に拘束される
• エンドポイントはHTTPSのみを受け付け、TLSはLambda側で終端する。アプリ側で証明書を扱う必要はない
• 実行環境のメモリは2GBで、Node.jsのV8ヒープ既定値は1,024MB。増やす場合は NODE_OPTIONS で指定する
• ランタイムのパッチはLambdaが自動適用し、パッチ版の固定や無効化はできない

注意が必要なのはリクエストの分離です。1つの実行環境では単一のNode.jsプロセスが複数リクエストを処理するため、リクエスト固有の情報をグローバル変数に置くと他のリクエストから参照できてしまいます。フレームワークのリクエストスコープ（Expressならreq/res）で持つのが前提です。同期的なCPU負荷の高い処理もイベントループを止め、同じ環境の他リクエストを待たせます。重い計算はworker_threadsへ逃がすか、後述の同時実行数を下げる判断が必要です。従来のEvent Functionsは1環境1リクエストだったため、この点は移行時に最も見落としやすい差分といえます。

スケーリングと上限値

スケールは「環境数」と「環境あたりの同時リクエスト数」の2軸です。環境あたりの同時実行数はLambdaがリソース使用状況に応じて動的に調整し、その上限をリビジョン設定の maxConcurrencyPerEnvironment（1〜128、既定64）で縛ります。エンドポイント側には maxEnvironments（2〜10,000、既定なし）と rateLimit（0〜10,000 rps、既定なし）があり、どちらもリージョンごとに適用されます。

加えてアカウント単位のクォータがリージョンごとに効きます。エンドポイントあたり10,000 rps、アカウント合計100,000 rps、アカウントのvCPUは2,000で、実行環境1つが2 vCPUを消費します。上限に当たったリクエストはHTTP 429で即座に拒否され、キューイングはされません（新しい環境の初期化中は待機になります）。rateLimitを0にするとHTTP 503が返ります。クライアント側にはジッター付きの指数バックオフを実装しておく必要があります。

トラフィックがなくなると環境はゼロまで縮小し、次のリクエストはコールドスタートになります。「暖機された環境が複数リクエストを吸収するためコールドスタートは起きにくい」という性質はありますが、ゼロスケールが消えるわけではない点は押さえておくべきです。設定値の調整はCloudWatchメトリクス（EndpointRequestThrottles、EndpointActiveEnvironments、EnvironmentConcurrentRequests など）を見ながら行う、というのが公式の指針です。CPUバウンドなら既定より下げてレイテンシを安定させ、I/Oバウンドなら上げて環境あたりの利用効率を高める、という方向性が示されています。

料金はアクティブCPU課金に変わる

課金要素はリクエスト数、アクティブCPU時間、実行環境が消費するメモリ、標準のデータ転送です。1ms単位で計測されます。米国東部（バージニア北部）のArmでは、アクティブvCPUが1 vCPU秒あたり0.0000276944ドル、メモリが1 GB秒あたり0.0000036667ドル、リクエストは100万件あたり0.30ドルです。Event Functionsのリクエスト単価（100万件あたり0.20ドル）より高い一方、DBや外部APIの応答待ちの時間にはCPU料金がほとんど発生しません。

AWSの試算例では、1リクエスト150ms（うちCPU 40ms）のSSRアプリを月1,500万リクエスト処理して合計25.78ドル、1リクエストが3秒開き続けるLLMストリーミング（うちCPU 200ms）で月500万リクエスト処理して33.94ドルとされています（いずれも無料利用枠とデータ転送を除き、常に1環境が稼働する前提の単純化した計算）。

ここから読み取れる判断軸は明確です。待ち時間が長くCPU使用が短いワークロードほど有利で、逆にメモリはリクエスト間の待機時間を含め環境が存在する限り積み上がるため、常時わずかなアクセスしかない用途ではEvent Functionsのほうが安くなる場合があります。短時間・高頻度の処理ではリクエスト単価そのものが総額を押し上げるため、試算では必ずリクエスト数・実測CPU時間・常駐メモリの3点を自社の値に置き換えてください。

デプロイと公開の選択肢

デプロイはAWS CLIの aws lambda-web deploy で完結し、関数の作成からHTTPS URLの払い出しまで行われます。コンソール、CloudFormation、SAM、CDK、SDKからも作成・設定が可能です。構成要素はリビジョン（コードと設定の不変スナップショット）とエンドポイント（リクエストを1つまたは2つのリビジョンへ振り分けるHTTPS URL）で、リビジョンに重みを設定すれば追加ツールなしでカナリアリリースができます。

公開面では次の点が実務上の分岐になります。

• カスタムドメインやAWS WAFを使うには、エンドポイントの前段にCloudFrontディストリビューションを置く。静的アセットをキャッシュし動的リクエストだけWeb Functionsへ流す構成も取れる
• CloudFrontのオリジンアクセスコントロール（OAC）をエンドポイントに付与でき、S3と同様の「非公開オリジン」パターンをアプリ側の独自認可なしに実現できる
• エンドポイントの認証方式はIAM認証かアプリ側管理かを選べる
• VPC接続に対応しており、VPC内のリソースへアクセスできる
• MultiRegionエンドポイントを選ぶと、指定リージョンへコードが複製され、単一のグローバルURLでレイテンシーベースのルーティングが行われる。ただしこれはベストエフォートで、常に最小遅延のリージョンへ送ることや稼働状態に基づく自動フェイルオーバーは保証されない。リージョンごとに別ドメインで公開するPerRegionも選べる

採用を判断するチェックポイント

以上を踏まえると、検討の順番は次のように整理できます。

1. ランタイム要件: Node.js 24で動くか。Python・Java・.NETやコンテナイメージが必要なら対象外で、AWS公式のLambda Web AdapterのREADMEも「他のランタイムやコンテナイメージはWeb Functionsが対応するまでAdapterを使い続ける」よう案内している
2. リージョン要件: 米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）で足りるか
3. 処理特性: I/O待ちが主体か、CPUバウンドか。後者ならイベントループのブロックと同時実行数の調整を前提に設計する
4. 状態の持ち方: グローバル変数やモジュールスコープにリクエスト固有の状態を置いていないか。既存コードの棚卸しが移行作業の中心になる
5. コスト試算: 実測のアクティブCPU時間と常駐メモリでEvent Functions・既存のコンテナ基盤と比較する
6. 通信方式: エンドポイントはHTTP/1.1で提供されるため、HTTP/2を前提とするネイティブgRPCや双方向ストリーミングは対象外。SSEやレスポンスストリーミングは追加設定なしで利用できる

新規のNode.js製Webアプリであれば、まずは小さなエンドポイントを東京リージョンに1つ立てて、コールドスタートとアクティブCPU時間を実測するところから始めるのが現実的です。

既存のNext.jsやExpressアプリの移行可否の切り分け、SSRやAI応答ストリーミングを含む構成の設計でお困りの際は、お問い合わせからご相談ください。

出典

• AWS News Blog: AWS Lambda Web Functions の提供開始について
• AWS What's New: AWS Lambda が Lambda Web Functions を発表
• AWS Lambda デベロッパーガイド: AWS Lambda Web Functions
• AWS Lambda デベロッパーガイド: Lambda Web Function のランタイム
• AWS Lambda デベロッパーガイド: Lambda Web Functions のスケーリング動作
• AWS Lambda: 料金
• GitHub: AWS Lambda Web Adapter（README の案内）
• gihyo.jp: AWS、Lambda Web Functionsを提供開始