Lambda Web Functionsは通常のLambdaと何が違う？ ColdStart・Idle・コスト・使いどころを整理

Lambda Web Functionsは通常のLambdaと何が違う？ ColdStart・Idle・コスト・使いどころを整理する

本記事は2026年10月時点の公式ドキュメントと料金ページを基に整理しています。料金は特記がない限り US East (N. Virginia) / Arm の単価です。

TL;DR

• Lambda Web Functionsは、HTTPサーバーをそのまま動かすLambda。1環境で複数リクエストを同時に処理する
• 既存のLambdaは Lambda Event Functions に改名された（名称のみの変更で、コードの修正や再デプロイは不要）
• ColdStartは起きにくいが、トラフィックがゼロになると環境もゼロまで縮退し、次のリクエストはColdStartになる。最低稼働数の設定はない
• Idle中はメモリの消費量に応じた課金が続く。CPUはアクティブな時間だけ課金される
• 低〜中トラフィックやPRプレビュー環境に向いている。高負荷が常に続くならECS Fargateの方が有利

Lambda Web Functionsとは

2026年10月12日に発表された、新しいサーバーレスのコンピューティング基盤です。

• コードがポートで待ち受け、HTTPリクエストを直接処理する
• Express、Hono、React Routerなどをアダプターなしで利用できる
• HTTPSエンドポイントが標準で付き、レスポンスのストリーミングにも対応
• マルチリージョンへの配置と、レイテンシベースのルーティングに対応
• 対応ランタイムは Node.jsのみ。東京リージョンでも利用可能

Event Functions（従来のLambda）との違い

観点	Event Functions（従来）	Web Functions
プログラミングモデル	handler関数がイベントを受け取る	ポートで待ち受けるHTTPサーバー
同時実行	1環境＝1リクエスト	1環境で複数（maxConcurrencyPerEnvironment 既定64、範囲1–128）
ColdStart対策の機能	Provisioned Concurrency、SnapStart	ヘッドルーム（予備の環境）の自動確保のみ。最低／予約環境数の設定はない
初期化の制約	Init phase	AWS_LAMBDA_HTTP_ENDPOINT で10秒以内に待ち受けを開始する必要がある
Idle中の状態	環境を凍結（Freeze）	環境は存続し、使われなくなれば縮退してゼロになる
Idle中の課金	なし	メモリ料金が継続する
終了処理	制御できない	ドレイン後に SIGTERM。後処理の猶予は1秒
環境スペック	メモリとCPUを選べる	1環境あたり2 vCPU／2 GB（Arm64）
ランタイム	多言語	Node.jsのみ
主な用途	キュー、S3、イベント処理	SSR、API、ストリーミング、Webhook

実行環境のライフサイクル

フェーズ	内容
Initialization	コードの読み込み → ランタイムの準備 → サーバーの起動 → listenを検知。初期化中はリクエストを受け付けない
Ready	maxConcurrencyPerEnvironment を上限にリクエストを受け付ける
Shutdown	新しいリクエストの振り分けを停止 → 処理中のリクエストをできる範囲で完了 → SIGTERM → 1秒後に強制終了

SIGTERM で行う後処理は1秒以内に終える必要があります。ただし、シャットダウン時の処理が必ず実行されるとは限らない（ハードウェア障害など）ため、重要なデータの保存をここに頼ってはいけません。

process.on('SIGTERM', () => {
  // ログのフラッシュなど、1秒以内に終わる処理だけを行う
  process.exit(0);
});

ColdStartはいつ起きるのか

ColdStartが起きるのは、主に次の2つのケースです。

1. リクエストの急増がヘッドルームの範囲を超えたとき
   既存の全環境が同時処理の上限に達し、新しい環境の起動を待つ場合
2. ゼロまで縮退した後の最初のリクエスト

1環境で数十リクエストを同時に処理でき、ヘッドルームも自動で確保されます。そのため、トラフィックが途切れない本番サイトではColdStartはあまり問題になりません。

一方、夜間にアクセスがなくなる社内システムや小規模サイトでは、朝一番のリクエストが毎回ColdStartになります。

ColdStartを短くする

• デプロイパッケージを小さくする
• 先にlistenを開始し、重い初期化はその後に行う（ハンドラーは共有のPromiseをawaitして完了を待つ）
• DB接続や外部クライアントは遅延初期化する

補足：同時実行数の上限は「学習」される

1環境あたりの同時実行数の上限は、Lambdaがリソースの使用状況から自動で調整します。新しく作った関数は控えめな値から始まりますが、学習結果はゼロまで縮退しても保持されます。負荷試験は2回目以降の結果で評価しましょう。

一度立ち上がった環境はどれくらい維持されるのか

公式ドキュメントに記載はありません。 書かれているのは「Lambdaはいつでも環境を削除しうる。特定の期間維持されることを前提にしない」という点だけです。

