AWSはAWS Lambda Web Functionsを発表した。これはLambdaに追加された新しい形式で、従来のイベントハンドラーのモデルに合わせてコードを書き直すことなく、ウェブアプリケーションや標準的なHTTPサーバーを直接実行できる。Express、Hono、Fastify、Next.js、または任意のNode.jsフレームワークで構築したアプリケーションを、専用のアダプターや追加のインフラストラクチャ管理なしに、1つのコマンドでデプロイできる。
このサービスは、ウェブアプリケーション、API、サーバーサイドレンダリング、同時リクエストを処理するI/O負荷の高いインタラクティブなHTTPワークロードを対象としている。
Lambda内で異なる実行モデル
AWSは現在、すべてがFirecrackerの分離技術を基盤とする、3つの異なる実行モデルをLambda内で提供している。Event Functionsは、イベント処理、メッセージ消費、AWSサービスから発生する呼び出しに引き続き適しており、ハンドラーが1つのイベントを受け取り、従来のモデルに従ってレスポンスを返す。
一方、Web FunctionsはネイティブなHTTPモデルを使用し、アプリケーションがポートをリッスンして標準的なリクエストを処理する。1つの実行環境で最大128件の同時リクエストを処理できる。3つ目のモデルであるLambda MicroVMsは、信頼できないコードやユーザーが生成したコードを実行するため、分離された環境、永続的な状態、顧客が管理するライフサイクルを提供する。
開発者にとって実際に何が変わるのか
AWSによれば、Web Functionsはウェブアプリケーションをグローバルに配信するために複数のコンポーネントを組み合わせる必要性を減らす。このサービスはスケーリング、リージョン間のレプリケーション、レイテンシーに基づくルーティングを担い、コードは開発者がローカルで実行するHTTPサーバーに近い状態に保たれる。
Web Functionsの料金はプロセッサーの使用時間に基づき、メモリは実行環境が存在する全期間について課金される。そのため、アプリケーションがデータベースクエリやAPI呼び出しを待機している時間は、プロセッサー時間をほとんど消費しない。これは、サーバーサイドレンダリング、API、トークンをストリーミングするAI推論エンドポイントなど、I/Oに大きく依存するワークロードに適したモデルとなる可能性がある。
ただし、すべてのアプリケーションで自動的にコストが下がることを意味するわけではない。結果は、利用パターン、環境の存続時間、メモリ消費量、リクエスト量によって異なる。
デプロイ、分散、バージョン
AWS CLIでは、aws lambda-web deployのようなコマンドを使用してコードをパッケージ化し、Web Functionを作成し、最初のリビジョンをデプロイして、HTTPSエンドポイントを関連付ける。アプリケーションはus-east-1、eu-west-1、ap-northeast-1など複数のリージョンにデプロイでき、Lambdaは単一のグローバルアドレスを通じて、ベストエフォート方式で応答時間が最も短いリージョンへリクエストをルーティングする。
このサービスは各バージョンを、変更不可能なコードのスナップショットとして扱う。また、エンドポイントを使用してバージョン間でトラフィックを分散でき、例えばリクエストの90%を現在のバージョンへ、10%を新しいバージョンへ送るcanary方式の段階的リリースにも対応する。
CloudFrontとの統合と初期提供
Web FunctionのエンドポイントはAmazon CloudFrontのオリジンとして使用できる。これにより、静的アセットはネットワーク上にキャッシュされ、動的なリクエストはWeb Functionへ送られる。AWSはCloudFrontのオリジンアクセスコントロールをエンドポイントに関連付けることもサポートしており、指定されたドメインだけがエンドポイントを呼び出せるようにして、エンドポイントの公開やアプリケーション内に専用の認可メカニズムを追加する必要を避けられる。
サービスは提供開始時点で、US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Asia Pacific (Tokyo)、Europe (Ireland)で利用できる。初期段階ではArm64上のNode.js 24（nodejs24.x）を使用し、プライベート仮想ネットワーク内のリソースへアクセスするためのAmazon VPC接続をサポートする。