はじめに
前回は、FaaS の基準となる AWS Lambda を整理しました。今回は 主要クラウド（CSP）の FaaS を横に並べて比較 します。
基準にするのは AWS Lambda の Event Functions（従来型の Lambda） です。各社のサービスを、Lambda と比べて「何が同じで、何が違うか」という視点で見ていきます。
この記事の情報は 2026年11月時点 の各社の公式ドキュメントに基づいています。料金は特に断りがない限り USD で、東京リージョン（またはそれに相当するティア）の値です。採用を判断する前に、必ず最新の公式情報を確認してください。
比較対象
| CSP | サービス | 位置づけ |
|---|---|---|
| AWS | Lambda（Event Functions） | 基準。イベント駆動 FaaS の元祖 |
| Google Cloud | Cloud Run functions | 旧 Cloud Functions（第2世代）。Cloud Run の上で動く FaaS |
| Microsoft Azure | Azure Functions（Flex Consumption プラン） | 新規のサーバーレス開発で推奨されているプラン |
| Cloudflare | Cloudflare Workers | エッジで動く V8 isolate ベースの FaaS |
| さくらインターネット | さくらのクラウド AppRun（共用型／専有型） | 国産。FaaS ではなく、コンテナのサーバーレス実行基盤 |
プランを選んだ理由
- Azure Functions: 従来の Consumption プランはレガシー扱いになり、Linux 版は終了に向かっています。新規開発では Flex Consumption が推奨されているため、こちらを比較対象にしました。
- Google Cloud: Cloud Functions は2024年に Cloud Run functions に統合されました。中身は Cloud Run のサービスなので、Cloud Run の制約や料金がそのまま当てはまります。
- さくらのクラウド: FaaS は提供されていないので、AppRun を比較対象にしました。2025年12月に正式サービスになったコンテナ実行基盤で、Knative ベースです（Cloud Run と同じ系統）。ゼロスケールできる 共用型 を中心に扱い、閉域網の項目では 専有型 も取り上げます。
国産 CSP の FaaS について
国産 CSP で、汎用的な FaaS（Lambda 相当の関数実行サービス）を一般に提供しているところがないか調べました。2026年11月時点では 見つかりませんでした。そのため、国産の代表としてはさくらのクラウド AppRun のみを扱います。
情報をお持ちの方は、コメントで教えてもらえるとありがたいです。見つかれば追記します。
総合比較マトリクス
まずは全体像です。詳細は後のセクションで説明します。
実行モデル・制約
| 項目 | AWS Lambda（基準） | Cloud Run functions | Azure Functions Flex | Cloudflare Workers | さくら AppRun 共用型 |
|---|---|---|---|---|---|
| 実行基盤 | Firecracker microVM | コンテナ（gVisor など） | Linux コンテナ | V8 isolate | コンテナ（Knative） |
| デプロイ単位 | .zip / コンテナイメージ | ソースコード（ビルドしてコンテナにする） | コード（コンテナは不可） | JS/Wasm バンドル | コンテナイメージ（linux/amd64 のみ） |
| 1インスタンスあたりの同時処理数 | 1（固定） | 既定 80、最大 1,000 | HTTP の既定: 512 MB→4 / 2 GB→16 / 4 GB→32 | 多数（isolate で多重化） | 最大 1,000（ハードリミット） |
| 同時処理数を ユーザーが設定できるか | ×（Event Functions は1で固定） |
○（--concurrency で1〜1,000） |
○（HTTP の同時処理数をインスタンス単位で設定。HTTP 以外は host.json などで設定） |
×（プラットフォームが自動で制御） | △（公開されている情報では設定項目を確認できず） |
| 最大実行時間 | 15分 | HTTP: 60分 / イベント: 9分 | 上限なし（HTTP の応答は 230秒 まで） | CPU 時間: 最大5分（有料）／ 経過時間: 接続中は制限なし | リクエストのタイムアウト: 1〜300秒 |
| 最大メモリ | 10,240 MB | 32 GiB | 4,096 MB | 128 MB | 4 GiB |
| 最大 vCPU | 6 | 8 | 2 | ―（CPU 時間で制限） | 2 |
| リクエストサイズ | 6 MB（同期） | 32 MiB（HTTP/1） | 約 100 MB | 100 MB〜（ドメインのプランによる） | 公開されていない |
| パッケージサイズ | 250 MB（展開後）／ イメージ 10 GB | 実質的な制限なし（イメージ） | ― | 64 MiB | イメージ 2 GiB |
| ゼロスケール | ○ | ○ | ○ | ○（そもそも常駐しない） | ○ |
運用・ネットワーク・コスト
| 項目 | AWS Lambda（基準） | Cloud Run functions | Azure Functions Flex | Cloudflare Workers | さくら AppRun 共用型 |
|---|---|---|---|---|---|
| コールドスタート | 数百 ms〜（Java は秒単位） | 数百 ms〜数秒 | 数百 ms〜数秒 | ほぼなし（数 ms） | 数秒〜十数秒 |
| コールドスタート対策 | SnapStart、Provisioned Concurrency | 最小インスタンス数、Startup CPU Boost | Always Ready インスタンス | 不要 | 最小スケールを 1 以上にする |
| スケール上限（既定） | 同時実行 1,000 / リージョン | 100 インスタンス / プロジェクト・リージョン | 1,000 インスタンス / 関数グループ（リージョンあたり 250 コアの上限あり） | 明示的な上限なし | 10 インスタンス / アプリ |
| 課金単位 | リクエスト数 + GB秒（1 ms 単位） | リクエスト数 + vCPU秒 + GiB秒（100 ms 単位） | 実行数 + GB秒（最小 1秒、以降 100 ms 単位） | リクエスト数 + CPU 時間（ms） | インスタンス × 時間（1時間単位） |
| 待ち時間（I/O 待ち）の課金 | される | される（リクエスト処理中） | される | されない | される（インスタンスが起動している間） |
| 無料枠（毎月） | 100万リクエスト + 40万 GB秒 | 200万リクエスト + 18万 vCPU秒 + 36万 GiB秒 | 25万実行 + 10万 GB秒 | Free プラン: 1日 10万リクエスト | なし |
| 閉域網への接続 | ◎ VPC 内に配置、PrivateLink 経由の呼び出し | ◎ Direct VPC egress、内部 ingress | ◎ VNet 統合、プライベートエンドポイント | △ Workers VPC（ベータ、Tunnel 経由のアウトバウンドのみ） | ×（専有型なら可） |
| 日本のリージョン | 東京・大阪 | 東京・大阪 | 東日本（西日本は Flex 未対応） | 全世界のエッジ（東京・大阪などを含む） | 国内のデータセンター |
| トリガー | 200以上の AWS サービス | HTTP、Eventarc（Pub/Sub、GCS など） | HTTP、Timer、Queue、Event Grid など（バインディング） | HTTP、Cron、Queues | HTTP のみ |
| ワークフロー | Step Functions / Durable Functions | Workflows | Durable Functions | Workflows | ― |
1. コールドスタート
FaaS の採用で、いちばんよく話題になる問題です。
| サービス | 仕組み | 目安 | 対策 |
|---|---|---|---|
| AWS Lambda | microVM の起動とランタイムの初期化（INIT）が必要 | Node.js / Python は数百 ms、Java / .NET は秒単位になることもある | SnapStart（Java / Python / .NET）、Provisioned Concurrency |
| Cloud Run functions | コンテナを起動する | 数百 ms〜数秒 | 最小インスタンス数（アイドル時は割安な料金）、Startup CPU Boost |
| Azure Functions Flex | インスタンスを割り当てて、ホストを起動する | 数百 ms〜数秒 | Always Ready インスタンス（既定は 0） |
| Cloudflare Workers | V8 isolate を作るだけ。TLS ハンドシェイク中に事前ロードする | ほぼゼロ | 不要 |
| さくら AppRun 共用型 | ゼロからコンテナを起動する | 数秒〜十数秒（公式の値はない） | 最小スケールを 1 以上にする（常時課金になる） |
Cloudflare Workers は構造的にコールドスタートが発生しにくい です。これは大きな差別化要素です。その代わり、メモリは 128 MB までで、Node.js 互換も一部に限られるなど、実行環境に制約があります。
2. 1インスタンスあたりの同時処理数
Lambda（Event Functions）と、ほかのサービスとの大きな違いがここです。
| サービス | 設定できるか | 既定値と範囲 | 補足 |
|---|---|---|---|
| AWS Lambda（Event Functions） | × | 1 で固定 | 多重処理が必要なら、Web Functions（最大128）や Managed Instances という別の形態を使う |
| Cloud Run functions | ○ | 既定 80、1〜1,000 | vCPU を 1 未満にすると、同時処理数は 1 に固定 される |
| Azure Functions Flex | ○ | HTTP の既定はメモリサイズで決まる（512 MB→4、2 GB→16、4 GB→32） |
Python は既定 1。HTTP 以外のトリガーは host.json などで設定する（動的に調整するモードもある） |
| Cloudflare Workers | × | ― | isolate の仕組みで、プラットフォームが自動的に多重化する |
| さくら AppRun 共用型 | △ | 上限 1,000 | Knative ベースだが、公開されている情報では設定項目を確認できず |
同時処理数を増やすと、次のような効果があります。
- 同じリクエスト数を 少ないインスタンス数 でさばけるので、コールドスタートの回数とコストが減る
- I/O 待ちの間にほかのリクエストを処理できるので、待ち時間の課金を実質的に減らせる
- その代わり、スレッドセーフ なコードを書く必要がある。グローバル変数の扱いや、DB コネクションプールのサイズに注意する
3. レスポンス時間・実行時間の制限
「関数そのものの実行時間の上限」と「HTTP で応答を返すまでの上限」は、別物として見る必要があります。
| サービス | 関数の実行時間の上限 | HTTP の応答の上限 | 注意点 |
|---|---|---|---|
| AWS Lambda | 15分 | Function URL: 15分 ／ API Gateway（REST）: 既定 29秒（引き上げ可能） | 前段に API Gateway を置くと、その制限が先にかかる |
| Cloud Run functions | イベント: 9分 | 60分 | HTTP の長時間処理に強い |
| Azure Functions Flex | 上限なし（既定 30分） | 230秒 | プランに関係なく、HTTP は 230秒の壁がある。長い処理は Durable Functions で非同期にする |
| Cloudflare Workers | CPU 時間: 最大5分（有料）／ Cron・Queue: 15分 | 接続している間は制限なし | 制限されるのは CPU 時間 で、I/O 待ちは数えない |
| さくら AppRun 共用型 | ― | 1〜300秒（既定 60秒） | 起動のタイムアウトは4分 |
4. コスト
料金体系
| サービス | 主な単価 |
|---|---|
| AWS Lambda | $0.20 / 100万リクエスト、$0.0000166667 / GB秒（x86） |
| Cloud Run functions（リクエスト単位の課金） | $0.40 / 100万リクエスト、$0.000024 / vCPU秒、$0.0000025 / GiB秒 |
| Azure Functions Flex（オンデマンド） | $0.40 / 100万実行、$0.000026 / GB秒 |
| Azure Functions Flex（Always Ready） | 待機中: $0.000004 / GB秒、実行中: $0.000016 / GB秒、$0.40 / 100万実行（無料枠なし） |
| Cloudflare Workers（有料） | 月額 $5（1,000万リクエストと 3,000万 CPU ms を含む）、超過分は $0.30 / 100万リクエスト、$0.02 / 100万 CPU ms |
| さくら AppRun 共用型 | 0.5 vCPU / 1 GiB で 5円 / 時間〜（税込） |
Azure の単価は、Azure Functions の料金ページで「東日本・USD・従量課金制」を選んだときの値です。1年または3年の節約プランを使うと、約17%安くなります。
試算：月 1,000万リクエスト、平均 200 ms、メモリ 512 MB
前回の記事と同じ条件で、ざっくり試算しました（無料枠を含む）。
| サービス | 前提 | 月額の目安 |
|---|---|---|
| AWS Lambda | x86、512 MB | 約 $11.8 |
| Cloud Run functions | 512 MiB / 0.333 vCPU、同時処理数 1 | 約 $16.5 |
| Azure Functions Flex | 512 MB（HTTP の同時処理数は既定の 4）、実行時間の合計で計算した場合 | 約 $27（※2） |
| Cloudflare Workers | 1リクエストあたり CPU 10 ms と仮定 | 約 $6.4 |
| さくら AppRun 共用型 | 0.5 vCPU / 1 GiB を1台、常時稼働 | 約 3,720円（≒ $24） |
※2 Flex には 最小課金時間が 1,000 ms あります。短い実行が多いと、実際の請求額は試算より高くなることがあります。
この試算は、比較の目安として かなり単純化 したものです。
- Cloud Run と Azure は、同時処理数を増やす と、1リクエストあたりのコストが大きく下がります。
- Cloudflare は、I/O 待ちが課金されないので、外部 API の待ち時間が長いほど有利になります。一方で、メモリ 128 MB に収まる処理しか動きません。
- AppRun は 時間単位の課金 なので、リクエスト数が増えても、インスタンス数が変わらなければ料金も変わりません。逆に、アクセスがほとんどないときは、ゼロスケールでほぼ無料になります。
5. ランタイム（対応言語）
| 言語 | AWS Lambda | Cloud Run functions | Azure Functions Flex | Cloudflare Workers | さくら AppRun |
|---|---|---|---|---|---|
| Node.js / TypeScript | ○ 22, 24 | ○ 22, 24 | ○ 22, 24 | ◎ ネイティブ（Node.js 互換は一部） | ○（コンテナ） |
| Python | ○ 3.11〜3.14 | ○ 3.11〜3.14 | ○ 3.10〜3.14 | ○（2026年9月に GA） | ○ |
| Java | ○ 8〜25 | ○ 17, 21, 25 | ○ 8〜25 | × | ○ |
| .NET（C#） | ○ 8, 10 | ○ 8, 10 | ○ 8, 9, 10（isolated のみ） | × | ○ |
| Go | △ カスタムランタイム | ○ 1.26, 1.27 | △ カスタムハンドラー | △ Wasm | ○ |
| Ruby | ○ 3.3〜4.0 | ○ 3.3〜4.0 | × | × | ○ |
| PHP | △ カスタム | ○ 8.2〜8.5 | × | × | ○ |
| Rust | △ カスタム | △ OS のみのランタイム | △ カスタムハンドラー | ○ Wasm | ○ |
| PowerShell | × | × | ○ 7.4, 7.6 | × | ○ |
| コンテナで自由に持ち込む | ○ | ○（Cloud Run サービスとして） | ×（Flex は不可） | ×（Containers は別サービス） | ◎（前提がコンテナ） |
AppRun はコンテナの実行基盤なので、linux/amd64 で動くものならどの言語でも使えます。ただし arm64 のイメージは動かない ので、Apple Silicon の Mac でビルドするときは --platform linux/amd64 を指定しましょう。
6. クォータ（主な上限）
| 項目 | AWS Lambda | Cloud Run functions | Azure Functions Flex | Cloudflare Workers（有料） | さくら AppRun 共用型 |
|---|---|---|---|---|---|
| 同時実行・インスタンス数 | 1,000 / リージョン（引き上げ可能） | 100 インスタンス / プロジェクト・リージョン（引き上げ可能） | 1,000 / 関数グループ、250 コア / リージョン | ― | 10 / アプリ |
| スケール速度 | 10秒あたり 1,000 実行環境 | ― | ― | ― | ― |
| 関数（アプリ）の数 | 実質的な制限なし（コードの保存容量 300 GB） | ― | 1プランに1アプリ | 500 / アカウント | ― |
| 環境変数 | 合計 4 KB | ― | ― | 128個、1つあたり 5 KB | 値は 512 バイトまで |
| サブリクエスト（外部への呼び出し） | ― | ― | ― | 1リクエストあたり 10,000 | ― |
7. 閉域網への配置・接続
エンタープライズ用途では、ここが 選定の決め手になる ことが多い項目です。
| サービス | アウトバウンド（関数 → 閉域内のリソース） | インバウンド（閉域内 → 関数を呼び出す） | 備考 |
|---|---|---|---|
| AWS Lambda | ◎ VPC にアタッチ（Hyperplane ENI） | ◎ PrivateLink（インターフェースエンドポイント）、プライベート API Gateway | VPC に入れてもコールドスタートへの影響は小さくなった |
| Cloud Run functions | ◎ Direct VPC egress / Serverless VPC Access | ◎ ingress を「内部」に限定、内部ロードバランサー | Private Service Connect にも対応 |
| Azure Functions Flex | ◎ VNet 統合 | ◎ プライベートエンドポイント | 旧 Consumption プランは VNet 非対応。Flex を選ぶ理由のひとつ |
| Cloudflare Workers | △ Workers VPC（ベータ）: Cloudflare Tunnel や WAN 経由で AWS / Azure / GCP / オンプレに接続 | ×（入口は必ずパブリックなエッジ。Cloudflare Access などで保護する） | ベータ期間中は無料 |
| さくら AppRun | 共用型: × ／ 専有型: ○（サービスエンドポイントゲートウェイ経由） | 共用型: パケットフィルタで IP を制限（最大10件） | 閉域網が必要なら専有型（月額 11,000円〜、ゼロスケールなし） |
さくら AppRun の 共用型は、スイッチ（ローカルネットワーク）に接続できません。プライベートネットワーク上の DB に直接つなぐ構成はとれないので、専有型にするか、別の構成を検討しましょう。
8. 追加の比較項目
| 項目 | AWS Lambda | Cloud Run functions | Azure Functions Flex | Cloudflare Workers | さくら AppRun |
|---|---|---|---|---|---|
| Arm 対応 | ○ Graviton（約20%安い） | ― | ― | ― | ×（amd64 のみ） |
| エッジ実行 | △ Lambda@Edge（別サービス） | × | × | ◎ 標準 | × |
| データを国内で完結できるか | ○（リージョンを指定） | ○（リージョンを指定） | ○（リージョンを指定） | △（エッジで実行される。Regional Services などで制御） | ◎ 国産・国内のデータセンター |
| 契約・支払い | USD（請求代行を使えば円も可） | USD | USD / 円（EA など） | USD | 円建て |
| ロックイン度 | 高い | 中（Functions Framework、コンテナ） | 中〜高（バインディングが Azure 固有） | 中（Web 標準 API ベースだが、独自のバインディングあり） | 低い（ただのコンテナ） |
| ローカル開発 | SAM CLI、LocalStack | Functions Framework | Azure Functions Core Tools | Wrangler（workerd） | Docker、apprun-cli |
9. ユースケース別の選び方
| サービス | 向いているケース | 向いていないケース |
|---|---|---|
| AWS Lambda | AWS 内のイベント処理（S3、SQS、DynamoDB Streams など） | 長時間の HTTP 処理、待ち時間の長い API |
| Cloud Run functions | HTTP API、長時間の処理、GCP のデータ基盤との連携 | AWS 中心のシステム |
| Azure Functions Flex | .NET の資産、Microsoft 365 / Entra ID との連携、Durable Functions | 230秒を超える同期 HTTP |
| Cloudflare Workers | エッジでの処理、認証プロキシ、BFF、待ち時間の長い AI API の中継 | メモリを大量に使う処理、閉域内の DB を多用する処理 |
| さくら AppRun | 国産・円建てが必須の案件、コンテナをそのまま動かしたい場合、小規模な Web | 大規模なスケール（共用型は10インスタンスまで）、イベント駆動の処理 |
まとめ
- AWS Lambda は、イベントソースとの統合と閉域網への対応のバランスが最も良く、今も基準となるサービスです。
- Cloud Run functions と Azure Functions Flex は、「1インスタンスで多重処理する」方向に進んでいます。Lambda の弱点だった、待ち時間の課金や長時間の HTTP 処理への対応が強みです。
- Cloudflare Workers は、コールドスタートがほぼなく、CPU 時間で課金されます。ただしメモリ 128 MB と閉域接続（ベータ）が制約です。
- さくら AppRun は FaaS ではありませんが、国産・円建て・ロックインが少ないという独自の価値があります。閉域網が必要なら専有型を選ぶ、という使い分けが必要です。
- 汎用 FaaS を一般に提供している国産 CSP は、2026年11月時点では見つかりませんでした。
次回以降は、各サービスを1つずつ深掘りしていく予定です。
参考
- Lambda のクォータ（AWS）
- AWS Lambda 料金
- Cloud Run のクォータと上限（Google Cloud）
- Cloud Run functions のランタイム（Google Cloud）
- Cloud Run の料金（Google Cloud）
- Azure Functions のホスティングオプション（Microsoft Learn）
- Azure Functions Flex Consumption プラン（Microsoft Learn）
- Azure Functions の料金
- Flex Consumption の新リージョン（Japan East を含む）
- Cloudflare Workers Limits
- Cloudflare Workers Pricing
- Cloudflare Workers VPC
- AppRun 共用型（さくらのクラウド）
- AppRun 専有型（さくらのクラウド）
- AppRun 正式サービス提供開始のお知らせ（さくらインターネット）
- さくらのクラウド、コンテナをサーバレスで実行する「AppRun」を正式サービスとして提供開始へ（Publickey）
FaaS比較シリーズ 記事一覧
| 回 | 記事 |
|---|---|
| #1 | AWS Lambda を整理する ― 2026年11月版・5つの形態と制約・料金・設計のツボ |
| #2 | 主要CSPのFaaSを横並びで比較する ― AWS Lambdaを軸にGCP・Azure・Cloudflare・さくらのクラウドを整理（2026年11月版）（この記事） |
| #3 | 運用編 ― デプロイ・監視・ローカルとクラウドの差分を5サービスで比較する（2026年11月版） |
| #4 | 1インスタンスあたりの同時処理数（マルチコンカレンシー）を比較する ― 対応サービス・コスト削減効果・実装の注意点（2026年11月版） |
| #5 | FaaS VS コンテナ実行基盤 ― どこからコンテナのほうが安くなるのか？損益分岐点を5社で試算する（2026年11月版） |
| #6 | FaaSとは何だったのか ― 12年の変遷・強み・基盤技術・セキュリティから定義を考え直す |
| #7 | もし今、自分がFaaSを設計するなら ― 12の設計判断とFaaSの未来予想 |