Amazon Web Services ブログ

AWS Lambda ウェブ関数の発表

2026 年 10 月 12 日、コードをイベントハンドラーに書き直さずに標準の HTTP ウェブアプリケーションを Lambda で実行できる新しいフォームファクターである AWS Lambda Web Functions を発表しました。Express、Hono、Fastify、Next.js、または任意の Node.js フレームワークで構築された標準のポートリスニングサーバーを 1 つのコマンドでデプロイできます。Lambda は、スケーリング、マルチリージョン分布、アクティブな CPU 請求を自動的に処理します。アダプター、管理するインフラストラクチャ、フレームワークのロックインはありません。

今回の発表により、AWS Lambda は 3 つの異なるフォームファクターを提供するようになりました。各フォームファクターは同じ Firecracker 分離テクノロジーに基づいて構築され、異なるプログラミングモデル向けに設計されています。

Lambda Event Functions は、すでに Lambda 関数として知られているものです。イベント駆動型の単一同時ハンドラーモデルとウォールクロック課金方式を採用しています。「イベント関数」という名前は、そのプログラミングモデル、つまり関数がイベントを受け取って処理し、応答を返すということを強調するためです。イベント駆動型プログラミングモデルは、イベント処理、キューコンシューマー、および他の AWS サービスによってトリガーされる呼び出しに最適です。

Lambda Web Functions は、マルチコンカレント実行とアクティブ CPU 課金が可能な HTTP ネイティブプログラミングモデルを使用しています。コードはポートでリッスンし、標準の HTTP リクエストを処理します。このプログラミングモデルは、複数の同時リクエストと I/O の多い処理が標準となっているウェブアプリケーション、API バックエンド、インタラクティブな HTTP ワークロードに最適です。

Lambda MicroVMは、信頼できないコードやユーザーが生成したコードを実行するための顧客管理のライフサイクルを備えた、分離されたステートフルなサンドボックス環境を提供します。

この3つは互いに補完し合っています。アプリケーションでは、非同期バックエンド処理にはイベント関数、ユーザー向け API とサーバー側レンダリングレイヤーには Web Functions、インタラクティブなコード実行機能には MicroVM を使用する場合があります。これらはすべて同じ AWS アカウント内で同じ運用モデルを共有します。

なぜウェブファンクションなのか
最新のウェブアプリケーションでは、開発者が標準フレームワークを自由に使用して迅速に反復できるようにしながら、高速で一貫した応答時間で世界中のユーザーにサービスを提供する必要があります。今日これを構築するには、通常、複数のインフラストラクチャコンポーネントを組み立て、マルチリージョン展開を構成し、レイテンシーベースのルーティングを設定し、I/O待機による支払いを回避するための請求モデルのチューニングが必要です。開発者は、すでに所有しているHTTPサーバーをデプロイするのではなく、特定のコンピューティングモデルに合わせてアプリケーションコードを調整していることに気付くことがよくあります。

Lambda ウェブ関数はこの複雑さを解消します。各実行環境は複数のリクエストを同時に処理します（環境ごとに最大128の同時リクエスト）。つまり、各リクエストを新しいリクエストにマッピングする代わりに、大量の受信トラフィックがウォーム環境を共有できます。Web Functions はコードが使用する CPU 時間を計測するため、データベースクエリや API 呼び出しの待機時間が CPU をほとんど消費しません。メモリは、実行環境が存在する限り計測されます。サーバーサイドレンダリング、API バックエンド、トークン応答をストリーミングする AI 推論エンドポイントなど、I/O の多いウェブワークロードでは、これによりコンピューティングコストを削減できます。

試してみましょう
はじめに、単純な Express.js サーバーを作成しました。これは node index.js を使用してローカルで実行するのと同じコードで、Lambda 固有のアダプターやラッパーは必要ありません。

「エクスプレス」からエクスプレスをインポート;

const アプリ = エクスプレス ();
const [ホスト, ポート] = process.env.aws_lambda_http_Endpoint.split (':');

app.get ('/', (req, res) => {
  res.json ({メッセージ:'ラムダウェブ関数からこんにちは!'});
});

app.listen (ポート、ホスト、() => {
  console.log(`Server running on port ${port}`);
});

ローカルでの実行との唯一の違いは、 AWS_LAMBDA_HTTP_ENDPOINT 環境変数です。Lambda はこの変数を、サーバーがリッスンする必要があるホストとポートに設定します。ローカルで実行するには、自分で設定します。たとえば、AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js のように設定します。

