Lambda Web FunctionsでHTTPサーバーを動かす｜同時処理とDB接続から考える移行判断

AWSは2026年10月12日、通常のHTTPサーバーをサーバーレスで動かすLambda Web Functionsを発表しました。ExpressやHonoなどでAPIを作っているチームは、イベントハンドラーへ書き換える方法に加え、ポートで待ち受けるアプリを配備する選択肢を持てます。ただし、起動方法が近いことと、既存環境の運用条件をそのまま持ち込めることは別です。

本稿は2026年10月27日に確認したAWS公式資料に基づく導入判断の解説です。発表当日の速報ではありません。HTTP APIの移行を検討する開発者向けに、最初に確認するランタイム、同時処理、DB接続、配備完了の判定を整理します。検証計画と計算例は本サイトの提案であり、実環境での性能測定や料金比較の結果ではありません。

HTTPサーバーとして動くことが今回の変更点

位置付けはAWSの発表ブログ、構成は開発者ガイドの概要で確認できます。Web FunctionsはHTTP要求を直接扱い、一つの実行環境で複数の要求を並行処理します。キューやファイル到着を起点とする処理はEvent Functionsと用途を分けて考えます。

採用候補として考えやすいのは、外部APIやDBの応答を待つHTTPバックエンドです。既存のイベント処理が安定しているなら、新しい方式が登場したことだけを理由に移す必要はありません。ユーザー向けAPIと非同期ジョブを一度に載せ替えず、HTTPの一経路を選んで違いを確かめると、移行の効果と問題を分けて評価できます。

発表時の提供リージョンには東京が含まれます。現在の公式ランタイム資料はNode.js 24を対応版として挙げています。別の言語や任意のNode.js版をそのまま使えると仮定せず、利用する依存関係と実行版を合わせて確認してください。

2026年10月28日追記：公式ランタイム資料の自動パッチ方針を確認しました。Web Functionsではランタイム管理コントロールを利用できず、特定のパッチ版への固定や自動パッチの無効化はできません。nodejs24.xは指定したメジャー系列の最新パッチ版へ解決されます。アプリのリビジョンを固定してもNode.jsのパッチ版まで不変になるわけではありません。パッチ版の固定が運用要件になっている既存基盤から移す場合は、この条件を採否に含めてください。

待受アドレスと起動ファイルをそろえる

アプリはAWS_LAMBDA_HTTP_ENDPOINTで指定されたhost:portで待ち受ける必要があります。ローカル用の3000番へ固定したままだと、プロセスが起動していても要求が届きません。フレームワークが独自のHOSTやPORTを読む場合も、基盤から渡される値を起動設定へ反映する経路を確認します。

次のコードは待受と簡単な応答を確認するために本稿で作成した最小例です。server.mjsとして配備する場合は、AWS_LAMBDA_NODEJS_ENTRYPOINTもそのファイルへ合わせます。既定の入口はパッケージ直下のindex.jsです。掲載例は未配備で、本番向けの認証や業務処理を含みません。

import { createServer } from 'node:http';
const address = process.env.AWS_LAMBDA_HTTP_ENDPOINT;
if (!address) throw new Error('HTTP endpoint is required');
const position = address.lastIndexOf(':');
const host = address.slice(0, position);
const port = Number(address.slice(position + 1));
if (!host || !Number.isInteger(port) || port < 1 || port > 65535) {
  throw new Error('Invalid listen address');
}
createServer((req, res) => {
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify({ ready: true }));
}).listen(port, host);

ローカルでは待受用の環境変数を自分で設定し、指定先へ要求を送ります。AWSへ配備するときは、ローカル専用値で上書きしないようにします。この応答の成功が示すのは待受とHTTP応答だけです。DB、外部API、認証、ストリーミングは、実アプリを使う別の試験で確認する必要があります。

作成手順は公式のCreating a Lambda Web Functionを参照します。CLI利用前にはaws lambda-web helpで対応コマンドの有無を確認します。既存アプリの配備ではdeployの--codeへ対象ディレクトリーを指定しますが、不要な開発ファイルや依存まで含めないよう、配備物の内容を管理してください。

Active表示とアプリの正常稼働は別

公式の作成資料は、リビジョン作成時にサーバーが待受を開始したかをLambdaが検証しないと説明しています。リビジョンとエンドポイントがActiveでもHTTP要求は失敗し得ます。管理画面の状態だけでリリース完了にせず、配備されたURLへ実際に要求を送り、期待する応答を得る確認を組み込みます。

試験は二段階に分けると扱いやすくなります。最小の疎通でプロセスと待受を確認し、次にDB接続や代表的な外部APIを含む業務経路を実行します。依存先が停止しているなら、最小の疎通だけ成功しても業務は正常ではありません。逆に外部APIの失敗だけで待受設定を変えると、原因の切り分けが難しくなります。

応答ステータス、所要時間、対象リビジョンを要求の識別情報と一緒に記録することを勧めます。開発端末の成功と配備先URLでの成功は別に残します。ログには調査に必要な情報を入れつつ、本文や秘密値を丸ごと保存しません。再現する経路を説明できる記録があれば、次の更新でも同じ判定を使えます。

同時処理を増やす前に共有状態を見直す

複数の要求は同じプロセスで重なって動きます。利用者ごとの途中状態をグローバル変数へ保存するコードは、要求をまたぐ値の混在につながります。接続プールや初期化済みクライアントの再利用と、要求固有データの保存を分けてください。利用者、入力、応答オブジェクトをどこに保持しているかを、非同期処理の境界まで追って確認します。

