AWS Lambdaで、既存のHTTPサーバーをそのまま動かせる「Web Functions」

Expressで書いたAPIサーバーを、AWS Lambdaに載せ替えようとしたことはないだろうか。公式ドキュメントに出てくる「イベントを受け取るハンドラー関数」という書き方に、手が止まった人もいるはずだ。今あるコードをそのまま動かす方法はないのか。2026年10月12日(米国時間)、AWSがその答えになる新しい実行形態を発表した(AWS公式ブログ)。名前は「Lambda Web Functions」。Express・Hono・Fastify・Next.jsなどで書いた普通のHTTPサーバーを、書き換えずに動かせるという。

コードを書き換えずに動く

AWSの説明によると、Web Functionsが動かすのは「ポートで待ち受ける標準的なサーバー」だ。著者自身が書いた簡単なExpress.jsサーバーの例を挙げている。「ローカルでnode index.jsと打つときと同じコードで、Lambda専用のアダプターやラッパーは不要」という説明だ。

デプロイも1行で済む。

aws lambda-web deploy --name my-web-app --code ./my-app

試しに動かすだけなら、手元にコードを用意する必要すらない。

aws lambda-web deploy --name hello-world --hello-world

AWSの説明では、ここから1分以内にHTTPSのURLが手に入るという。書き換えが要らないとして、これまでのLambdaはなぜコードをそのまま動かせなかったのか。

従来のLambdaは1リクエスト1関数だった

これまでのLambda(AWSは今回「Event Functions」と呼び直した)は、1件のリクエストが来るたびに1回呼ばれる関数として書く決まりだった。たとえばexports.handler = (event) => {...}のような形だ。ポートを開いて待ち受け続ける普通のサーバーのコードとは、形そのものが違う。だからExpressのコードをLambdaへ持っていくには、リクエストをイベントへ変換する層を挟むか、コードを書き直す必要があった。

AWSは今回、Lambdaの実行形態を3つに整理した。いずれも同じFirecracker隔離技術の上で動く。

(AWS公式ブログより作成。MicroVMsは今回のHTTPサーバーの話とは別の用途で、本記事では深く扱わない)

普通のサーバーのコードがそのまま動くとなると、次に気になるのはアクセスが増えたときの挙動だ。

1つの実行環境で128件まで同時に処理する

AWSの説明では、1つの実行環境が複数のリクエストを同時に処理できる。1リクエストごとの扱いは、次のように変わった。

• Event Functions: リクエスト1件につき、新しい実行環境を1つ割り当てる
• Web Functions: 1つの実行環境が、最大128件の同時リクエストを処理する

すでに温まった環境を使い回せる分、急なアクセス増にも強くなる設計だ。複数リクエストを1つの環境で処理できるなら、課金の仕組みも変わっているはずだ。ここがこの発表の核心になる。

課金の基準がCPU時間に変わった

AWSの公式なLambda料金ページは、課金の違いを説明する例を挙げている。処理全体が200msかかり、そのうちCPUが実際に動いたのは50msだけ、というケースだ。

Event Functionsのduration課金は、料金ページの原文で「コードの実行が始まってから、戻るか終了するまでの時間」と定義されている。この定義を素直に読むと、DBやAPIの応答を待っている間も時間に含まれる。自分はここで、従来のLambdaの課金に慣れていたぶん、相手の応答を待つだけの時間にお金を払わなくていいという発想の転換に驚いた。

Web Functionsでは、料金ページが「コードが実際に処理している間だけCPUが課金される」と説明している。200msの処理のうちCPUが動いたのが50msなら、課金の対象になるのはその50msだけだ。残り150msの応答待ちは、CPU課金にはほとんど含まれない。ただしメモリは別で、実行環境が存在している間はアイドル時間も含めて課金され、複数リクエストが1つの環境を共有しているときはメモリ料金もそのぶん分け合う形になる。

DBやAPIの応答待ちが多いアプリほど、この課金方式の恩恵が大きいとAWSは説明している。SSR(サーバー側でページを組み立てる処理)やAIの推論結果をストリーミングで返す処理のように、I/O待ちの長い処理が例に挙がっている。

対応状況と試し方

発表時点でWeb Functionsが使えるのは、Node.js 24(nodejs24.x)・Arm64のみだ。リージョンも次の5つに限られる。

東京リージョンは発表時点から対応している。--regionsオプションを使えば複数リージョンへ一度にデプロイでき、グローバルなURLからレイテンシの近いリージョンへ振り分けられる。AWSはこの振り分けを「ベストエフォート」と説明しており、常に最速のリージョンに届くとは限らない。

aws lambda-web deploy --name my-web-app --code ./my-app \
    --regions us-east-1,eu-west-1,ap-northeast-1

自分のNode.jsサーバーがそのまま動くか試したいだけなら、まず--hello-worldのお試しコマンドから動かすとよい。そのあと自分のExpressサーバーへ差し替えるのが近道だろう。

まとめ

AWSが発表した「Lambda Web Functions」は、普通のHTTPサーバーのコードを書き換えずにLambdaで動かせる実行形態だ。対象はExpress・Hono・Fastify・Next.jsなどで書いたコードで、1つの実行環境が最大128件のリクエストを同時に処理する。

課金も実行開始から終了までの時間ではなく、CPUが実際に動いた時間が基準になる。DBやAPIの応答待ちが多い処理ほど、課金面の変化は大きいはずだ。発表時点ではNode.js 24・Arm64、5リージョンに限られるが、東京リージョンはすでに対応している。aws lambda-web deployコマンド1つで、1分以内に自分のサーバーを試せる。