AWS Lambda Web FunctionsのPython対応｜2026年10月時点の結論

AWS

※この記事にはプロモーションが含まれます

AWSから「Lambda Web Functions」が発表されて、正直かなりテンションが上がりました。ただ、Pythonで書く前提で調べ始めたら「あれ、まだPythonで使えない…？」となったので、自分用に整理しておきます。

実はLambdaでAWSの日次コストを集計してWebページに出すところまで作っていて、表示部分だけ3か月くらい放置しています。HTTPサーバーをそのまま載せられるなら、これを機に作り直せるかも…と思ったのが調べ始めたきっかけです。

この記事でわかること

  • Lambda Web Functionsが何なのか、これまでのLambdaと何が違うのか
  • 2026年10月時点でのPython対応状況
  • Pythonで今すぐ「Webサーバー的なLambda」を動かす方法（Lambda Web Adapter）
  • マルチ同時実行と「アクティブCPU課金」の考え方を、手元のPythonで確かめた結果

Lambda Web Functionsとは？ざっくり仕組みを整理

Lambda Web Functionsは2026年10月12日に発表された、Lambdaの新しい形態です。いちばんの特徴は、イベントハンドラーを書かずに、普通のHTTPサーバーをそのまま動かせるところです。

これまでのLambdaは handler(event, context) でJSONのイベントを受け取って、レスポンスを返す形でしたよね。Web Functionsでは、コードがポートをlistenして、HTTPリクエストを直接受け取ります。Lambda側がHTTPSエンドポイントを用意してくれて、トラフィックに応じたスケール（アイドル時はゼロまで）も面倒を見てくれるそうです。

今回の発表で、Lambdaは3つの形態に整理されました。

  • Lambda Event Functions：これまでのLambda関数のこと。名前が変わっただけで、コードの変更や再デプロイは要らないとのこと
  • Lambda Web Functions：今回の新顔。HTTPネイティブで、1つの実行環境が複数リクエストを同時に処理する
  • Lambda MicroVMs：状態を持てる隔離サンドボックス環境

3つともFirecrackerベースの分離技術の上に乗っていて、プログラミングモデルの違いで使い分ける、という位置づけらしいです。

ところで既存のLambdaが「Event Functions」と呼ばれるようになったので、しばらくはブログ記事やドキュメントを検索するときに混乱しそうですね。「Lambda関数」と書いてある古い記事は、だいたいEvent Functionsのことだと思って読めばよさそうです。

Event Functionsとの違い｜課金と同時実行がポイント

個人的にいちばん大きいと思ったのは課金モデルの違いです。調べた範囲で、主な違いをまとめるとこんな感じでした。

  • 実行モデル：Event Functionsは handler(event, context)、Web Functionsはポートで待ち受けるHTTPサーバー
  • 同時実行：Event Functionsは1環境につき1リクエスト。Web Functionsは1環境で複数リクエストを並行処理（1〜128で、デフォルトは64）
  • 課金：Event Functionsは実行時間（壁時計時間）×メモリ。Web Functionsはリクエスト数＋アクティブCPU時間＋実行環境が消費するメモリ＋データ転送
  • タイムアウト：Web Functionsは1リクエスト最大15分、デフォルトは30秒
  • デプロイ：.zipでデプロイ。複数リージョンにまとめて配置して、レイテンシーベースでルーティングすることもできる

「アクティブCPU課金」がミソで、DBのクエリや外部APIの応答を待っている間のCPU時間は課金されないそうです。LLMのAPIを叩いてトークンをストリーミングで返すようなAPIは、処理時間の大半が待ち時間なので、従来の壁時計課金だとけっこう損をしていたんですよね。発表でもAI推論エンドポイントやストリーミングAPIがユースケースとして最初のほうに挙がっていて、まあ狙っているのはそこだろうなと思いました。

料金の目安としては、東京リージョンでもバージニア北部でもリクエスト料金は100万リクエストあたり0.30ドルとのこと。vCPU秒・GB秒の単価もあって1ms単位で計算されるようなので、詳細は公式の料金ページで確認するのが確実です。

利用できるリージョンはバージニア北部・オハイオ・オレゴン・東京・アイルランドの5つ。東京が最初から入っているのはありがたいです。

2026年10月時点：Pythonはまだ使えない

ここが今回いちばん伝えたいところです。ローンチ時点でWeb Functionsが対応しているランタイムはNode.js（nodejs24.x）だけです。公式ドキュメントやFAQでも、Express・Hono・React RouterといったNode.jsのフレームワークが例に挙がっています。

じゃあPythonはいつ来るの？という話ですが、AWS Lambdaの公開ロードマップ（GitHubの aws/aws-lambda-roadmap）に「Python runtime support for Lambda Web Functions」というIssue（#102）が立っていて、ステータスは「Coming Soon」になっているようです。Issueの説明を読むと、FastAPI・Flask・Djangoを、UvicornやGunicornといった普通のアプリケーションサーバーで、Lambda専用のアダプターなしに動かせる形を想定しているようです。

コミュニティの記事には「Python対応は2026年Q4予定」と書いているものもありますが、自分が見た範囲ではAWS公式の日付は見つけられなかったので、ここは話半分で待つのがよさそうです。

ちなみにNode.js版はこれくらいシンプルらしいです。

import http from 'node:http';

const port = Number(process.env.LOCAL_PORT ?? 3000);

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify({ message: 'hello', path: req.url }));
});

server.listen(port);

サンプルではLambdaがポート3000にリクエストを送る前提になっていて、ロードマップのIssueには AWS_LAMBDA_HTTP_ENDPOINT という環境変数のアドレスにルーティングする、という記述もありました。デプロイはCLIで aws lambda-web deploy というコマンドを使って、関数・リビジョン・エンドポイントをまとめて作れるとのこと。