• Idle状態から何分でゼロまで縮退するかは、実測が必要（CloudWatchの EndpointActiveEnvironments で確認できる）
• /tmp やメモリ上のキャッシュは環境が存続している間は残るが、永続化には使わず、DynamoDBやS3などへ保存する

コスト

Web Functionsの料金体系

課金項目	単価
Active vCPU	$0.0000276944 / vCPU秒（約$0.10 / vCPU時）
Memory	$0.0000036667 / GB秒
Requests	$0.30 / 100万件
データ転送	標準のAWSデータ転送料金

ポイントは次の2点です。

• CPUは実際に処理している時間だけ課金される。DBや外部APIの応答待ちの間はほぼ課金されない
• メモリは割り当て量（2 GB）ではなく消費量で課金される。ただしIdle中も環境が存在する間は課金が続く

公式の料金例（SSRアプリ、月1,500万リクエスト、1リクエストあたりアクティブCPU 40ms、消費メモリ0.49 GB、1環境が常駐）では、月額は約**$25.78**です。

ECS Fargateとの比較（目安）

項目	Web Functions	ECS Fargate
CPU	アクティブな時間のみ課金	起動中は常に課金（約$0.032 / vCPU時、Arm）
メモリ	消費量で課金	割り当て量で常に課金
リクエスト	$0.30 / 100万件	なし
前段のLB	不要（HTTPSエンドポイントが付属）	ALBが必要（約$16/月＋LCU）
最小構成	Idle時はほぼ$0	2タスク＋ALBで概ね$30/月以上

Fargateの単価は参考値です。東京リージョンは単価が高くなります。最終判断には AWS Pricing Calculator を使ってください。

損益分岐の目安

• Web FunctionsのCPU単価は、Fargateの約3倍
• CPUがほぼ常時稼働している状態（Fargateで換算して平均利用率が約30%を超える状態）が続くなら、Fargateの方が安い
• 月間のリクエスト数が数億件規模になると、リクエスト料金だけでも無視できない

ColdStart対策で定期アクセスした場合のコスト

公式例の条件（0.49 GBの環境を1か月常駐）では、メモリ料金は約$4.66/月です。定期的なアクセスで環境を保つ方法は、費用面では現実的です。

定期アクセスで環境を保つのは公式に推奨された方法ではありません。どの間隔でアクセスすれば維持されるのかも公開されていないため、実測してから判断してください。

どういう使い方が向いているか

用途	推奨	理由
PRごとのプレビュー環境	◎ Web Functions	Idle中は$0。ALBのルール管理が不要で、片付けも簡単
低〜中トラフィックのSSR、API、Webhook	◎ Web Functions	運用が軽く、従量課金が有利
LLMのストリーミング応答	◎ Web Functions	ネイティブのHTTPストリーミングに対応し、待ち時間のCPUはほぼ課金されない
夜間に完全Idleになる社内向けWeb	○ Web Functions＋定期アクセス、またはFargate	朝一番のColdStartを許容できるかで決める
高負荷が常に続くサービス	◎ ECS Fargate	CPU単価が安い
Node.js以外、2vCPU/2GBを超える、常駐処理	◎ ECS Fargate	言語・スペック・実行モデルの制約

PRごとのプレビュー環境と相性が良い

Web Functionsはリビジョン（コードと設定の変更不可なスナップショット）とエンドポイント（リビジョンへのルーティング）で構成されます。PRごとにエンドポイントを作るだけで、プレビュー環境を用意できます。

Fargateと比べた利点

• Idle中のプレビュー環境はゼロまで縮退し、ほぼ$0になる
• ALBのリスナールールやターゲットグループをPRごとに管理する必要がない
• HTTPSエンドポイントが標準で付く

注意点

• エンドポイントはインターネットから直接アクセスできる。プレビュー環境でも IamAuth＋CloudFront OAC、またはアプリ側で認証をかける
• アカウントあたりのエンドポイント数やリビジョン数の上限を確認する（使われていない古いリビジョンは上限を超えると自動削除される）
• PRごとのDB分離は別途設計が必要
• ネイティブモジュールはArm64向けにビルドする

まとめ

• Web Functionsは「HTTPサーバーをそのまま載せられるLambda」。1環境で複数リクエストを同時に処理するため、ColdStartは大幅に減る
• ただし最低稼働数の設定はなく、ゼロまで縮退した後はColdStartになる。Idle状態がどれくらい維持されるかも非公開
• コストは低〜中トラフィックや変動の大きい負荷で有利。高負荷が常に続くならFargate
• 最も分かりやすく効果が出るのは、PRごとのプレビュー環境

参考

• AWS Lambda announces Lambda Web Functions
• AWS Lambda Web Functions - Developer Guide
• Scaling behavior for Lambda Web Functions
• Execution environment lifecycle
• Best practices for Lambda Web Functions
• AWS Lambda pricing