--- title: "Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18319/" published: 2026-10-13 updated: 2026-10-13 categories: ["AWS"] publisher: "株式会社一創" --- # Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金【2026年10月】 Lambda Web Functionsは、ポートで待ち受けるNode.jsのHTTPサーバーを、イベントハンドラーに書き換えずにLambda上で動かす実行形態です。2026年10月12日に[一般提供が発表](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-lambda-web-functions/)され、東京リージョンも初日から対象に入りました。同時に従来のLambda関数は「Lambda Event Functions」へ改称されています。この記事では、AWSの開発者ガイドとPrice List APIの単価データをもとに、仕組み・Expressのデプロイ手順・東京リージョンの料金試算・本番前に決める設定値を整理し、[Lambda Web Adapterを使う従来の方法](https://www.issoh.co.jp/tech/details/1917/)から乗り換えるかどうかの判断基準を示します。 ## まとめ：Lambda Web Functionsの要点と従来のLambdaから移すかの結論 Web Functionsは「Lambdaの運用のまま、普通のWebサーバーとして書ける」形態です。1つの実行環境が最大128件のリクエストを同時に処理し、課金はリクエスト数・実際にCPUを使った時間・環境が存在する間のメモリの3つで決まります。データベースや外部APIの応答を待つ時間には、CPUの課金がほとんど発生しません。 結論から言うと、処理時間の大半がI/O待ちのAPI、SSR、LLMの応答を流すストリーミングなら、Web Functionsへ移す価値があります。東京の単価で試算すると、1件3秒のうちCPUを0.2秒しか使わないストリーミングAPIは、従来のLambda（512MB）の約101ドルに対して約39ドルで済みます。逆に、CPUを処理時間の4分の1以上使うAPIを512MBの関数で動かしているなら、従来のLambdaのほうが安いままです。 制約も先に押さえてください。対応ランタイムはNode.js 24（arm64）だけで、WebSocketは使えず、エンドポイントのドメインは常にインターネットから到達できます。PythonやJavaの案件、閉域網に閉じたいAPIは、現時点では対象外です。 ## Web Functionsの仕組みと従来のLambda・MicroVMsとの違い Web Functionsでは、コードは「関数」ではなく「HTTPサーバー」として起動します。Lambdaが渡すアドレスで待ち受けていれば、ExpressでもHonoでもFastifyでも動作は同じです。 ### HTTPサーバーを直接動かすリビジョンとエンドポイントの2層構成 Web Functionsは「リビジョン」と「エンドポイント」の2つで構成されます。[開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/web-functions.html)によると、リビジョンはコードと設定の変更できないスナップショットで、エンドポイントはHTTPSのドメインを持ち、1つか2つのリビジョンへリクエストを振り分けます。コードを直すたびに新しいリビジョンができ、エンドポイントの向き先を切り替える流れです。 エンドポイントの種類は3つあります。1リージョンで動く `HomeRegion`、リージョンごとに個別のドメインを持つ `PerRegion`、1つのグローバルなドメインからレイテンシの小さいリージョンへ振り分ける `MultiRegion` です。種類は作成後に変更できません。最初は `HomeRegion` で始め、後述のVPC接続が要らないと確定してからマルチリージョンを検討する順番が安全です。 ### 従来のLambdaとWeb Functionsを6項目で比べた比較表 今回の発表で、Lambdaは3つの形態に整理されました。[AWS News Blogの発表記事](https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/)と開発者ガイドの記載を、設計への影響が大きい順に並べています。 | 項目 | Event Functions（従来） | Web Functions | | ---------- | ------------------------ | ----------------------- | | コードの形 | イベントを受け取るハンドラー | ポートで待ち受けるHTTPサーバー | | 同時実行 | 1環境で1リクエストずつ | 1環境で最大128リクエスト（既定の上限64） | | 課金 | リクエスト数＋実行時間（GB秒） | リクエスト数＋アクティブCPU秒＋メモリGB秒 | | リクエストの上限時間 | 900秒 | 3〜900秒（既定30秒） | | ランタイム | Node.js・Python・Javaなど | Node.js 24（arm64）のみ | | 入口 | API Gateway・関数URL・各種イベント | Lambdaが発行するHTTPSエンドポイント | 3つ目の形態であるMicroVMsは、利用者がライフサイクルを管理する状態つきのサンドボックスで、信頼できないコードの実行向けです。課金と同時実行の違いは、EC2の上で複数リクエストを並行処理する[Lambda Managed Instances](https://www.issoh.co.jp/tech/details/17767/)と似ていますが、Web Functionsはゼロまで縮み、インスタンスの床コストがありません。 ### Lambda Web AdapterやAPI Gateway構成から変わる3つの作業 これまでLambdaでWebアプリを動かすには、Lambda Web Adapterを拡張機能として同梱するか、`serverless-http` のような変換層でイベントをHTTPリクエストに直す必要がありました。[ランタイムの解説](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-runtimes.html)は、Web FunctionsではWeb Adapterも変換層も不要だと明記しています。 実務で変わるのは、変換層の削除、API Gatewayを置かずにLambda自身のHTTPSエンドポイントで受ける構成、同時実行を前提にしたコードの見直しの3点です。[従来のAWS Lambdaの仕組み](https://www.issoh.co.jp/tech/details/15407/)にあった「1環境1リクエスト」の前提が崩れるため、移行時の不具合の多くは3点目から出ます。 ## ExpressアプリをCLIでデプロイしてHTTPSエンドポイントから呼ぶ手順 手元のExpressアプリを東京リージョンへ載せる最小手順です。[作成手順のページ](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-create.html)によると、AWS CLI v2のうち `aws lambda-web` コマンドを含む版が必要で、`aws lambda-web help` が通れば使えます。 ### 環境変数で渡すポートで待ち受けるExpressコードと10秒の起動制限 Lambdaは待ち受けるホストとポートを環境変数 `AWS_LAMBDA_HTTP_ENDPOINT` に `host:port` 形式で渡します。別のポートで待ち受けるとリクエストは届きません。ランタイムは既定でパッケージ直下の `index.js` を読み込み、別のファイルにしたいときは `AWS_LAMBDA_NODEJS_ENTRYPOINT` で指定します。Express 5の書き方は[Express.jsの入門記事](https://www.issoh.co.jp/tech/details/3857/)で扱っており、以下はそのままWeb Functionsで動く形にした例です（`package.json` に `"type": "module"` を指定）。 ``` import express from 'express'; const app = express(); // Lambdaが渡す待ち受け先。ローカルでは未設定なので127.0.0.1:3000で起動する const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || '127.0.0.1:3000').split(':'); // DB呼び出しの代わり（I/O待ちの間はCPU課金がほぼ発生しない） const findOrder = async (id) => { await new Promise((r) => setTimeout(r, 200)); return { id, status: 'shipped' }; }; app.get('/health', (req, res) => res.json({ ok: true })); app.get('/orders/:id', async (req, res) => { // リクエスト固有の値はreqとローカル変数に閉じる。グローバル変数に置くと別リクエストと混ざる const order = await findOrder(req.params.id); res.json({ order, requestId: req.get('lambda-web-request-id') }); }); const server = app.listen(Number(port), host, () => { console.log(`listening on ${host}:${port}`); }); // 縮退時に届くSIGTERMの猶予は1秒。ログの書き出し程度に留める process.on('SIGTERM', () => { server.close(); process.exit(0); }); ``` 起動にも制限があります。[実行環境のライフサイクル](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-env-lifecycle.html)では、プロセス起動から10秒以内に待ち受けを始めなければなりません。大きなデータの読み込みやDB接続は `listen` の後に回し、最初のリクエストで待ち合わせる形にします。リビジョンが `Active` でも、サーバーが待ち受けたかまでは検証されません。 ### aws lambda-web deployの実行からカナリア配信までのコマンド例 初回は `deploy` コマンドが、版管理を有効にしたS3バケット・CloudWatch Logsへの書き込み権限を持つ実行ロール・関数・最初のリビジョン・`dev` という名前の `HomeRegion` エンドポイントをまとめて作ります。 ``` # 1) 東京リージョンへデプロイ（CIでは確認プロンプトを飛ばす --create を付ける） aws lambda-web deploy --name orders-web --code ./orders-web --region ap-northeast-1 --create # 2) 出力されたURLで動作を確かめる curl https://..lambda-web.ap-northeast-1.on.aws/health # 3) 自動切り替えを止め、新リビジョンへ10%だけ流す aws lambda-web update-web-function-endpoint \ --function-name orders-web \ --endpoint-name dev \ --auto-deployment-mode Disabled \ --revision-weights '[{"revisionId": "", "weight": 90}, {"revisionId": "", "weight": 10}]' # 4) 片付け（S3バケット・実行ロール・ロググループは残るので別途削除する） aws lambda-web delete-web-function --function-name orders-web --region ap-northeast-1 ``` 既定の `dev` エンドポイントは `LatestRevision` モードで、同じ `deploy` を再実行すると、新しいリビジョンが `Active` になった時点で全トラフィックが移ります。API操作で直接作る場合は注意が必要で、`autoDeploymentMode` を省略すると既定値は `Disabled` となり、新しいリビジョンへ自動では切り替わりません。 ## 東京リージョンの料金単価と従来のLambdaとの損益をCPU比率で試算 [公式の料金ページ](https://aws.amazon.com/lambda/pricing/)に掲載されているのはバージニア北部の単価と計算例だけで、東京の値は載っていません。そこでAWSのPrice List API（2026年10月12日版）から東京リージョンの単価を取り出しました。 ### Price List APIで取得した東京とバージニア北部の単価比較表 | 課金項目（arm64） | 東京 | バージニア北部 | | -------------------- | -------------- | -------------- | | Web：リクエスト（100万件） | 0.30ドル | 0.30ドル | | Web：アクティブCPU（1vCPU秒） | 0.0000322421ドル | 0.0000276944ドル | | Web：メモリ（1GB秒） | 0.0000042688ドル | 0.0000036667ドル | | Event：リクエスト（100万件） | 0.20ドル | 0.20ドル | | Event：実行時間（1GB秒） | 0.0000133334ドル | – | Eventの実行時間は、月75億GB秒までの段階の単価です。東京のCPUとメモリの単価はバージニア北部の約1.16倍で、リクエスト単価は従来のLambdaの1.5倍に上がりました。課金は1ミリ秒単位で、同じ環境で並行に処理されたリクエストはCPUとメモリの使用量を分け合う仕組みです。料金ページにWeb Functions向けの無料枠の記載は無く、計算例も無料枠を除いた額で示されています。 ### I/O待ちのAPIとLLMストリーミングで比べた月額の試算結果 料金ページの計算例2と4を、東京の単価で計算し直しました。前提は公式例と同じで、トラフィックが30日間に均等に分散し、1つの実行環境が常に動いている状態です。従来のLambdaの比較列は、arm64・512MBの関数が同じ処理時間で動いた場合の額で、無料枠は含めていません。 | 例 | 月間件数 | 処理時間／CPU時間 | メモリ | Web（東京） | Event 512MB（東京） | | ---------- | ------- | ------------- | ------ | ------- | --------------- | | I/O待ちのAPI | 1,000万件 | 200ms／50ms | 0.29GB | 22.33ドル | 15.33ドル | | LLMストリーミング | 500万件 | 3,000ms／200ms | 0.5GB | 39.27ドル | 101.00ドル | APIの例ではWeb Functionsのほうが高くなりました。CPU時間が処理時間の4分の1を占めるうえ、リクエスト単価も上がるためです。ストリーミングの例ではCPU比率が15分の1まで下がり、従来のLambdaの約4割で済みます。 単価から割り戻すと、目安は次のとおりです。従来のLambdaが512MBなら、CPU時間が処理時間の約5分の1を下回るとWeb Functionsが安くなります。1GBの関数なら約4割が分岐点です。実際には待機中の予備環境にもメモリ課金がかかるため、移行前にCloudWatchのメトリクスで環境数を確かめてから見積もってください。従来側の付帯課金を含めた単価は[Lambdaの料金を東京リージョンの実額で計算する記事](https://www.issoh.co.jp/tech/details/17740/)にまとめています。 ## スケール設定・認証・ネットワークで本番公開の前に決める3つの設定値 デプロイは1コマンドで済みますが、既定のまま本番に出すと、誰でも呼べる公開エンドポイントのまま無制限にスケールします。次の3点は公開前に決めておきます。 ### 同時実行の上限と環境数の上限で429を防ぐスケール設定の決め方 [スケーリングの解説](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-scaling.html)によると、設定値は3つあります。リビジョン側の `maxConcurrencyPerEnvironment`（1〜128・既定64）、エンドポイント側の `maxEnvironments`（2〜10,000）と `rateLimit`（0〜10,000リクエスト毎秒）です。アカウントにはリージョンごとに、エンドポイントあたり毎秒1万件、全体で毎秒10万件、vCPU 2,000個の上限があり、1環境は2vCPUを消費するため、既定ではリージョン全体で約1,000環境が天井になります。 すべての環境が埋まり、それ以上増やせないとき、Lambdaは新しいリクエストを待たせずHTTP 429で返します。クライアント側には指数バックオフとジッターつきの再試行を入れてください。`maxEnvironments` を小さく絞れば、下流のDB接続数と請求額の上限を同時に抑えられる設計です。Node.jsは1スレッドで動くため、重いJSON変換などCPUを占有する処理が多いAPIでは、`maxConcurrencyPerEnvironment` を既定より下げると応答時間が安定します。[リクエストの上限時間](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-revisions-timeout.html)は既定30秒で、超えると504が返ります。 ### IamAuthとCloudFront OACで直アクセスを遮断する構成と前提条件 `deploy` が作るエンドポイントの認証方式は既定で `ApplicationManaged` です。Lambdaは認証を一切行わず、ドメインを知っている人は誰でも呼べます。[アクセス制御の解説](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-endpoint-access-control.html)では、もう1つの方式 `IamAuth` を選ぶと、SigV4（MultiRegionはSigV4a）で署名されたリクエストだけを受け付けます。 ブラウザ向けのサービスで実際に使う構成は、CloudFrontを前に置き、オリジンタイプ `lambda`・署名動作 `always-amz-auth` のOACで署名させる形です。関数側のリソースベースポリシーで `cloudfront.amazonaws.com` に `lambda:InvokeWebFunctionEndpoint` を許可し、`aws:SourceArn` で自分のディストリビューションに絞ります。S3オリジンで使うOACと考え方は同じで、OACそのものの仕組みは[CloudFront OACの解説記事](https://www.issoh.co.jp/tech/details/3684/)で確認できます。独自ドメインとAWS WAFはエンドポイントに直接付けられないため、どちらが必要な場合もCloudFrontが前提です。CloudFrontから転送する際はビューアーの `Host` ヘッダーを渡さないでください。Lambdaは `Host` で振り分けており、別の値だと404が返ります。 組織で公開エンドポイントを禁止したいなら、条件キー `lambda:Request/WebFunctionAuthType` が `ApplicationManaged` の作成と更新を拒否するSCPを置けば、`--auth-type IamAuth` を付けない `deploy` は失敗するようになります。 ### VPC接続がHomeRegion限定になるnetwork connectorの制約 Web FunctionsはLambda管理のインフラで動き、VPCの中には入りません。[ネットワーク設定の解説](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-networking.html)によると、RDSなどVPC内の資源へ出ていくには、`aws lambda-core create-network-connector` で作る「egress network connector」をリビジョンから参照します。サブネットは異なるAZから2つ以上が必要で、インターネットへ出るにはそのサブネットからNATゲートウェイへの経路も要ります。 見落とされやすい制約は2つです。connectorを参照したリビジョンは `HomeRegion` のエンドポイントからしか使えず、マルチリージョン配信とVPC接続は両立しません。もう1つは、エンドポイントのドメインが常にインターネットから到達可能で、PrivateLinkのインターフェースエンドポイントも用意されていない点です。社内ネットワークからだけ呼べるAPIを作りたい案件は、現時点では要件を満たせません。 ## Lambda Web Functionsを採用する条件と見送るべき案件の線引き 判断を言い切ります。Web Functionsは従来のLambdaの後継ではなく、HTTPで受けてI/Oを待つ処理に寄せた別の料金モデルです。 ### 採用してよい条件と1プロセスに複数リクエストが同居するコードの前提 次の条件がそろう場合は、検証環境で試す価値があります。 - Node.jsで書かれ、処理時間のうちCPUを使う割合が2割を下回るAPIやSSR - LLMの応答やファイル生成の進捗を、Server-Sent Eventsで逐次返したい処理 - Lambda Web Adapterや変換層の保守を減らし、手元と同じサーバーコードで動かしたい既存アプリ - 新規受付を停止したApp Runnerからの移行先を探しているNode.jsのWebアプリ 前提は、1つのプロセスに最大128件のリクエストが同居することです。グローバル変数にユーザー情報を置く、`await` をまたいでキャッシュを読み書きする、といった書き方は別のリクエストのデータを返す事故につながります。App Runnerからの移行先の比較は[App Runnerの新規受付停止と移行先の解説](https://www.issoh.co.jp/tech/details/7023/)に、既存のLambda構成やVPC設計を含めた移行の見積は[AWSを含むインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)で相談できます。 ### Event Functionsや他の基盤のままにすべき場面と移行で踏む失敗 1つ目は、SQSやS3イベントを処理する非同期のジョブです。Web FunctionsはHTTPで受ける形態で、キューの処理は従来どおりEvent Functionsの役割だと開発者ガイドが明記しています。 2つ目は、CPUを使う割合が高いAPIを小さなメモリで動かしている場合です。前章の試算どおり、512MBの関数でCPU比率が4分の1を超えるなら、移すと請求額が上がります。画像変換やPDF生成のようにCPUで詰まる処理は、同じ環境の他のリクエストまで止めてしまう点でも不向きです。 3つ目は、WebSocketを使うチャットや、閉域網の中だけで呼ばれる社内APIです。どちらも現時点の仕様では実現できません。移行でよく起きる失敗は、ローカルで単発のリクエストだけを確かめて本番に出し、同時実行で初めて状態の混線を踏むことです。移す前に、同じエンドポイントを並行で叩く負荷試験を通してください。 ## よくある質問 Lambda Web Functionsについて検索されることの多い質問に、2026年10月13日時点の公式ドキュメントで確認できる範囲で答えます。 ### Lambda Web Functionsは東京リージョンで使えますか？ 使えます。提供開始時点の対象は、バージニア北部・オハイオ・オレゴン・東京・アイルランドの5リージョンです。東京の単価もPrice List APIに掲載されており、アクティブCPUは1vCPU秒あたり0.0000322421ドル、メモリは1GB秒あたり0.0000042688ドルでした。ランタイムはNode.js 24のarm64だけで、x86は選べません。 ### PythonやJavaのWebアプリもWeb Functionsで動かせますか？ 現時点では動かせません。開発者ガイドは、Node.js以外の言語にはEvent Functionsか、Lambda MicroVMsを案内しています。PythonのFastAPIやJavaのSpring BootをLambdaで動かしたい場合は、従来どおり[Lambda Web Adapterを同梱する方法](https://www.issoh.co.jp/tech/details/1917/)が現実的な選択肢です。 ### 既存のLambda関数は改称に合わせて作り直す必要がありますか？ 不要です。従来のLambda関数は名称が「Lambda Event Functions」に変わっただけで、発表文ではコードの変更も再デプロイも必要ないとされています。API Gatewayや関数URLを使った既存の構成も変更なしで動作を継続。Web Functionsへ移すかどうかは、本記事の損益試算と同時実行への対応を見て、関数ごとに決めれば足ります。 ### WebSocketやHTTP/2は使えますか？ WebSocketは使えず、Lambdaはアップグレード用のヘッダーを取り除いて転送します。サーバーから一方向に流すだけなら、Server-Sent Eventsが代替手段です。エンドポイントが受けるのはHTTP/1.1で、ブラウザとの間をHTTP/2やHTTP/3にしたい場合はCloudFrontを前に置きます。ストリーミングも上限時間の対象で、超えた時点で本文が途中で切れます。 ### 独自ドメインを直接設定できますか？ 直接は設定できません。エンドポイントのドメインは `lambda-web.<リージョン>.on.aws` の形式で発行され、独自ドメインとAWS WAFを使うにはCloudFrontを前に置く構成が前提です。このとき認証方式を `ApplicationManaged` のままにすると、Lambdaのドメインを直接叩かれてCloudFrontとWAFを迂回されます。`IamAuth` とOACを組み合わせてください。 ## 関連記事 - [Lambda Web Adapterの使い方｜WebアプリをLambdaで動かす手順とv1.1.0のSnapStart対応](https://www.issoh.co.jp/tech/details/1917/)：Node.js以外の言語でWebアプリをLambdaに載せる従来の方法と、Web Functionsとの使い分けの前提になります。 - [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15407/)：Event Functionsへ改称された従来のLambdaの仕組みと課金の基本を整理しています。 - [Lambda Managed Instancesとは？料金の実額・90分実行・標準Lambdaとの使い分け【2026年9月】](https://www.issoh.co.jp/tech/details/17767/)：同じく複数リクエストを並行処理する、EC2上の実行形態との違いを比べられます。 - [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](https://www.issoh.co.jp/tech/details/17869/)：Webアプリの載せ先をコンテナまで広げて検討するときの比較軸です。 - [サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](https://www.issoh.co.jp/column/details/13005/)：サーバーレス全体の中でLambdaとコンテナをどう選ぶかを、検討段階の視点でまとめています。 --- 出典: [Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金【2026年10月】]()（株式会社一創）