例えば共有変数へ対象IDを入れ、外部APIを待った後でその値を読むコードは、別要求に上書きされる可能性があります。要求の引数やローカル変数で値を保持し、完了まで同じ対象を参照する設計へ直します。一時ファイルにも固定名を使わず、同時処理同士が上書きしない名前と削除条件を持たせます。

CPU負荷の高い同期処理も確認対象です。一要求が長い計算をしている間、ほかの要求も待たされる構成では、同時実行数を上げても処理能力は比例しません。重い変換と軽いAPIが同居する場合は、処理を分ける案も比較します。asyncという構文を付けたことだけで、計算が別スレッドへ移ったと解釈しないでください。

2026年10月29日追記：公式ランタイム資料のメモリー条件では、一実行環境は2 GB、既定のV8ヒープは1,024 MBです。ヒープだけでなくBuffer、ネイティブ割り当て、ランタイム、並行要求も2 GB内に収めます。NODE_OPTIONSでヒープ上限を変えても環境全体の容量は増えません。同時処理を増やす際は、この上限を接続予算と併せて確認してください。

環境数とDB接続数を同じ計画で扱う

スケール設定はScaling behaviorの公式資料で確認します。maxConcurrencyPerEnvironmentは一環境の同時処理上限、maxEnvironmentsは環境数、rateLimitは到着率を扱います。一環境の実際の並行数はLambdaが動的に調整するため、設定上限が常に使われるわけではありません。

DB側では、各環境が持つプールの上限と環境数の増加を一緒に見ます。仮に一環境が最大5接続を開き、20環境まで増えるなら、単純な検討値は100接続です。これは実際の接続数の保証値ではなく、下流の接続予算を考える例です。ほかのアプリや管理作業が使う接続も同じDBの容量に含めます。

要求数と接続数は一対一とは限りません。一要求で複数クエリーを並行実行する処理も、プール待ちになる処理もあります。負荷試験では、API全体の時間と、接続取得待ち、クエリー時間、タイムアウトを分けて観測します。基盤を大きくするだけでは、遅くなったDBへの待ち行列を増やす結果になる場合があります。

正常な要求だけを大量に送る試験に加え、遅延や失敗を混ぜた検証も行います。依存先が遅いと、平常時よりメモリーや接続を長く占有するからです。再試行の回数と待ち時間を無制限にせず、更新処理では重複を避ける仕組みを組み合わせます。下流の障害時に増える負担まで説明できることを採用条件にします。

CPU課金だけで安くなると判断しない

公式の製品ページは、要求、アクティブCPU時間、メモリー、データ転送を料金要素に挙げています。概要資料は、I/O待ちでCPU消費が小さくても、実行環境が存在する間はメモリーの課金が続くと説明しています。待ち時間が多いから無料になる、という読み方はできません。

比較には代表的な要求の種類と割合を使います。キャッシュ応答、DBを読むAPI、重い計算、長いストリームを同じ一件として平均すると、費用の発生箇所が見えにくくなります。現行環境と候補で同じ業務量を扱い、失敗や再試行を含めた計測期間をそろえます。単価は利用リージョンと最新の公式料金で確認してください。

転送、ログ、周辺サービスまで含める範囲も事前に決めます。コンピュートだけの比較とシステム全体の比較は別の評価です。最初は一つのAPIで、応答品質を維持しながら何が変わるかを測るとよいでしょう。本稿は料金を実測していないため、具体的な削減率や移行による費用削減を保証しません。

複数リージョン化より先にデータ配置を決める

コードを利用者に近い場所へ置いても、毎回遠いDBへアクセスするなら、通信経路全体が短くなるとは限りません。利用者、アプリ、DB、外部APIの場所を書き出します。読み込みの多い経路と更新の多い経路では整合性の要求も変わります。配備先を増やす前に、依存先を含む構成を決めることが重要です。

AWSの運用上の推奨事項は、各リージョンの更新状態と部分的な配備失敗の確認を案内しています。一つのURLの成功だけで全拠点の反映完了とせず、配置先ごとの状態を確認します。必要な設定とデータがそろうまでは、単一リージョンで比較する方法でも構いません。

小さな経路から配信を切り替えて判断する

初回は、読み取り中心で依存関係を説明しやすいAPIなどへ絞ります。現行側を残し、応答本文、ステータス、遅延、エラー率を比較します。新しい版へ送る比率を増やす条件と、元へ戻す条件を先に決めます。切り戻すには旧コードだけでなく、参照する設定と配備成果物も保持する必要があります。

採否の記録には、対応ランタイム、待受の確認、代表経路の結果、接続余力、費用の比較範囲、戻し方を残します。HTTPコードを再利用できる利点を生かしながら、同時処理とスケール条件は新しく評価する。その順序なら、新サービスの試用を継続して判断できる移行計画へ変えられます。

関連記事

Node.jsのHTTPサーバー終了処理の解説は通常のサーバーの終了を学ぶ参考になります。ただし記事の猶予時間をWeb Functionsへそのまま移さず、配置先の終了仕様を別途確認してください。

参考資料

AWS：Lambda Web Functions発表（2026年10月12日）
AWS：Lambda Web Functions概要
AWS：Web Functionの作成
AWS：ランタイムと待受の仕様
AWS：スケーリングの仕様
AWS：運用上の推奨事項
AWS：製品と料金要素の概要