コードの準備ができたら、 AWS コマンドラインインターフェイス (AWS CLI) を使用してデプロイしました。

aws lambda-web deploy --name my-web-app --code ./my-app

1 つのコマンド。事前のリソース設定はありません。CLIはソースをバンドルし、Webファンクションを作成し、最初のリビジョンを公開し、Webファンクションエンドポイントをアタッチして、1分以内にライブHTTPSURLを返しました。

リビジョンは、デプロイしたコードの不変のスナップショットです。エンドポイントは、トラフィックをリビジョンにルーティングしたり、トラフィックをリビジョン間で分割したりする HTTPS URL です。これらは、反復作業を行い、新しいコードへトラフィックをどのように移行させるかを制御するために使用するリソースです。

私はすぐにそれをテストしました：

<shard-id>$ curl https://<domain-id>. .lambda-web.us-east-1.on.aws/
{「メッセージ」:「Lambda Web Functionsからこんにちは!」}

次に、自分のアプリケーションがヨーロッパとアジアのユーザーに低レイテンシーでサービスを提供できるようにしたかったのです。複数のリージョンで再デプロイしました。

aws lambda-web deploy --name my-web-app --code ./my-app \
    --regions us-east-1,eu-west-1,ap-northeast-1

Lambda Web Functions は私のコードを 3 つのリージョンすべてに複製し、レイテンシーベースのルーティングを自動的に設定しました。これで、各リクエストは、ベストエフォート方式で 1 つのグローバル URL (<domain-id>.lambda-web.global.on.aws) を介して、呼び出し側のレイテンシーが最も低いリージョンにルーティングされるようになりました。。

コードを更新して同じデプロイコマンドを再度実行すると、CLIは既存の関数を検出し、新しいリビジョンをアップロードして、エンドポイントにそのリビジョンを指定しました。コード変更から本番稼働までの合計所要時間: 秒。

より段階的なロールアウトが必要なプロダクションワークフローでは、1 回の API 呼び出しでリビジョン間でトラフィックをシフトできます。

aws lambda-web update-web-function-endpoint \
    --function-name my-web-app \
    --endpoint-name dev \
    --auto-deployment-mode Disabled \
    --revision-weights 『[{「revisionId」: 「<current-revision-id>」, 「weight」: 90}, {「revisionId」: 「<new-revision-id>」, 「weight」: 10}]』

これにより、エンドポイントトラフィックの90％が現在のリビジョンに、10％が新しいリビジョンに送られるため、追加のツールなしでカナリアデプロイメントを行うことができます。

Amazon CloudFront と併用するとさらに便利に
静的コンテンツと動的コンテンツを組み合わせるアプリケーションの場合、ウェブ関数は Amazon CloudFront と併用するとうまく機能します。ウェブ関数エンドポイントを CloudFront ディストリビューションのオリジンとして選択できます。静的アセットはキャッシュから提供され、動的リクエストはWeb Functionにルーティングされるため、動的部分のサーバーレスコンピューティングで静的コンテンツのCDNパフォーマンスを実現できます。

ウェブ機能により、CloudFront のプライベートオリジンエクスペリエンスが向上します。 今回の起動では、代わりに CloudFront オリジンアクセスコントロール (OAC) をウェブ関数エンドポイントにアタッチします。CloudFront はオリジンへのリクエストに署名し、エンドポイントはディストリビューションのみがそれを呼び出すことを許可します。エンドポイントを公開したり、アプリケーションにカスタム認証を追加したりしなくても、CloudFront がすでに Amazon Simple Storage Service (Amazon S3) に提供しているのと同じプライベートオリジンパターンが得られます。

今すぐご利用いただけます
AWS Lambda Web Functions は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、および欧州 (アイルランド) でご利用いただけます。ウェブ関数は起動時に Arm64 で Node.js 24 (nodejs24.x) を実行し、Amazon 仮想プライベートクラウド (VPC) 接続をサポートします。これにより、関数が VPC 内に存在するリソースにアクセスできるようになります。

始めるには、最初の Web 関数を 1 分以内にデプロイしてください。

aws lambda-web deploy --name hello-world --hello-world

料金の詳細については、 AWS Lambda の料金表ページをご覧ください。詳細については、 Lambda ウェブ関数のドキュメントを参照してください。

原文はこちらです。