AWS Lambda Web Functions登場！Node.jsのWebアプリをサーバーレスで動かす新しい選択肢
AWS Lambdaといえば、イベントを受け取って処理を実行する「関数型」の実行基盤をイメージする方が多いのではないでしょうか。
2026年10月12日、AWSは新しい実行形態「AWS Lambda Web Functions」を発表しました。
最大の特徴は、ExpressやHonoなどで作った通常のHTTPサーバーを、Lambda向けのイベントハンドラーに書き換えずにデプロイできることです。
今回は、従来のLambdaとの違い、料金モデル、マルチリージョン対応、インフラエンジニアが押さえておきたい注意点を解説します。
1. ニュースの概要
Lambda Web Functionsは、標準的なHTTP WebアプリケーションをLambda上で動かすための新しい実行形態です。
AWSによると、アプリケーションを1つのコマンドでデプロイでき、実行環境のスケーリングやHTTPSエンドポイントの提供をLambda側が管理します。
主な特徴は次のとおりです。
Express、Hono、FastifyなどのNode.jsフレームワークに対応
1つの実行環境で複数のHTTPリクエストを同時処理
CPUが実際に処理を行っている時間を基準とする課金
マルチリージョンへのデプロイとレイテンシーベースのルーティング
HTTPレスポンスのストリーミングに対応
従来のLambdaのプログラミングモデルを拡張し、Webサーバーとしての利用を簡単にするアップデートといえます。
2. AWSが公表した事実
AWSの公式発表で確認できる内容を整理します。
項目内容発表日2026年10月12日対応ランタイムNode.js対応フレームワーク例Express、Hono、Fastify、Next.jsなど同時リクエスト数1環境あたり最大128デプロイ方法AWS CLI、CloudFormation、SAM、CDKなど初期提供リージョン米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）
上記の同時リクエスト数は最大値です。実際の同時処理数は設定やリソース使用状況などによって異なります。
また、既存のLambda関数は「Lambda Event Functions」という名称に変更されました。これは名称変更であり、既存関数のコード変更や再デプロイは不要とAWSは説明しています。
3. 技術的な仕組みと変更点
3-1. イベントハンドラーではなく、通常のHTTPサーバーを動かす
従来のLambdaでは、API Gatewayなどから渡されたイベントを関数で処理する構成が一般的でした。
一方、Web Functionsでは、アプリケーションがポートをリッスンし、通常のWebサーバーと同じようにHTTPリクエストを処理します。
概念的には次のような違いです。
Lambda Event Functions： イベントを受け取り、ハンドラーで処理する
Lambda Web Functions： HTTPサーバーがリクエストを受け付けて処理する
これにより、既存のNode.jsアプリケーションをLambda向けに大きく書き換える負担を減らせます。
3-2. 1環境で複数リクエストを処理する
Web Functionsでは、1つの実行環境が複数のリクエストを同時に処理できます。
リクエストが増えるとLambdaが実行環境を追加し、トラフィックが減ると環境を縮小します。トラフィックがない場合はゼロまでスケールできます。
ただし、同時処理が増えると、データベース接続数やメモリ使用量なども増える可能性があります。アプリケーション側の設計が不要になるわけではありません。
3-3. アクティブなCPU時間を基準とした課金
従来のLambda Event Functionsでは、実行時間と割り当てメモリなどを基に料金が決まります。
Web Functionsでは、リクエスト数、アクティブなCPU時間、実行環境が存在する間のメモリ、データ転送などが料金に関係します。
AWSは、データベースや外部APIからの応答待ちでCPUを使っていない時間について、CPU時間の課金対象にしないと説明しています。
そのため、I/O待ちが多いWebアプリケーションでは、従来の実行モデルよりコンピューティングコストを抑えられる可能性があります。
ただし、メモリやリクエスト、データ転送などの料金は別途考慮する必要があります。
3-4. マルチリージョンへの展開
複数リージョンを指定すると、Lambdaがコードと設定を各リージョンへ複製し、レイテンシーベースのルーティングを行います。
利用者に近いリージョンへリクエストを振り分けることで、応答時間の短縮を目指せます。
ただし、リージョン間でデータベースの状態が自動的に同期されるわけではありません。アプリケーションのデータ設計は別途必要です。
4. インフラエンジニアへの影響
Webアプリケーションの構成を簡素化できる可能性
小規模なREST APIやWebアプリでは、EC2やコンテナの実行基盤を構築する代わりに、Web Functionsを選択肢として検討できます。
サーバーやロードバランサーの管理負担を減らせる可能性がありますが、すべての構成で最適とは限りません。
AIのストリーミングAPIにも活用できる
AIモデルの応答を少しずつクライアントへ返す場合、Server-Sent Events（SSE）などのストリーミングが役立ちます。
Web FunctionsはネイティブなHTTPストリーミングに対応しており、AI推論APIやリアルタイム性が求められるバックエンドの実行基盤として利用できます。
従来のLambdaやコンテナとの使い分けが重要
定期バッチやイベント駆動処理には従来のLambdaが適しています。一方、通常のHTTPサーバーとして動くNode.jsアプリにはWeb Functionsが候補になります。
PythonやJavaなど、Node.js以外のランタイムが必要な場合は、現時点の対応条件を確認したうえで、従来のLambdaやECSなどを検討しましょう。
5. 実際に試せること
まずは開発用のNode.jsアプリケーションで、次の点を試すと理解が深まります。
ExpressやHonoで簡単なHTTPサーバーを作成する。
AWS公式ドキュメントに従ってWeb Functionsとしてデプロイする。
HTTPSエンドポイントから応答を確認する。
並行リクエストを増やし、応答時間やエラー率を測定する。
CPU処理が多いケースと、データベースなどのI/O待ちが多いケースを比較する。
本番環境へ展開する前に、認証、レート制限、下流サービスの接続上限、エラー時の再試行なども検討しましょう。
6. 注意点と限界
対応ランタイムはNode.js
今回のWeb FunctionsはNode.jsランタイムを対象としています。PythonやJavaなどのアプリケーションをそのまま移行できるとは限りません。
同時処理は下流サービスにも影響する
1つの環境が多数のリクエストを処理すると、データベースや外部APIへの接続が集中する場合があります。maxConcurrencyPerEnvironment、maxEnvironments、rateLimit などを使って負荷を制御できます。
公開エンドポイントの認証設計が必要
エンドポイントには認証方式を設定できます。アプリケーション側で認証する方式のほか、AWS Signature Version 4などを利用するIAM認証も用意されています。
エンドポイントはパブリックインターネットから到達可能なドメインを使用するため、認証設定とアクセス制御を慎重に設計してください。
マルチリージョンは自動フェイルオーバーを保証しない
レイテンシーベースのルーティングは、常に最も健全なリージョンを選択するヘルスチェック型のフェイルオーバーとは異なります。障害時の振る舞いを理解し、必要な可用性設計を行うことが重要です。
7. 参照した公式URL
Lambda Web Functions開発者ガイド：https://docs.aws.amazon.com/lambda/latest/dg/web-functions.html
スケーリングの仕様：https://docs.aws.amazon.com/lambda/latest/dg/web-functions-scaling.html
エンドポイントの仕様：https://docs.aws.amazon.com/lambda/latest/dg/web-functions-endpoints.html
AWS Lambda料金：https://aws.amazon.com/jp/lambda/pricing/
まとめ
AWS Lambda Web Functionsは、通常のNode.js WebアプリケーションをLambda上で実行しやすくする新しい選択肢です。
複数リクエストの同時処理、アクティブなCPU時間に基づく課金、マルチリージョン配信は、Webアプリケーションの設計と運用を考えるうえで重要なポイントです。
ただし、実際の性能やコストはアプリケーションの特性、下流サービス、通信量などによって変わります。
新しいサービスだから採用するのではなく、既存のLambda・ECS・EC2と要件や運用負荷を比較する。 それが、インフラエンジニアにとって実践的な判断基準になります
