AWS は 2026 年 10 月 12 日、普通の Node.js の HTTP サーバーをアダプター無しで動かせる Lambda Web Functions を一般提供しました。1 つの実行環境で最大 128 件を同時に処理し、待ち時間ではなくアクティブな CPU 時間に課金します。Hono での作り方、Function URL などとの違い、料金と制限、Cloudflare Workers との使い分けをまとめます。
SNSでシェアして、他のエンジニアにも教えてあげましょう
AWS Lambda Web Functions は、ポートで待ち受ける普通の Node.js の HTTP サーバーを、アダプター無しでそのまま Lambda で動かす新しい実行形態です。AWS は 2026 年 10 月 12 日に一般提供（GA）を発表しました12。1 つの実行環境が複数のリクエストを同時に処理し、データベースの応答を待つ時間ではなく、CPU が実際に動いた時間に課金されます3。
この記事では、2026 年 10 月時点の公式ドキュメントをもとに、Web Functions の仕組み、Function URL・API Gateway・Lambda Web Adapter との違い、Hono で作ってデプロイする手順、料金と制限、Cloudflare Workers との使い分けを説明します。
Lambda Web Functions は「HTTP を直接受け取る Lambda」です。コードは AWS_LAMBDA_HTTP_ENDPOINT 環境変数が示すホストとポートで待ち受け、Lambda が HTTPS エンドポイントからのリクエストをそこへ転送します4。Express・Hono・Fastify・Next.js などのフレームワークを、イベントハンドラーに書き換えずに使えます2。
AWS はこの発表に合わせて、Lambda を 3 つの形態に整理しました2。
3 つとも同じ Firecracker の隔離技術の上で動きます。AWS は「非同期処理は Event Functions、ユーザー向けの API と SSR は Web Functions、コード実行機能は MicroVMs」という組み合わせ方を例に挙げています2。
一番の違いは、1 つの実行環境が普通の Web サーバーのように同時に複数のリクエストをさばくことです。Event Functions では 100 件の同時リクエストに 100 個の実行環境が必要でしたが、Web Functions では温まった環境が増えたリクエストを吸収します3。
もう 1 つは課金です。CPU 時間はコードが実際に動いた分だけ課金されるため、データベースや外部 API の応答を待つ時間はほとんど費用になりません3。SSR、API バックエンド、LLM のトークンを流すストリーミング API のように「待ち」が長い処理ほど効果が大きくなります2。
公式ドキュメントが挙げる用途は次のとおりです3。
| 用途 | 例 |
|---|---|
| Web アプリ | HTML・静的ファイル・API を 1 つのデプロイで配る |
| REST / GraphQL API | リクエスト数の多い API バックエンド |
| マイクロサービス | 使われないときは 0 台まで縮む HTTP サービス |
| SSR（サーバーサイドレンダリング） | フレームワークの本番サーバーをそのまま動かす |
| ストリーミング応答 | LLM の応答を生成しながら返す |
キューのメッセージ処理やファイルアップロードのようなイベント駆動の処理は、引き続き Event Functions を使うよう案内されています3。
AWS は 2026 年 10 月 12 日、What's New と AWS News Blog で Lambda Web Functions の提供開始を発表しました12。発表時点の対応リージョンは次の 5 つで、東京リージョン（ap-northeast-1）が最初から含まれています2。
ランタイムは Node.js 24（nodejs24.x）だけで、CPU は Arm64（Graviton）だけです25。
発表の前には混乱もありました。2026 年 10 月 1 日の botocore 1.43.107 の変更履歴に「Lambda Web Functions GA launch」と載り、翌 10 月 2 日の 1.43.108 で「LambdaWeb の API は実験的で、外部の顧客にはまだ提供していない」と訂正されています6。そのため 10 月上旬の時点では、SDK のソースから仕組みを読み解く記事が先に出ていました6。10 月 12 日の発表で、正式に使える機能になりました。
既存の Lambda 関数は、この発表から「Lambda Event Functions」と呼ばれます1。コンソールやドキュメントで Event Functions と書かれていたら、これまでの Lambda 関数のことです。
Web Function は「リビジョン」と「エンドポイント」の 2 つの子リソースを持ちます7。
リクエストは次の順で処理されます7。
IamAuth の場合）か、そのまま通す（ApplicationManaged の場合）エンドポイントは作るときに地理的な範囲を選び、あとから変えられません79。
| 種類 | ドメイン | 振り分け |
|---|---|---|
HomeRegion | リージョンのドメイン 1 つ | 作成したリージョンだけで動く |
MultiRegion | グローバルドメイン 1 つ（*.lambda-web.global.on.aws） | Lambda がレイテンシーで近いリージョンへ振り分ける（ベストエフォート） |
PerRegion | リージョンごとのドメイン | Route 53 や CloudFront で自分で振り分ける |
MultiRegion は、コードを 1 回デプロイするだけで指定したリージョンに複製し、レイテンシーベースのルーティングまで設定してくれます2。管理は作成したリージョン（ホームリージョン）だけで行います9。
Web Functions は「実行環境の数」と「1 環境あたりの同時リクエスト数」の 2 軸でスケールします10。
| 設定 | 設定する場所 | 範囲 | 既定値 |
|---|---|---|---|
maxConcurrencyPerEnvironment | リビジョン | 1〜128 | 64 |
maxEnvironments | エンドポイント | 2〜10,000 | なし |
rateLimit（リクエスト/秒） | エンドポイント | 0〜10,000 | なし |
実際の同時実行数は、Lambda が CPU やメモリの使い方を見て動的に決め、maxConcurrencyPerEnvironment を超えません10。トラフィックがなければ実行環境は 0 台になり、次のリクエストはコールドスタートを待ちます10。最小台数を予約する設定はありません10。
一言でいうと、Node.js の Web アプリを新しく Lambda に載せるなら Web Functions、それ以外の言語やコンテナなら従来の方法です。Lambda Web Adapter の README も、新しい Node.js の Web アプリには Web Functions を勧め、他のランタイムやコンテナイメージには Web Adapter を使い続けるよう案内しています11。
| 項目 | Web Functions | Function URL（Event Functions） | API Gateway HTTP API + Lambda | Lambda Web Adapter |
|---|---|---|---|---|
| コードの形 | ポートで待ち受ける HTTP サーバー | イベントを受け取るハンドラー | イベントを受け取るハンドラー | HTTP サーバー（拡張機能がイベントを HTTP に変換） |
| 言語 | Node.js 24 のみ | Lambda の全ランタイム | Lambda の全ランタイム | 全ランタイム・コンテナイメージ |
| 1 環境の同時処理 | 最大 128 | 1 | 1 | 1 |
| 課金 | リクエスト + アクティブ CPU + メモリ | リクエスト + 実行時間 | API Gateway + Lambda の実行時間 | リクエスト + 実行時間 |
| 最大処理時間 | 900 秒（既定 30 秒） | 900 秒 | 30 秒（統合タイムアウト） | 900 秒 |
| カスタムドメイン | CloudFront を前に置く | CloudFront を前に置く | API Gateway の機能 | 入り口による |
出典: Web Functions248、Function URL12、Lambda のクォータ8、API Gateway HTTP API のクォータ13、Lambda Web Adapter11。
Go や Python の API を Lambda に載せたい場合は、Web Functions はまだ使えません。Go なら「AWS Lambda で Go の API サーバーを作る」の方法が引き続き有効です。また、EC2 インスタンス上で Lambda を動かす「Lambda Managed Instances」は、長時間・大容量メモリの処理向けの別の選択肢です。
ここでは Hono の API を作り、ローカルで動かしてから Web Functions にデプロイします。ローカルの動作は筆者が Node.js 24.6.0・hono 4.13.13・@hono/node-server 2.1.5 で確かめました。デプロイの手順は公式ドキュメントのコマンドです（筆者は AWS へのデプロイは行っていません）。
aws lambda-web コマンドを含む AWS CLI v2。aws lambda-web help が動けば使えます。古い場合は aws update などで更新します14iam:PassRole、S3 と IAM の作成権限（deploy が既定のバケットとロールを作る場合）14従来の Lambda で Hono を動かすには hono/ の handle でイベントを変換していました15。Web Functions では Node.js 用の @hono/ でそのまま待ち受けます16。
mkdir my-hono-app && cd my-hono-app
npm init -y
npm pkg set type=module
npm install hono @hono/node-server
ランタイムは既定でパッケージ直下の index.js を読み込みます4。待ち受けるホストとポートは AWS_LAMBDA_HTTP_ENDPOINT から読み、ローカルでは localhost:3000 に落とします。
import { serve } from '@hono/node-server';
import { Hono } from 'hono';
import { logger } from 'hono/logger';
import { streamSSE } from 'hono/streaming';
const app = new Hono();
app.use(logger());
app.get('/api/health', (c) => c.json({ status: 'ok', region: process.env.AWS_REGION ?? 'local' }));
app.get('/api/hello/:name', (c) => {
const requestId = c.req.header('lambda-web-request-id') ?? 'local';
return c.json({ message: `Hello, ${c.req.param('name')}!`, requestId });
});
// 1 秒ごとに 3 回イベントを送る（Server-Sent Events）
app.get('/api/stream', (c) =>
streamSSE(c, async (stream) => {
for (let i = 1; i <= 3; i++) {
await stream.writeSSE({ data: JSON.stringify({ tick: i }) });
await stream.sleep(1000);
}
}),
);
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
serve({ fetch: app.fetch, port: Number(port), hostname: host }, (info) => {
console.log(`listening on ${info.address}:${info.port}`);
});
process.on('SIGTERM', () => process.exit(0));
ポイントは 3 つです。
lambda-web-request-id ヘッダーは Lambda がリクエストごとに付ける ID で、応答ヘッダーにも同じ値が返ります。ログの突き合わせに使えます17SIGTERM を送り、後始末に使えるのは 1 秒までです18本番と同じ起動経路を試すには、環境変数を自分で設定して起動します19。
AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js
別のターミナルから curl で確かめます。
$ curl -s 127.0.0.1:3000/api/hello/lambda
{"message":"Hello, lambda!","requestId":"local"}
$ curl -sN 127.0.0.1:3000/api/stream
data: {"tick":1}
data: {"tick":2}
data: {"tick":3}
同じ実行環境で複数のリクエストが同時に動くので、ローカルのテストでも同時リクエストを流し、グローバル変数にリクエストごとの状態を持っていないかを確かめるよう公式は勧めています19。
本番用の依存だけを入れて zip にします16。
npm ci --omit=dev
zip -r function.zip index.js package.json package-lock.json node_modules
筆者の環境では zip が約 630 KB、展開後の node_modules が約 3 MB でした。パッケージの上限は展開後 512 MB です8。実行環境は Arm64 なので、ネイティブモジュールを含む場合は Linux Arm64 向けにビルドします5。
ソースのディレクトリを渡すと、CLI がパッケージを S3 に上げ、Web Function・最初のリビジョン・エンドポイントを作ります14。
aws lambda-web deploy --name my-hono-app --code ./my-hono-app
初回は次のものが作られます14。
awscli-lambdaweb-{account-id}-{region}-an）dev という名前の HomeRegion エンドポイント出力された URL（公式ドキュメントの例では https:/）に curl すれば動作を確かめられます14。deploy でできたエンドポイントは既定で認証なしです。IAM 認証にするには --auth-type IamAuth を付けます14。CI から実行するときは、確認のプロンプトを飛ばす --create を付けます14。
同じコマンドをもう一度実行すると新しいリビジョンが作られ、dev エンドポイントは自動でそちらに切り替わります（autoDeploymentMode が LatestRevision のため）14。なお、Lambda はサーバーが待ち受けを始めたかを確かめずにリビジョンを Active にします。デプロイのたびにテストリクエストを送ってログを見ます7。
まず雛形で試したい場合は、--hello-world を付けると TypeScript の HTTP サーバーと AGENTS.md を含む雛形が作られてデプロイされます14。
本番では、新しいリビジョンに少しずつトラフィックを移します。自動切り替えを止め、2 つのリビジョンに重みを付けます220。
aws lambda-web update-web-function-endpoint \
--function-name my-hono-app \
--endpoint-name dev \
--auto-deployment-mode Disabled \
--revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'
複数のリージョンに置く場合は --regions を付けます。グローバルドメインが 1 つでき、近いリージョンへ振り分けられます2。
aws lambda-web deploy --name my-hono-app --code ./my-hono-app \
--regions ap-northeast-1,us-east-1,eu-west-1
不要になったら aws lambda-web delete-web-function --function-name my-hono-app で消します。このコマンドは IAM ロール、S3 のパッケージ、ロググループは消さないので、別に削除します14。
独自ドメインや AWS WAF を使うには、エンドポイントの前に Amazon CloudFront を置きます3。Web Functions のエンドポイントは CloudFront のオリジンに指定でき、静的ファイルはキャッシュから、動的なリクエストは Web Function から返す構成が作れます2。
エンドポイントを CloudFront からしか呼べないようにするには、オリジンアクセスコントロール（OAC）を使います221。
IamAuth にするlambda、署名の動作 always-amz-auth で OAC を作るcloudfront.amazonaws.com に lambda:InvokeWebFunctionEndpoint を許可し、aws:SourceArn でディストリビューションを絞る{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontOACAccess",
"Effect": "Allow",
"Principal": { "Service": "cloudfront.amazonaws.com" },
"Action": "lambda:InvokeWebFunctionEndpoint",
"Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<distribution-id>"
}
}
}
]
}
（公式ドキュメントの例21。リージョン・アカウント ID・関数名は自分の値に置き換えます）
CloudFront は Authorization ヘッダーを使わずに署名するので、アプリの JWT やクッキーによる認証はそのまま使えます21。一方、ApplicationManaged のエンドポイントは CloudFront の後ろに置いても、自分のドメインで誰でも呼べる点に注意します21。
Web Functions の料金は「リクエスト数」「アクティブな CPU 時間」「実行環境が存在する間のメモリ」「データ転送」の 4 つです22。2026 年 10 月時点の米国東部（バージニア北部）の Arm の単価は次のとおりです22。
| 項目 | 単価 |
|---|---|
| アクティブ vCPU | 0.0000276944 ドル / vCPU 秒 |
| メモリ | 0.0000036667 ドル / GB 秒 |
| リクエスト | 0.30 ドル / 100 万リクエスト |
課金は 1 ミリ秒単位です22。注意したいのはメモリはリクエストの間の待ち時間も含めて、実行環境がある限り課金されることです3。
公式の料金ページには、実行環境が常に 1 つ動いている前提の 4 つの計算例があります（無料枠とデータ転送は除く）22。
| ワークロード | アクティブ vCPU（ドル） | メモリ（ドル） | リクエスト（ドル） |
|---|---|---|---|
| SSR（1,500 万件） | 16.62 | 4.66 | 4.5 |
| I/O 中心の API（1,000 万件） | 13.85 | 2.76 | 3 |
| 認可ミドルウェア（1 億件） | 33.23 | 1.33 | 30 |
| LLM ストリーミング（500 万件） | 27.69 | 4.75 | 1.5 |
合計は SSR が 25.78 ドル、I/O 中心の API が 19.61 ドル、認可ミドルウェアが 64.56 ドル、LLM ストリーミングが 33.94 ドルです22。
アクティブ CPU 課金の効果は、リクエストの所要時間と CPU 時間の差で分かります。同じ計算例の数字を並べると、LLM ストリーミングは 1 リクエスト 3,000 ミリ秒のうち CPU が動くのは 200 ミリ秒だけです22。
| ワークロード | 所要時間（ミリ秒） | アクティブ CPU（ミリ秒） |
|---|---|---|
| SSR | 150 | 40 |
| I/O 中心の API | 200 | 50 |
| 認可ミドルウェア | 50 | 12 |
| LLM ストリーミング | 3,000 | 200 |
無料枠について、料金ページは Event Functions の無料枠（月 100 万リクエストと 40 万 GB 秒）を書いていますが、Web Functions の計算例は無料枠を除いて計算しています22。Web Functions に無料枠が適用されるかは、2026 年 10 月時点で料金ページから確認できませんでした。
費用の上限を抑えたい趣味のプロジェクトでは、maxEnvironments を小さくすると実行環境の数、つまりメモリ料金の上限を抑えられます10。
| 項目 | 値 |
|---|---|
| ランタイム | Node.js 24（nodejs24.x）のみ |
| CPU アーキテクチャ | Arm64 のみ（選べない） |
| 実行環境あたりの vCPU・メモリ | 2 vCPU・2 GB（変更不可） |
| Node.js のヒープ | 既定 1,024 MB（NODE_OPTIONS で変更可） |
| リクエストのタイムアウト | 既定 30 秒、3〜900 秒 |
| 起動（待ち受け開始）の制限時間 | 10 秒 |
| デプロイパッケージ | 展開後 512 MB |
/ | 512 MB（同じ環境のリクエストで共有） |
| リクエストヘッダー | 合計 128 KiB |
| エンドポイントのリクエストレート | 10,000 リクエスト/秒 |
| アカウントのリクエストレート | 100,000 リクエスト/秒（リージョンごと・引き上げ可） |
| アカウントの vCPU | 2,000（リージョンごと・引き上げ可。1 環境 2 vCPU） |
つまずきやすい点は次のとおりです。
X-Forwarded-Host を信用しない: Lambda は検証せずに転送するので、リダイレクト先の組み立てや認可に使いません17nodejs24.x は常に最新のパッチ版で動きます4AWS_LAMBDA_HTTP_ENDPOINT から値を移す index.js を入口にします4スロットリングされると HTTP 429 が返ります。maxEnvironments かアカウントの vCPU に達したとき、または rateLimit を超えたときです。クライアントは指数バックオフとジッターで再試行します10。
Web Functions と Cloudflare Workers は、どちらも CPU 時間に課金し、待ち時間を課金しない点が似ています324。違いは「どこで、どんな実行環境で動くか」です。
| 項目 | Lambda Web Functions | Cloudflare Workers（Paid） |
|---|---|---|
| 実行環境 | Node.js 24 のプロセス（2 vCPU・2 GB） | V8 アイソレート（128 MB） |
| 配置 | 選んだ AWS リージョン（発表時 5 つ） | Cloudflare のネットワーク全体 |
| リクエスト単価 | 0.30 ドル / 100 万（米国東部） | 月 1,000 万まで込み、以降 0.30 ドル / 100 万 |
| CPU 単価 | 0.0000276944 ドル / vCPU 秒 | 月 3,000 万 CPU ミリ秒まで込み、以降 0.02 ドル / 100 万 CPU ミリ秒 |
| メモリ | 実行環境がある間 GB 秒で課金 | 課金なし（上限 128 MB） |
| 固定費 | なし | 月 5 ドルから |
| 1 リクエストの上限 | 最大 900 秒 | CPU 時間で最大 5 分 |
| AWS の VPC・IAM | そのまま使える | 使えない |
出典: Web Functions2822、Cloudflare Workers の料金24 と上限25。
判断の基準は次のとおりです。
Hono なら同じアプリを両方で動かせます。Workers 側の作り方は「Hono＋Cloudflare D1 で REST API」を参考にしてください。
@hono/ で AWS_LAMBDA_HTTP_ENDPOINT に待ち受け、aws lambda-web deploy 1 回で HTTPS のエンドポイントができます次にやることは、手元の Node.js の API を AWS_LAMBDA_HTTP_ENDPOINT で待ち受けるように 1 行変え、aws lambda-web deploy --hello-world で雛形を動かしてみることです。
2026 年 10 月 12 日に一般提供が始まりました1。対象リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）です2。10 月 1 日の botocore の変更履歴に GA と載ったのは誤りで、翌日に訂正されています6。
2026 年 10 月時点では使えません。サポートしているのは Node.js 24 だけです4。他の言語では Event Functions（Function URL など）か Lambda MicroVMs を使うよう公式は案内しています3。HTTP サーバーをそのまま載せたい場合は、Lambda Web Adapter が引き続き選択肢です11。
名前が「Lambda Event Functions」に変わるだけで、コードの変更や再デプロイは不要です1。
Function URL は Event Functions に URL を付ける機能で、リクエストはイベントとして届き、1 つの実行環境は一度に 1 件だけ処理します212。Web Functions はポートで待ち受ける HTTP サーバーが直接リクエストを受け、1 つの実行環境で複数件を同時に処理します2。
使えません。WebSocket へのアップグレードはサポートされていません16。サーバーからのプッシュには Server-Sent Events を使います。
あります。トラフィックが無いと実行環境は 0 台になり、次のリクエストは環境の起動を待ちます10。トラフィックがある間は、Lambda が余裕を持って先に環境を増やすため、小さな増加ではコールドスタートが起きにくい仕組みです10。最小台数を予約する設定はありません10。
AWS Lambda announces Lambda Web Functions — AWS What's New, 2026-10-12（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Announcing AWS Lambda Web Functions — AWS News Blog（Micah Walter）, 2026-10-12（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21
AWS Lambda Web Functions — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
Lambda Web Function runtimes — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10
Instruction set architecture（Lambda Web Functions） — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2
リリース前のAWS Lambda Web Functions(lambda-web)の仕組みを公開ソースから読み解いてみた — DevelopersIO（クラスメソッド）, 2026-10-04（2026-10-14 参照） ↩ ↩2 ↩3
Core concepts（Lambda Web Functions） — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4
Lambda quotas（Lambda Web Functions） — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
Lambda Web Function endpoints — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2
Scaling behavior for Lambda Web Functions — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
aws/aws-lambda-web-adapter README — AWS（GitHub）（2026-10-14 参照） ↩ ↩2 ↩3
Creating and managing Lambda function URLs / Invoking Lambda function URLs — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3
Quotas for configuring and running an HTTP API in API Gateway — Amazon API Gateway 開発者ガイド（2026-10-14 参照） ↩ ↩2
Creating a Lambda Web Function — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
AWS Lambda（Getting Started） — Hono 公式ドキュメント（2026-10-14 参照） ↩
Web Function sample applications — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4
HTTP requests and responses — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5
Execution environment lifecycle（Lambda Web Functions） — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2
Testing Lambda Web Functions — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2
Deployment patterns（Lambda Web Functions） — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩
Lambda Web Function endpoint access control — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩ ↩2 ↩3 ↩4
AWS Lambda pricing — AWS（2026-10-14 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
Troubleshooting Lambda Web Functions — AWS Lambda 開発者ガイド（2026-10-14 参照） ↩
Workers Pricing — Cloudflare Docs（2026-10-14 参照） ↩ ↩2
Workers Limits — Cloudflare Docs（2026-10-14 参照） ↩