Digital Appendix
『AIエージェントが見つけたサーバーレス』のデジタル付録
FaaSの運用仕様
FaaSの運用仕様
対象本文
第1章の上限、第2章の初期化・warm capacity・課金境界・環境内並行、第5章のnetwork統合とAWS Lambda tenant isolation modeを補います。数値の暗記ではなく、負荷試験と料金表で確認する仕様面を示します。
収集方法
2026年7月30日にAWS Lambda、Google Cloud Run functions、Azure Functions、Cloudflare Workersの公式クォータ、scale、pricingへの入口を再確認しました。比較可能な共通単位へ無理に換算せず、各社が何を実行単位・課金単位・上限単位にするかを記録しています。AWSについては、第2章の具体例に合わせ、オンデマンド実行、Provisioned Concurrency、SnapStart、Lambda MicroVMsの課金境界と変更履歴を追加で照合しました。
現在の答え
FaaSは、hostの台数を隠し、要求またはeventを実行単位へ割り当て、需要に応じてinstanceを増減し、利用量を計測する方向へ収斂しました。しかし、同じ「function」でも、1環境が同時に処理する要求数、scaleの単位、warm capacity、network、CPU時間の扱いは異なります。
| 観点 | AWS Lambda | Google Cloud Run functions | Azure Functions | Cloudflare Workers |
|---|---|---|---|---|
| scaleの主語 | function/version/aliasのconcurrency | revision instanceとrequest concurrency | hosting plan、function app、trigger groupまたはfunction | isolateを収容するWorkers runtime |
| 同時処理 | 通常は1実行環境が1 concurrent invocation。同期RPS等は別quota | 1 instance内concurrencyを構成できる | planとtriggerによりinstance内並行・scale単位が変わる | 1 isolateがevent loopで複数I/Oを扱い、CPU timeとsubrequest等で制約 |
| warm制御 | provisioned concurrency。reserved concurrencyは上限・取り置きで、初期化済みとは限らない | minimum instances | Flex/Premium等のalways-readyまたはprewarmed設定 | 一般的な固定warm instanceではなく、isolateの高速起動を前提 |
| 下流保護 | reserved concurrency、event sourceのmaximum concurrency | max instances/concurrency | maximum instance countとtrigger設定 | CPU/subrequest/dispatchのlimit、Queues等のconsumer設定 |
| 閉域接続 | VPC統合。共有network interfaceとservice側管理 | Direct VPC egressまたはconnector | VNet integration | service binding、Tunnel、Hyperdrive等、製品境界ごとの接続 |
| 値の正本 | Lambda quotas/pricing | Cloud Run functions quotas/pricing | Functions scale/hosting limits/pricing | Workers limits/pricing |
warm capacityの共通点は、初回遅延の一部を消すために利用者向け在庫を取り置くことです。違いは、初期化済み環境の個数、minimum instance、plan全体のready capacityのどれを予約するかにあります。したがって「1個の環境を稼働維持する」と一括りにはできず、費用と効果は同じではありません。
環境内並行も同じではありません。1要求1環境のモデルではconcurrencyがほぼ環境数になります。1 instanceが複数要求を扱うモデルでは、共有memory、event loop、thread、CPU割当を含めて飽和点を測ります。下流databaseを守る上限は、公開最大値ではなく、接続席と処理時間から逆算します。
コールド／ウォームと課金境界
コールド／ウォームはレイテンシの状態名であり、請求書の状態名ではありません。料金表では、起動・初期化、利用中の実行、待機・取り置き、状態保持、復元・再開のどこで計測されるかを分けます。同じ「初回を短くする」構成でも、支払う対象は揃いません。
| 課金境界 | AWS Lambdaの代表例 | 読むときの注意 |
|---|---|---|
| 起動・初期化 | 通常のオンデマンド実行ではINITがBilled Durationに含まれる。2025年8月1日から、従来例外だったマネージドランタイムのZIP関数にも適用 | Custom Runtime、Provisioned Concurrency、コンテナイメージでは以前からINITが課金対象だった。料金境界は履歴で変わり得る |
| 利用中 | 呼び出し回数と、メモリ等に応じた実行時間 | ウォーム再利用ではINITを通らなくても、本体処理の料金は発生する |
| 待機・取り置き | Provisioned Concurrencyは設定した同時実行数と有効期間を5分単位で計測し、リクエストと実行時間は別に数える | reserved concurrencyは上限・取り置きであり、初期化済み環境の確保ではない |
| 状態保持 | Pythonと.NETのSnapStartはsnapshot cacheを最低3時間、その後はミリ秒単位で維持。対応するJavaマネージドランタイムは追加料金の対象外 | ランタイムと提供条件で例外がある。単価ではなく適用条件まで確認する |
| 復元 | Pythonと.NETのSnapStartはsnapshotから実行環境を復元するたびに料金が発生 | 初期化を消したのではなく、保存と復元へ費目を移している |
| 休止 | Lambda MicroVMsは休止中の計算課金が止まる | snapshotの保存、読出し、書込み、転送など、状態を保つ費目は残る |
この一社だけでも、オンデマンド、確保、snapshot cache、restore、休止中の状態保持という複数のメーターがあります。したがって、コールドスタート対策を比べるときは「速くなるか」だけでなく、初期化する時刻と料金の置き場所がどこへ動くかを確認します。最新の単価、無料枠、対象ランタイム、リージョン差はAWS公式料金表を正本とします。
AWS Lambda tenant isolation modeは、呼出しにtenant identifierを含め、そのtenantに関連付けた実行環境を他tenantへ再利用しない実行モデルです。これはVM専有やaccount分離と同じではなく、共有pool内の再利用境界をtenantへ狭める中間の選択です。
一次資料
- AWS Lambda quotas: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
- AWS Lambda concurrency: https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
- AWS Lambda provisioned concurrency: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html
- AWS Lambda pricing: https://aws.amazon.com/lambda/pricing/
- AWS Lambda INIT billing standardization: https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/
- AWS Lambda SnapStart: https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
- AWS Lambda MicroVMs lifecycle and billing: https://docs.aws.amazon.com/lambda/latest/dg/microvms-launching.html
- AWS Lambda tenant isolation: https://docs.aws.amazon.com/lambda/latest/dg/tenant-isolation.html
- Google Cloud Run functions quotas: https://docs.cloud.google.com/functions/quotas
- Google Cloud Run concurrency: https://docs.cloud.google.com/run/docs/about-concurrency
- Azure Functions scale and hosting: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
- Azure Functions event-driven scaling: https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling
- Cloudflare Workers limits: https://developers.cloudflare.com/workers/platform/limits/
- Cloudflare Workers pricing: https://developers.cloudflare.com/workers/platform/pricing/
既知の未知
- 既定quota、引上げ可能値、scale rate、minimum instance、単価はregion、plan、account、runtimeで変わります。
- AWS LambdaのINIT、Provisioned Concurrency、SnapStart、MicroVMsは同じLambdaブランドでも別の料金境界を持ち、対象runtimeやpackagingで適用条件が変わります。
- Google Cloud Functionsの世代・名称移行により、旧世代とCloud Run functionsの文書が併存します。
- Azure Functionsはhosting planごとの差が大きく、単一の「Azure Functions上限」にはできません。
- 実効cold start、network初回、環境再利用率は公開値でなく対象workloadの測定が必要です。
変更履歴
- 0.10.0 (2026-07-30): 第2章のAWS課金ケースに合わせ、コールド／ウォームと課金境界を分離。INIT課金の変更履歴、Provisioned Concurrency、SnapStartのcache/restore、Lambda MicroVMs休止時の計算と状態保持を追加し、確認日を更新。
- 0.9.0 (2026-07-10): 上限、warm capacity、環境内並行、network、tenant isolationを一つの運用仕様として初版ドラフト化。