Next.jsがほぼそのままLambdaで動く　AWSが新形態Web Functions

AWSは日本時間10月13日、普通のWebサーバーをそのままLambdaで動かせる新しい形態「Lambda Web Functions」を発表した。Next.jsやExpressのアプリを、アダプターをかませずにコマンド1本でデプロイできる。東京リージョンでも初日から使え、料金はCPUが実際に動いた時間で計算する。

アダプターなしでNext.jsが動く

これまでのLambdaにNext.jsのような待ち受け型のサーバーを載せるには、OpenNextやLambda Web Adapterのような変換役が要った。Web Functionsではそれがいらない。Lambdaが環境変数AWS_LAMBDA_HTTP_ENDPOINTに「host:port」を入れて渡すので、アプリはそこで待ち受けるだけだ。従来の関数は「Lambda Event Functions」と呼び分けるが、書き換えは不要だ。信頼できないコードを隔てて動かす「Lambda MicroVMs」と合わせ、Lambdaは3つの形を持つことになる。

AWS公式の記載では、1つの実行環境で最大128のリクエストを同時に処理する。課金はリクエスト数と、実際に使ったCPU時間とメモリで決まる。応答待ちの間はCPU料金がほとんどかからないが、メモリは実行環境がある間ずっと課金される。デプロイごとに変更できないリビジョンができ、流量を「旧90％・新10％」のように分けられる。デプロイの時に複数のリージョンを並べれば、1つの共通のURLから、呼び出し元にとって遅延が最も小さいリージョンへ、できる範囲で振り分ける。

CloudFrontの配信元にも指定でき、独自ドメインやWAFが使える。CloudFrontのオリジンアクセス制御を付ければ、Web FunctionsのURLはCloudFrontを通した時だけ呼べるようになる。この連携に追加料金はない。VPCの中の資源にもつなげる。

個人開発者にとっての意味

Claude CodeやCodexで作ったNext.jsアプリの置き場所は、まずVercelという人が多いと思う。AWSで動かすには、これまでOpenNextやAmplifyを理解する一段高いハードルがあった。今回、サーバー部分はNext.js標準のstandalone出力をほぼそのまま載せられるようになり、エージェントにデプロイまで任せやすくなった（編集部の読み）。

AWSの計算例では、月1500万リクエストのサーバーサイドレンダリングで月約25.78ドルだ（米国東部の価格での計算で、無料枠とデータ転送料を除く）。待ち時間の多いアプリほど有利な設計だ。Vercel側の一次情報は確かめていないので、料金の比較はしない。

コマンド1本での試し方

AWS CLIのaws lambda-web deployに、codeのオプションでフォルダを渡すと、HTTPSのURLが返る。AWSのブログでは、1分かからずに動くURLが返ったという。Next.jsはstandaloneで出力し、起動前にAWS_LAMBDA_HTTP_ENDPOINTの値をホスト名とポートに分けてNext.js側の変数に入れる。手元で試す時は、この環境変数を自分で決めて起動すればよい。正式なコードはAWSの公式ドキュメントで確かめてほしい。

使う前に知っておく注意点もある。対応リージョンは東京を含む5つだ。ランタイムはArm64のNode.js 24だけで、パッチ版は固定できない。メモリは1つの実行環境あたり2GBで、同時に処理するリクエスト全部で分け合う。起動から10秒以内に待ち受けを始める必要もある。1つのプロセスで多くのリクエストを同時に扱うので、グローバル変数にリクエストごとのデータを入れると混ざる。画像最適化やISRがどこまで動くかは公式に記載がなく、未確認だ。

編集部の見方

Lambdaはこれまで、イベントを受けて短く動く関数の置き場所だった。Web Functionsで、普通のWebサーバーの置き場所にもなった。AWSにすでにデータを置いている人や、東京に処理を寄せたい人は試す価値がある（編集部の読み）。一方で、画像最適化やISRがどこまで動くかは未確認で、ランタイムもNode.js 24に固定だ。プレビューの手軽さやISRを重視するなら、当面はVercelのままでよさそうだ。