記事のポイント
- AWS Lambdaはイベント駆動のFaaSとして登場し、AWSのサービス同士をつなぐコンポーネントとしても利用されてきた
- Lambda Web FunctionsやMicroVMsの登場により、AWS Lambdaは関数だけでなくHTTPサーバーや独立した実行環境も提供するようになった
- AWS Lambdaの15分制限や他クラウドとの違いを振り返りながら、Lambdaというサービスがこれからどうなっていくのかを考える
はじめに
今回はLambda Web Functionsの細かな使い方を解説するのではなく、AWS Lambdaがこれまで担ってきた役割を振り返りながら、Lambdaというサービスのあり方について考えてみたいと思います。
2026年10月12日、AWS Lambda Web Functionsが発表されました。
Lambda Web FunctionsはAWS Lambda上でHTTPサーバーを直接実行できる新しい仕組みです。ExpressやHonoなどのWebフレームワークを利用できるほか、1つの実行環境で複数のHTTPリクエストとして処理できます。
今回の発表を見て、最初に思ったのは「これまでのAWS Lambdaと何が違うのだろうか」ということでした。というのも、LambdaでWebアプリケーションを動かすこと自体は以前から可能だったためです。
API GatewayやLambda Function URLsを使えばHTTPエンドポイントを公開できますし、Lambda Web Adapterを利用すれば既存のWebアプリケーションをLambda上で動かせます。
AWS Lambdaといえば、イベント駆動のサーバーレスコンピューティングサービスというイメージがあります。しかし、最近ではLambda Managed InstancesやMicroVMsなども登場し、従来のLambdaとは異なる実行モデルが提供されるようになりました。全体像をまとめると以下のとおりです。
個人的には今回の発表を見て、そもそもAWS Lambdaとは何だったのだろうかと考えるようになりました。
AWS Lambdaとは何なのか
AWS Lambdaは2014年11月13日に発表されたサーバーレスコンピューティングサービスです。
2024年11月13日に開催された「AWS Lambda 10周年記念生誕祭」ではLambdaが当初「S3 Scripts」という名前で構想されていたという話を聞きました。
現在ではさまざまなAWSサービスと連携できるLambdaですが、初期のLambdaを象徴するユースケースの一つがAmazon S3との連携です。
例えば、S3に画像がアップロードされるとLambdaが起動し、画像をリサイズして別のS3バケットへ保存するような処理が挙げられます。Lambdaはこのように何らかのイベントをきっかけにプログラムを実行する仕組みとして登場しました。
こうした仕組みはFunction as a Service（FaaS）と呼ばれています。FaaSでは開発者がサーバーを管理することなく、必要な処理を関数として実装できます。
Glue Lambdaという考え方
ここで思い浮かぶのがGlue Lambdaという考え方です。Glueは接着剤や糊を意味する言葉で、AWSのサービス同士をつなぐための処理をLambdaで実装する使い方を指します。
例えば、S3にファイルが保存されたことをきっかけにLambdaを実行し、データを加工してDynamoDBに保存するような処理です。
データエンジニアリングの分野でも、データの変換や外部サービスとの連携処理にLambdaを利用することがあります。
こうした使い方ではLambda自体がアプリケーションの中心になるわけではありません。AWSが提供するさまざまなサービスを組み合わせてシステムを構築するためのコンポーネントとして利用します。
もちろん、Lambdaの用途がGlue Lambdaだけに限定されていたわけではありません。APIのバックエンドやデータ処理など、幅広い用途で利用されてきました。
ただし、Glue Lambdaという考え方については、現在では少し事情が変わってきています。
例えば、EventBridge Pipesを使えば、イベントソースからターゲットへデータを連携できます。またStep FunctionsにはAWSサービスを直接呼び出すためのサービス統合機能があります。
以前であればLambdaで実装していたようなサービス間連携が、現在ではLambdaを書かずに実現できる場合もあるわけです。
実際、2025年に書いた「手を動かして学ぶ Amazon Bedrock AgentCore Code Interpreter」でもGlue Lambdaについて触れています。
ここで面白いのは従来Lambdaが担っていたサービス間連携の一部を他のマネージドサービスで実現できるようになった一方で、Lambda自体は新しい実行モデルを取り込んでいることです。
では、こうしたLambdaの使い方はどのように変化してきたのでしょうか。
S3 Object Lambdaから振り返るLambdaの使い方
Lambdaの使い方を振り返るうえで、個人的に思い出すのがAmazon S3 Object Lambdaです。
参考：【AWS】Amazon S3 Object Lambdaを検証！
S3 Object Lambdaは2021年に登場した機能でS3からオブジェクトを取得する際にLambdaを実行し、データを加工してからクライアントへ返すというS3の機能のうちのひとつです。
こういったサービスが他のCDN系サービスから出ていたことも印象に残っています。
例えば、S3に保存された画像を取得するときにLambdaで画像をリサイズしたり、透かしを追加するといった処理が可能です。図で整理すると以下のとおりです。
CloudFrontと組み合わせれば、画像などのコンテンツを配信する際にも利用できます。つまり、動的なコンテンツ配信を実現できるわけです。
S3 Object Lambdaは2025年11月7日以降、既存顧客と一部のAWSパートナーを除いて新規利用ができなくなっています。
AWSが案内している代替手段には、CloudFrontを使った動的画像変換やAPI Gateway、Lambda Function URLsなどを経由してLambdaを呼び出す方法があります。
ここで考えたいのが、Lambdaの役割です。S3 Object LambdaではS3からオブジェクトを取得するという処理にLambdaを組み込んでいました。
一方でAPI GatewayやLambda Function URLsを利用する場合は、HTTPリクエストを受け取ってLambdaを呼び出します。
どちらもLambdaを利用していますが、アプリケーションのどこにLambdaを配置するのかという点が異なります。
こうして振り返ってみると、LambdaはAWSのサービスに処理を組み込むためのコンポーネントという使い方だけでなく、HTTPリクエストを処理するバックエンドとしても利用されてきたことが分かります。
そして、今回のLambda Web FunctionsではそのHTTPを扱うための仕組みがさらに拡張されました。
Lambda Web Functionsは何を変えたのか
Lambda Web Functionsの特徴はHTTPサーバーを直接実行できることです。ただし、これまでもLambdaを使ってWebアプリケーションを構築することはできました。
例えば、API GatewayとLambdaを組み合わせれば、HTTPリクエストを受け取って処理した結果を返すことができます。
APIという名前ではありますが、レスポンスとしてHTMLを返すこともできるため、サーバーサイドでHTMLを生成するような構成も実現できます。
また、Lambda Web Adapterを利用すればExpressやNext.jsなどのWebアプリケーションをLambda上で動かせます。
以前に書いた「検証！Powertools for AWS Lambda（Python）」でも、API GatewayとLambdaを利用した構成を扱っています。
Lambda Web Functionsは何が違うのか
大きな違いは、HTTPサーバーを実行するためのモデルがLambdaの機能として正式に提供されたことです。
従来のLambda Event Functionsではイベントをハンドラーで受け取り、処理結果を返すモデルが基本でした。一方のLambda Web Functionsでは、アプリケーションがネットワークポートをリッスンし、HTTPリクエストを直接処理します。
また、1つの実行環境で複数のHTTPリクエストを並行処理できることも特徴です。課金方式も従来のLambdaとは異なります。Lambda Web Functionsでは、実際にCPUが動作している時間と実行環境で使用するメモリに対して、それぞれ料金が発生します。
例えば、データベースや外部API、LLMからの応答を待っている間は、CPUをほとんど使用しない場合があります。
こうしたI/O待機時間に対してCPU時間の課金が発生しない点はHTTPアプリケーションを実行するうえで興味深いところです。ただし、メモリやリクエスト、データ転送などの料金は別途考慮する必要があります。
さらにLambda Web Functionsでは、複数のAWSリージョンにまたがるエンドポイントやCloudFrontとのOrigin Access Control（OAC）連携にも対応しています。
単にHTTPサーバーが動くというだけではなく、Webアプリケーションを公開するための構成も考慮されているわけです。
AWS App Runnerとは何が違うのか
ここで気になるのが、AWS App Runnerとの違いです。App RunnerはソースコードやコンテナイメージからWebアプリケーションを簡単にデプロイできるサービスです。
この点だけを見ると、Lambda Web Functionsと似ているように感じます。
App Runnerは2026年4月30日から新規顧客の受付を停止しています。
既存顧客は引き続き利用できます。
AWSはApp Runnerからの移行先としてAmazon ECS Express Modeを案内しています。
ECS Express Modeはコンテナイメージを指定することでECS on FargateやApplication Load Balancer、Auto Scalingなどを含む構成を作成できる仕組みです。そのためApp RunnerがLambda Web Functionsに置き換わったというわけではありません。
むしろ、Webアプリケーションをホストする方法としてECS Express ModeとLambda Web Functionsの両方が選択肢になると考えた方がよさそうです。
- 参考：【AWS】検証！Amazon ECS Express ModeとAWS CodeBuildでアプリをデプロイ
- 参考：【AWS】手を動かしながら学ぶ AWS App Runner (Codeシリーズを利用)
ここで面白いのはコンテナの扱いです。従来のLambdaではコンテナイメージを使ったデプロイに対応しています。
しかし、Lambda Web Functionsは2026年10月時点でNode.js 24とArm64を利用したZIPパッケージによるデプロイが前提です。つまり、コンテナを動かすためのサービスとして拡張されたというよりHTTPサーバーを実行するという用途に合わせてLambdaが拡張されたと考えられます。
Webアプリケーションを公開するという観点では単にアプリケーションが動くかどうかだけを比較するのは不十分です。独自ドメイン、TLS、キャッシュ、WAF、アクセス制御、マルチリージョン構成など、Webサービスを公開するために必要な構成全体で評価する必要があります。
各サービスの違いをまとめると以下のとおりです。
そんなわけでLambda Web Functionsは従来のLambdaが扱ってきたユースケースを拡張するものだと感じます。
AWS Lambdaは15分の壁を超えることができたのか
さて、Lambdaについて語るうえでもう一つ触れておきたい話があります。それが15分の壁です。AWS Lambdaといえば、1回の関数実行が最大15分という制限があります。
そのため長時間のデータ処理やバッチ処理を実装する際には処理を分割したりStep Functionsなどを組み合わせたりする必要がありました。
以前に書いたAmazon Bedrock AgentCore Code Interpreterの検証記事でも、Lambdaの15分制限について触れています。
では、2026年現在のAWS Lambdaは15分の壁を超えることができたのでしょうか。結論から言えば、一部の実行モデルでは15分を超えられるようになりました。
Lambda Managed Instancesでは最大90分に拡張
2026年9月9日、AWS Lambda Managed Instancesにおいて、非同期呼び出しやイベントソースマッピングからの呼び出しで最大90分の関数実行が可能になりました。
これは従来の15分から6倍へ拡張されたことになります。
Managed Instancesは、AWSが管理するEC2インスタンス上でLambda関数を実行する仕組みです。
従来のLambdaとは実行基盤が異なり、インスタンスの管理やキャパシティの考え方も変わります。
この仕組みについては以前に書いた「Modern Serverless Architectures with Lambda Managed Instances」でも取り上げています。
今回の90分への拡張により、データ処理やメディア変換、AI推論などの長時間実行するワークロードにも対応しやすくなりました。ただし、すべてのLambda関数で90分まで実行できるようになったわけではありません。
Managed Instancesでも同期呼び出しの実行時間は最大15分です。また、Lambda Web Functionsにおける1つのHTTPリクエストのタイムアウトも最大15分となっています。
Lambda MicroVMsは最大8時間
もう一つ注目したいのが、2026年6月に発表されたAWS Lambda MicroVMsです。
Lambda MicroVMsは、Firecrackerを利用した仮想マシンレベルの分離を提供するサーバーレスの実行環境です。
従来のLambdaのように関数を呼び出して処理を実行するのではなく、独立した実行環境を起動し、HTTP経由でアクセスすることができます。また、実行環境の一時停止や再開、状態の保持にも対応しています。
例えば、AIエージェントが生成したコードを実行したり、ユーザーごとに独立した開発環境を提供したりする用途が考えられます。
そしてLambda MicroVMsでは、実行環境のライフサイクルを最大8時間まで設定できます。
ただし、これは従来のLambda関数が8時間連続で実行できるようになったという話ではありません。Lambda MicroVMsが提供しているのは、関数呼び出しとは異なるライフサイクルを持つ実行環境だからです。
Durable Functionsという選択肢もある
さらにAWS LambdaにはDurable Functionsという仕組みもあります。Durable Functionsはチェックポイントによって処理の進行状況を管理し、必要に応じて中断や再開を行うことで、長期間にわたるワークフローを実現するものです。
ワークフロー全体としては最大1年間の実行に対応しています。ただし、これは1つの関数呼び出しが1年間動き続けるという意味ではありません。処理を分割し、状態を保持しながら再開することで長期間のワークフローを実現しています。
ここまでを整理すると、実行時間については次のようになります。
| 実行モデル | 実行時間に関する特徴 |
|---|---|
| Lambda Event Functions | 通常は1回の呼び出しにつき最大15分 |
| Lambda Managed Instances | 対応する非同期呼び出しなどで最大90分 |
| Lambda Web Functions | 1つのHTTPリクエストにつき最大15分 |
| Lambda MicroVMs | 実行環境のライフサイクルが最大8時間 |
| Lambda Durable Functions | 中断と再開を利用したワークフロー全体で最大1年間 |
こうして見ると、現在のLambdaは15分という制限だけでは説明できないサービスになっています。ただし、重要なのは時間が延長されたことだけではありません。
Lambda Event Functions、Web Functions、MicroVMsでは、プログラムの実行方法そのものが異なります。
従来のLambdaではイベントを受け取って関数を実行し、処理が終わったら結果を返すというモデルが基本でした。
しかし、Web FunctionsではHTTPサーバーがリクエストを受け付け、MicroVMsでは独立した実行環境を維持できます。
つまり、15分の壁を超えたかどうかという話は、Lambdaというサービスの実行モデルが変化してきたことにもつながっているわけです。
AWS Lambdaは今何なのか、これから何になるのか
ここまでLambdaの歴史を振り返ってきましたが、他のクラウドに目を向けると興味深い違いがあります。
まずGoogle Cloudです。Google CloudではCloud Functionsの第2世代がCloud Run functionsとして提供されるようになり、Cloud Runとの統合が進んでいます。
Cloud Runはコンテナベースのサーバーレスコンピューティングサービスです。
Webアプリケーションをコンテナとして実行できるだけでなく、Cloud Run functionsを利用すれば関数として記述したコードも実行できます。
つまりGoogle Cloudでは、Cloud Runという実行基盤に関数のプログラミングモデルを統合する方向へ進んでいます。
一方でAzureにはAzure FunctionsとAzure Container Appsがあります。Azure Functionsはイベント駆動の処理を関数として実装するためのサービスです。
Azure FunctionsでもHTTPトリガーを利用してWeb APIを実装できますし、コンテナ化したFunctionsアプリケーションをAzure Container Apps上で動かすこともできます。
AzureにはほかにもApp ServiceやStatic Web AppsなどWebアプリケーションをホストするためのサービスが用意されています。
このように各クラウドを比較すると、FaaSとWebアプリケーションを実行する仕組みの関係に違いがあるとわかります。
| クラウド | FaaSと実行基盤の関係 |
|---|---|
| AWS | LambdaにWeb FunctionsやMicroVMsなどの実行モデルを追加 |
| Google Cloud | Cloud Runという実行基盤にFunctionsを統合 |
| Azure | Functionsのプログラミングモデルを維持しながらContainer Appsなどの実行基盤と組み合わせる |
もちろん、どのクラウドにも複数の実装方法が存在するため、これだけで単純に優劣を比較できるものではありません。
ただ、各クラウドがFaaSという概念をどのように扱っているのかという観点では興味深い違いがあると思います。
| クラウド | 進み方 |
|---|---|
| Google Cloud | Cloud Runを中心とした統合 |
| Azure | Functionsというプログラミングモデルを維持しつつ、Container Appsなどとの連携を強化 |
| AWS | Lambdaというサービスの中に、新しい実行モデルを追加 |
図でまとめると以下のとおりです。
話を戻して
ここで最初の問いAWS Lambdaとは何なのかに戻ります。もともとLambdaはイベントをきっかけに必要なコードを実行するためのサービスとして登場しました。
Glue LambdaのようにAWSのサービスをつなぐための使い方もありました。
しかし、現在ではHTTPサーバーを直接実行できるようになり、独立したMicroVMも扱えるようになっています。こうした変化を見るとLambdaを単に関数を実行するためのサービスと説明するのは難しくなってきたように感じます。
一方でLambdaの原点が失われたわけでもありません。イベント駆動のFaaSという役割は現在でも残っていますし、AWSのサービスを組み合わせたアーキテクチャを構築するうえでは重要な存在です。
では、こうした異なる実行モデルに共通するものは何でしょうか。
個人的には開発者がサーバーや仮想化基盤を直接管理することなく、必要なワークロードを実行できることなのではないかと思います。
イベント駆動はそのための方法の一つであり、HTTPサーバーやMicroVMも別の方法として提供されるようになったと考えられます。
そうすると、現在のAWS Lambdaはイベント駆動のFaaSとしての機能を残しつつ、複数の実行モデルを提供するサーバーレスコンピューティング基盤へと拡張されていると捉えることができます。
今回のLambda Web Functionsはそうした変化を象徴する機能の一つなのかもしれません。
まとめ
今回はLambda Web Functionsの登場をきっかけに、AWS Lambdaがこれまで担ってきた役割について振り返ってみました。AWS Lambdaはイベント駆動のFaaSとして登場し、S3などのAWSサービスと連携するコンポーネントとして利用されてきました。
Glue Lambdaという使い方やS3 Object Lambdaのような仕組みを振り返ると、LambdaがAWSの各サービスを組み合わせるうえで重要な役割を担ってきたことが分かります。
一方でAPI GatewayやLambda Web Adapterなどを通じてHTTPアプリケーションを実行する用途にも広がっていきました。
そして2026年にはLambda Web FunctionsやMicroVMsが登場し、従来とは異なる実行モデルが提供されるようになっています。
さらにLambda Managed Instancesでは一部の関数呼び出しについて最大90分の実行が可能になり、従来の15分という制限も変化しています。
こうして振り返ってみると、AWS Lambdaはイベント駆動の関数を実行するためのサービスとしての役割を維持しながら、さまざまなワークロードを扱うための基盤へと拡張されているように感じます。
もちろん、今後どのような機能が追加されるのかは分かりません。ただ、Lambda Web FunctionsやMicroVMsの登場を見る限りでは、Lambdaというサービスが関数の実行だけにとどまらない方向へ進んでいることは確かです。
個人的には、今後Web FunctionsがNode.js以外のランタイムやコンテナイメージに対応するのか、MicroVMsがAIエージェントの実行環境としてどのように利用されていくのかにも注目しています。
AWS Lambdaとは何なのか
今回の発表をきっかけに振り返ってみると、Lambdaはこれまでの使い方を残しながら、その役割を少しずつ変えてきたサービスなのだと思います。これからAWS Lambdaがどのようなサービスになっていくのか楽しみです。