Pythonで今やるなら：Lambda Web Adapter + FastAPI

「Python対応を待てない、でもFastAPIをそのままLambdaで動かしたい」という場合は、以前からあるLambda Web Adapter（LWA）を使うのが現実的っぽいです。LWAのREADMEにも、Node.jsの新規アプリならWeb Functionsがおすすめで、それ以外のランタイムやコンテナイメージはネイティブ対応されるまでLWAを使ってね、という趣旨の案内が追加されていました。

構成はだいたいこんな感じです。

# app.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"message": "hello from FastAPI on Lambda"}

@app.get("/cost/{day}")
def cost(day: str):
    return {"day": day, "usd": 1.23}

#!/bin/bash
# run.sh（Lambdaのハンドラーにこれを指定する）
PATH=$PATH:$LAMBDA_TASK_ROOT/bin \
PYTHONPATH=$PYTHONPATH:/opt/python:$LAMBDA_RUNTIME_DIR \
exec python -m uvicorn --port=$PORT app:app

あとはLambda側で次の設定をします。

  • LWAのレイヤーをアタッチする（ARNはリージョン・アーキテクチャ・バージョンで変わるので、READMEで最新を確認）
  • 環境変数 AWS_LAMBDA_EXEC_WRAPPER=/opt/bootstrap を設定
  • 環境変数 PORT=8000（LWAが転送するポートとuvicornのポートを揃える。LWA側の設定名は AWS_LWA_PORT もあるので、使うバージョンのREADMEを確認）
  • ハンドラーを run.sh にして、実行権限を付けておく
  • Function URLかAPI Gatewayをフロントに置く

ただし注意点もあります。LWAはあくまでEvent Functionsの上でHTTPサーバーを動かすための変換レイヤーなので、Web Functionsの目玉である「1環境で複数リクエストを同時処理」や「アクティブCPU課金」は基本的に付いてきません。LWAのREADMEによると、Lambda Managed Instancesと組み合わせればマルチ同時実行にも対応しているようですが、これはまた別の話です。

なので「コードの書き方はWeb Functions的にしておいて、Python対応が来たら乗り換える」というのが今のところの落としどころかなと思っています。FastAPIのアプリ自体はLambdaに依存しない普通のコードなので、移行コストはそこまで高くならないはず…たぶん。

マルチ同時実行の効き方をPythonで確かめてみた

「待ち時間中はCPUを使わないから、そのぶん他のリクエストをさばける」というのを感覚的に掴みたかったので、asyncioでざっくりシミュレーションしてみました。1リクエストあたり「CPU処理5ms → I/O待ち200ms → CPU処理5ms」という想定です。

import asyncio
import time

def cpu_work(ms):
    end = time.process_time() + ms / 1000
    while time.process_time() < end:
        pass

async def handle_request(i):
    cpu_work(5)
    await asyncio.sleep(0.2)  # DBや外部APIの待ちのつもり
    cpu_work(5)

async def main(n):
    wall0, cpu0 = time.perf_counter(), time.process_time()
    await asyncio.gather(*(handle_request(i) for i in range(n)))
    wall = time.perf_counter() - wall0
    cpu = time.process_time() - cpu0
    print(f"requests={n:3d}  wall={wall:.2f}s  cpu={cpu:.2f}s  cpu/wall={cpu / wall:.0%}")

for n in (1, 16, 64):
    asyncio.run(main(n))

print("1件ずつ順番に処理した場合の壁時計時間(目安):", f"{64 * 0.21:.2f}s")

手元で動かした結果はこんな感じでした。

requests=  1  wall=0.21s  cpu=0.01s  cpu/wall=5%
requests= 16  wall=0.29s  cpu=0.16s  cpu/wall=56%
requests= 64  wall=0.64s  cpu=0.64s  cpu/wall=100%
1件ずつ順番に処理した場合の壁時計時間(目安): 13.44s

1リクエストだけだと、0.21秒のうちCPUを使っているのはたった5%。壁時計時間で課金されるEvent Functionsだと、残りの95%は「待っているだけなのにお金がかかっている」状態です。64件を同時にさばくと、全体の時間は0.64秒で済んでいて、順番に処理した場合の約13秒と比べると差は歴然でした。

ただ、64件のところで cpu/wall が100%に張り付いているのが気になりました。Pythonのイベントループは基本1スレッドなので、同時リクエストを増やしていくと、今度はCPU処理の部分が詰まり始めるんですよね。Web Functionsは1環境あたり2vCPUという情報もあるので、Python対応が来たらワーカー数（uvicornの --workers とか）をどう設定するのがいいのか、ちょっと気になっています。ここは正直まだよくわかっていないので、実際に触れるようになったら検証したいところです。

PR（アフィリエイト広告）

そういえば、Lambdaでサーバーレスな構成を触っていると、逆に普通のWordPressサイトを立てたくなる瞬間ってありませんか。余談ですが、月額990円〜で独自ドメインも実質0円になるお名前.com レンタルサーバーを調べてたら見つけて、ちょっと気になってます。

まとめ

  • Lambda Web Functionsは「ポートをlistenする普通のHTTPサーバー」をそのまま動かせる新しいLambdaで、既存のLambdaはEvent Functionsという名前になった
  • 目玉は1環境でのマルチ同時実行と、I/O待ちを課金しないアクティブCPU課金
  • 2026年10月時点ではNode.js 24のみ対応。Pythonはロードマップで「Coming Soon」のようです
  • Pythonで今やるならLambda Web Adapter＋FastAPI。ただし課金や同時実行のメリットは別物

放置しているコスト表示ページは、とりあえずFastAPIで書き直しておいて、Python対応が来たらWeb Functionsに載せ替える作戦でいこうと思います。

タイトルとURLをコピーしました