2026.10.13 AWS

Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金【2026年10月】

Q: 独自ドメインを直接設定できますか？

直接は設定できません。エンドポイントのドメインは lambda-web. .on.aws の形式で発行され、独自ドメインとAWS WAFを使うにはCloudFrontを前に置く構成が前提です。このとき認証方式を ApplicationManaged のままにすると、Lambdaのドメインを直接叩かれてCloudFrontとWAFを迂回されます。 IamAuth とOACを組み合わせてください。

Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金【2026年10月】

Lambda Web Functionsは、ポートで待ち受けるNode.jsのHTTPサーバーを、イベントハンドラーに書き換えずにLambda上で動かす実行形態です。2026年10月12日に一般提供が発表され、東京リージョンも初日から対象に入りました。同時に従来のLambda関数は「Lambda Event Functions」へ改称されています。この記事では、AWSの開発者ガイドとPrice List APIの単価データをもとに、仕組み・Expressのデプロイ手順・東京リージョンの料金試算・本番前に決める設定値を整理し、Lambda Web Adapterを使う従来の方法から乗り換えるかどうかの判断基準を示します。

まとめ：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のドメインを持ち、1つか2つのリビジョンへリクエストを振り分けます。コードを直すたびに新しいリビジョンができ、エンドポイントの向き先を切り替える流れです。

エンドポイントの種類は3つあります。1リージョンで動く HomeRegion、リージョンごとに個別のドメインを持つ PerRegion、1つのグローバルなドメインからレイテンシの小さいリージョンへ振り分ける MultiRegion です。種類は作成後に変更できません。最初は HomeRegion で始め、後述のVPC接続が要らないと確定してからマルチリージョンを検討する順番が安全です。

従来のLambdaとWeb Functionsを6項目で比べた比較表

今回の発表で、Lambdaは3つの形態に整理されました。AWS News Blogの発表記事と開発者ガイドの記載を、設計への影響が大きい順に並べています。

項目	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と似ていますが、Web Functionsはゼロまで縮み、インスタンスの床コストがありません。

Lambda Web AdapterやAPI Gateway構成から変わる3つの作業

これまでLambdaでWebアプリを動かすには、Lambda Web Adapterを拡張機能として同梱するか、serverless-http のような変換層でイベントをHTTPリクエストに直す必要がありました。ランタイムの解説は、Web FunctionsではWeb Adapterも変換層も不要だと明記しています。

実務で変わるのは、変換層の削除、API Gatewayを置かずにLambda自身のHTTPSエンドポイントで受ける構成、同時実行を前提にしたコードの見直しの3点です。従来のAWS Lambdaの仕組みにあった「1環境1リクエスト」の前提が崩れるため、移行時の不具合の多くは3点目から出ます。

ExpressアプリをCLIでデプロイしてHTTPSエンドポイントから呼ぶ手順

手元のExpressアプリを東京リージョンへ載せる最小手順です。作成手順のページによると、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の入門記事で扱っており、以下はそのまま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);
});

起動にも制限があります。実行環境のライフサイクルでは、プロセス起動から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://<domain-id>.<shard-id>.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": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "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比率で試算

公式の料金ページに掲載されているのはバージニア北部の単価と計算例だけで、東京の値は載っていません。そこで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の料金を東京リージョンの実額で計算する記事にまとめています。

スケール設定・認証・ネットワークで本番公開の前に決める3つの設定値

デプロイは1コマンドで済みますが、既定のまま本番に出すと、誰でも呼べる公開エンドポイントのまま無制限にスケールします。次の3点は公開前に決めておきます。

同時実行の上限と環境数の上限で429を防ぐスケール設定の決め方

スケーリングの解説によると、設定値は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 を既定より下げると応答時間が安定します。リクエストの上限時間は既定30秒で、超えると504が返ります。

IamAuthとCloudFront OACで直アクセスを遮断する構成と前提条件

deploy が作るエンドポイントの認証方式は既定で ApplicationManaged です。Lambdaは認証を一切行わず、ドメインを知っている人は誰でも呼べます。アクセス制御の解説では、もう1つの方式 IamAuth を選ぶと、SigV4（MultiRegionはSigV4a）で署名されたリクエストだけを受け付けます。

ブラウザ向けのサービスで実際に使う構成は、CloudFrontを前に置き、オリジンタイプ lambda・署名動作 always-amz-auth のOACで署名させる形です。関数側のリソースベースポリシーで cloudfront.amazonaws.com に lambda:InvokeWebFunctionEndpoint を許可し、aws:SourceArn で自分のディストリビューションに絞ります。S3オリジンで使うOACと考え方は同じで、OACそのものの仕組みはCloudFront OACの解説記事で確認できます。独自ドメインと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の中には入りません。ネットワーク設定の解説によると、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の新規受付停止と移行先の解説に、既存のLambda構成やVPC設計を含めた移行の見積は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を同梱する方法が現実的な選択肢です。

既存の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を組み合わせてください。