はじめに
#4 では、1インスタンスで複数のリクエストを同時に処理する「マルチコンカレンシー」を取り上げました。そこで浮かんだのが次の疑問です。
- コンテナ実行基盤は、もともと 複数のリクエストを同時に処理するのが前提
- それなら、リクエストが途切れずに来るケースでは、FaaS よりコンテナのほうが安い のでは？
今回は、同じクラウドの中の「FaaS」と「コンテナ実行基盤」をペアにして、どんな条件ならどちらが安いのか を試算します。コスト以外の違いも合わせて整理します。
この記事の情報は 2026年11月時点 の各社の公式料金ページに基づいています。AWS は us-east-1、Google Cloud は Tier 1（東京を含む）、Azure は 東日本 の USD 価格です。さくら AppRun は税込みの円で、1ドル = 150円 で換算しています。
比較するペア
| CSP | FaaS | コンテナ実行基盤 |
|---|---|---|
| AWS | AWS Lambda（Event Functions） | AWS Fargate（Amazon ECS） |
| Google Cloud | Google Cloud Run functions | Google Cloud Run（サービス） |
| Microsoft Azure | Azure Functions（Flex Consumption） | Azure Container Apps（従量課金プラン） |
| Cloudflare | Cloudflare Workers | Cloudflare Containers |
| さくらインターネット | ―（FaaS なし） | さくら AppRun（共用型 / 専有型） |
Google Cloud Run functions と Google Cloud Run は、同じ基盤の上で動いています。 違いは「関数として書くか、コンテナとして持ち込むか」と「課金方式の選び方」だけです。FaaS とコンテナの境界が、いちばん曖昧なペアです。
1. 課金モデルの違い
まず、何に対してお金を払うのかを整理します。ここがコストの差のほぼすべてを決めます。
| サービス | 課金の対象 | アイドル時 | リクエスト単位の料金 | ゼロスケール |
|---|---|---|---|---|
| AWS Lambda（Event Functions） | 実行時間（GB秒）、1リクエスト = 1インスタンス | 0 | あり（$0.20 / 100万） | ○ |
| AWS Fargate | タスクを動かしている時間（vCPU時間 + GB時間） | 課金される | なし（ロードバランサーは別料金） | × |
| Google Cloud Run functions | リクエストを処理している時間（vCPU秒 + GiB秒） | 0 | あり（$0.40 / 100万） | ○ |
| Google Cloud Run（インスタンス単位の課金） | インスタンスが起動している時間（単価は割安） | 課金される | なし | △（最小インスタンス数による） |
| Azure Functions（Flex Consumption） | インスタンスが実行している時間（GB秒） | 0 | あり（$0.40 / 100万） | ○ |
| Azure Container Apps | アクティブな時間（vCPU秒 + GiB秒）。アイドル時は割安な料金 | 割安な料金 | あり（$0.40 / 100万） | ○ |
| Cloudflare Workers | CPU 時間のみ | 0 | あり（$0.30 / 100万、1,000万件まで込み） | ○ |
| Cloudflare Containers | CPU は実際に使った分、メモリとディスクは起動している間 | スリープすれば 0 | Workers のリクエスト料金 | ○ |
| さくら AppRun（共用型） | インスタンス数 × 時間（1時間単位） | インスタンスがあれば課金 | なし | ○ |
| さくら AppRun（専有型） | ワーカーとロードバランサーの月額・日額・時間額 | 課金される | なし | × |
整理すると、課金モデルは大きく3つに分かれます。
- 処理している時間だけ払う（AWS Lambda、Google Cloud Run functions、Azure Functions など）
- 起動している時間ずっと払う（AWS Fargate、Google Cloud Run のインスタンス単位の課金、さくら AppRun 専有型など）
- CPU を使った時間だけ払う（Cloudflare Workers、AWS Lambda Web Functions）
2. 単価の比較
1 vCPU + 2 GB を、1時間ずっと使い続けた場合 の単価を並べました。
| サービス | 1時間あたり | 備考 |
|---|---|---|
| AWS Lambda（Event Functions） | $0.120 | 2,048 MB（約 1.16 vCPU 相当）、x86 |
| AWS Fargate | $0.049 | x86。Arm（Graviton）なら $0.040 |
| Google Cloud Run functions | $0.104 | リクエスト単位の課金 |
| Google Cloud Run | $0.079 | インスタンス単位の課金 |
| Azure Functions（Flex Consumption） | $0.187 | 2,048 MB のインスタンス（1コア） |
| Azure Container Apps | $0.108 | アクティブ時の料金 |
| Cloudflare Containers | $0.090 | CPU を100%使った場合 |
| さくら AppRun（共用型） | 約 $0.060（9円） | 1 vCPU / 2 GiB |
同じ計算資源を100%使い続けるなら、コンテナのほうが単価は安い ことがわかります。特に AWS Fargate は、AWS Lambda の 約4割 の単価です。
さらに、コンテナ側には Savings Plans（AWS）や確約利用割引（Google Cloud）、節約プラン（Azure） といった長期利用の割引があり、最大で数十％下がります。
3. ケース別の試算
3つのパターンで試算しました。
ケースA：待ち時間の長い API が、一定のペースで来る
#4 と同じ条件です。
- 月 1,000万リクエスト（平均 約3.9 リクエスト/秒）
- 1リクエストは2秒。そのうち CPU を使うのは 20 ms で、残りは外部 API の応答待ち
このパターンに当てはまるユースケース
- AI アプリ: LLM のチャットのバックエンド（LLM の API を呼び出し、応答をストリーミングで返す）
- AI アプリ: RAG の検索 API（ベクトル DB を検索してから LLM を呼び出す）
- AI アプリ: AI エージェントのツール呼び出し（外部 API を順番に呼ぶ）
- Web REST API: 複数の SaaS の API をまとめて返す BFF
- Web REST API: DB の読み書きが中心の CRUD API（DB の応答待ちが大半）
- Webhook の受信と中継（決済サービスや Git ホスティングからの通知など）
| 分類 | サービス | 構成 | 月額の目安 |
|---|---|---|---|
| FaaS | AWS Lambda（Event Functions） | 512 MB | $162 |
| FaaS | Google Cloud Run functions | 同時処理数 80 | $63 |
| FaaS | Azure Functions（Flex Consumption） | 同時処理数 4 | $69 |
| FaaS | AWS Lambda Web Functions | CPU 時間で課金（メモリ 2 GB と仮定） | $28 |
| FaaS | Cloudflare Workers | CPU 時間で課金 | $8.4 |
| コンテナ | AWS Fargate | 0.25 vCPU / 0.5 GB × 1台 | $8.9（+ ALB $16〜） |
| コンテナ | AWS Fargate | 0.25 vCPU / 0.5 GB × 2台（冗長化） | $17.8（+ ALB $16〜） |
| コンテナ | Google Cloud Run | 1 vCPU / 512 MiB、インスタンス単位の課金 | $44 |
| コンテナ | Azure Container Apps | 0.5 vCPU / 1 GiB、常時1台 | $37 |
| コンテナ | Cloudflare Containers | メモリ 1 GiB、常時起動 | $15〜（Durable Objects などは別料金） |
| コンテナ | さくら AppRun（共用型） | 0.5 vCPU / 1 GiB × 1台 | 3,720円（≒ $25） |
読み取れること
- AWS 内で比べると、AWS Lambda（Event Functions）の $162 に対して、AWS Fargate はロードバランサー込みでも $25〜35 程度。待ち時間の長い処理では、コンテナが圧倒的に安い。
- ただし、CPU 時間だけで課金される FaaS（Cloudflare Workers、AWS Lambda Web Functions）は、コンテナと同じか、それより安い。
- ケースAでは、「FaaS かコンテナか」よりも「待ち時間に課金されるかどうか」 で決まっている。
ケースB：CPU を使う処理が、高い頻度で来る
- 100 リクエスト/秒が24時間続く（月 約2.6億リクエスト）
- 1リクエストは CPU 処理だけで 10 ms（待ち時間なし）
- 平均で 1 vCPU をちょうど使い切る負荷
このパターンに当てはまるユースケース
- AI アプリ: 埋め込みベクトルを作る前処理（テキストの分割や正規化）、小さなモデルを CPU で推論する API
- AI アプリ: レコメンドや広告のスコアリング API（軽量なモデルで点数を計算する）
- Web REST API: アクセスの多い公開 API（キャッシュしたデータを JSON に整形して返す）
- Web REST API: 認証 API（トークンの発行・検証が集中する）
- 常にアップロードがある EC サイトやメディアの、画像のリサイズ・サムネイル生成
- IoT のテレメトリやクリックストリームの変換・集計
| 分類 | サービス | 構成 | 月額の目安 | 内訳 |
|---|---|---|---|---|
| FaaS | AWS Lambda（Event Functions） | 1,769 MB（1 vCPU 相当） | $121 | 実行時間 $70 + リクエスト $52 |
| FaaS | Google Cloud Run functions | 1 vCPU / 2 GiB | $173 | 計算資源 $70 + リクエスト $103 |
| FaaS | Azure Functions（Flex Consumption） | 2,048 MB | $236 | 計算資源 $133 + 実行数 $104 |
| FaaS | Cloudflare Workers | ― | $131 | CPU 時間 $51 + リクエスト $75 + 月額 $5 |
| コンテナ | AWS Fargate | 1 vCPU / 2 GB | $36（+ ALB で約 $52） | 計算資源のみ |
| コンテナ | Google Cloud Run | 1 vCPU / 2 GiB、インスタンス単位の課金 | $52 | 計算資源のみ（リクエスト料金なし） |
| コンテナ | Azure Container Apps | 1 vCPU / 2 GiB | $175 | 計算資源 $72 + リクエスト $103 |
| コンテナ | さくら AppRun（共用型） | 1 vCPU / 2 GiB × 1台 | 6,480円（≒ $43） | 計算資源のみ |
読み取れること
- リクエスト数が多いと、FaaS のリクエスト単位の料金が、計算資源の料金と同じくらいか、それ以上になる。
- リクエスト料金がかからないコンテナ（AWS Fargate、Google Cloud Run のインスタンス単位の課金、さくら AppRun）が、FaaS の 1/2〜1/4 になる。
- Azure Container Apps はコンテナでも リクエスト料金がかかる ので、このケースでは FaaS と差がつかない。
- CPU 時間だけで課金される Cloudflare Workers でも、リクエスト料金が効いて安くならない。
ケースC：アクセスが少ない・波がある
- 月 10万リクエスト、平日の日中に集中
- 1リクエスト 200 ms、512 MB
このパターンに当てはまるユースケース
- AI アプリ: 社内向けの AI チャットボット（利用者が少ない）、PoC・検証段階の AI アプリ
- Web REST API: 社内ツールや管理画面の API（業務時間しか使われない）
- Web REST API: お問い合わせフォームなどの受付 API
- ファイルのアップロードをきっかけにした処理（ストレージにファイルが置かれたら変換する）
- 定期バッチ（夜間の集計、レポートの作成）
- チャットツールのボット
| 分類 | サービス | 月額の目安 |
|---|---|---|
| FaaS | AWS Lambda（Event Functions） | $0（無料枠内） |
| FaaS | Google Cloud Run functions | $0（無料枠内） |
| FaaS | Azure Functions（Flex Consumption） | $0（無料枠内） |
| FaaS | Cloudflare Workers | $0（Free プラン）〜 $5 |
| コンテナ | AWS Fargate | $25（最小構成1台 + ALB。ゼロスケールできない） |
| コンテナ | Google Cloud Run | ほぼ $0（ゼロスケール、リクエスト単位の課金） |
| コンテナ | Azure Container Apps | ほぼ $0（ゼロスケール） |
| コンテナ | さくら AppRun（共用型） | 数百円（ゼロスケール。アクセスのあった時間だけ課金） |
| コンテナ | さくら AppRun（専有型） | 11,000円〜（ゼロスケールできない） |
読み取れること
- アクセスが少ない場合は FaaS が圧勝 する。
- ただし、ゼロスケールできるコンテナ実行基盤（Google Cloud Run、Azure Container Apps、さくら AppRun 共用型）なら、FaaS とほぼ同じ水準になる。
- 差がつくのは、ゼロスケールできない基盤（AWS Fargate、さくら AppRun 専有型）の場合。
4. ユースケース別のおすすめ
ここまでの試算をもとに、代表的なユースケースごとのおすすめをまとめました。「パターン」は、上のケースA〜Cのどれに近いかを表しています。
AI アプリ
| ユースケース | パターン | おすすめ | 理由 |
|---|---|---|---|
| LLM のチャットのバックエンド（ストリーミング） | A | Cloudflare Workers、AWS Lambda Web Functions、Google Cloud Run（同時処理数を高めに） | LLM の応答待ちが長く、ストリーミングで接続時間も長い。AWS Lambda（Event Functions）は待ち時間がすべて課金される |
| RAG の検索 API | A | Google Cloud Run、AWS Fargate、Azure Container Apps | ベクトル DB と LLM の待ちが中心。ライブラリが大きいので、コンテナのほうがデプロイしやすい |
| AI エージェント（複数ステップ・長時間） | A（長時間） | AWS Lambda Durable Functions、Azure Functions の Durable Functions、コンテナ | 15分を超える処理や、人の承認待ちがある。途中経過を保存できる仕組みが必要 |
| 社内向けの AI チャットボット | C | AWS Lambda、Azure Functions、Google Cloud Run functions、ゼロスケールできるコンテナ | 利用者が少なく、使われない時間が長い |
| 埋め込みの生成・小さなモデルの CPU 推論 | B | AWS Fargate、Google Cloud Run（インスタンス単位の課金） | CPU を多く使い、モデルの読み込みでコールドスタートも重い。メモリも多く必要 |
GPU を使う推論（大きなモデルを自前で動かす場合）は、この記事の範囲外です。Google Cloud Run や Azure Container Apps には GPU を使えるサーバーレスの選択肢があります。AWS Lambda や Cloudflare Workers では GPU を使えません。
Web REST API
| ユースケース | パターン | おすすめ | 理由 |
|---|---|---|---|
| 社内ツール・管理画面の API | C | AWS Lambda、Azure Functions、Google Cloud Run functions | 業務時間しか使われないので、ゼロスケールの効果が大きい |
| DB 中心の CRUD API（中程度のトラフィック） | A | Google Cloud Run、AWS Fargate、さくら AppRun | DB の待ちが中心。コネクションプールを共有できるコンテナが有利 |
| アクセスの多い公開 API（毎秒数百リクエスト以上） | B | AWS Fargate、Google Cloud Run（インスタンス単位の課金）、さくら AppRun | FaaS ではリクエスト料金が膨らむ |
| 複数の SaaS をまとめる BFF | A | Cloudflare Workers、Google Cloud Run | 外部 API の待ちが中心 |
| エッジでの認証・リダイレクト | ―（軽い処理） | Cloudflare Workers | 利用者の近くで動き、コールドスタートもほぼない |
イベント処理・バッチ
| ユースケース | パターン | おすすめ | 理由 |
|---|---|---|---|
| ファイルのアップロードをきっかけにした処理 | C | AWS Lambda、Azure Functions、Google Cloud Run functions | ストレージのイベントと簡単につながる。FaaS のいちばんの得意分野 |
| 画像のリサイズ（散発的） | C | AWS Lambda など FaaS | 使われない時間が長い |
| 画像のリサイズ（常に大量） | B | AWS Fargate、Google Cloud Run | CPU を使い切るので、単価の安いコンテナが有利 |
| Webhook の受信 | A / C | Cloudflare Workers、FaaS | 波が大きいことが多い |
| 定期バッチ（15分以内） | C | AWS Lambda、Azure Functions など FaaS | 決まった時間だけ動けばよい |
| 定期バッチ（長時間） | ― | AWS Fargate のタスク、Google Cloud Run jobs、Azure Container Apps のジョブ | FaaS の実行時間の上限を超える |
| IoT・クリックストリームの集計 | B | コンテナ、またはキューにためてから FaaS でまとめて処理 | 常にデータが流れてくる |
5. 損益分岐点の考え方
CPU を使い切る処理の場合
FaaS は処理している時間だけ、コンテナは起動している時間ずっと課金されます。そのため、コンテナの「稼働率」 が損益分岐点になります。
損益分岐点の稼働率 ≒ コンテナの単価 ÷ FaaS の単価
| 比較 | 単価（1 vCPU + 2 GB / 時間） | 損益分岐点の稼働率 |
|---|---|---|
| AWS Fargate vs AWS Lambda（Event Functions） | $0.049 vs $0.120 | 約 41% |
| Google Cloud Run（インスタンス単位） vs Google Cloud Run functions | $0.079 vs $0.104 | 約 76% |
つまり、AWS Fargate の平均稼働率が 41% を超えるなら、AWS Fargate のほうが安い という目安になります（リクエスト料金を含めると、分岐点はさらに下がります）。
待ち時間の長い処理の場合
AWS Lambda（Event Functions）は待ち時間にも課金され、コンテナは同時処理で待ち時間を分け合えます。そのため、損益分岐点は「同時処理できる数」の分だけ、さらに下がります。
損益分岐点の稼働率 ≒ コンテナの単価 ÷（FaaS の単価 × コンテナ1台で同時処理できる数）
ケースAのように、1台で数十のリクエストを同時に処理できるなら、コンテナの稼働率が数％でもコンテナのほうが安い 計算になります。
まとめると
| 条件 | 有利なもの |
|---|---|
| アクセスが少ない・波が大きい | FaaS（またはゼロスケールできるコンテナ） |
| 一定以上のトラフィックが続く + CPU 中心 | コンテナ（稼働率が損益分岐点を超えるなら） |
| 一定以上のトラフィックが続く + 待ち時間中心 | コンテナ または CPU 時間で課金される FaaS |
| リクエスト数が非常に多い | リクエスト料金がかからないコンテナ |
6. コスト以外の比較
コストだけで決めると、運用で苦労することがあります。
| 観点 | FaaS | コンテナ実行基盤 |
|---|---|---|
| コールドスタート | あり（対策はある） | ゼロスケールしない構成ならなし |
| スケールの速さ | 速い（AWS Lambda は10秒で1,000実行環境） | 遅め（コンテナの起動に数秒〜数十秒） |
| 最大実行時間 | 短い（AWS Lambda は15分） | 長い、または制限なし |
| イベント連携 | ◎ ストレージやキューのイベントと簡単につながる | △ 自分で組む必要がある（Google Cloud Run は Eventarc でつなげる） |
| 運用の手間 | 少ない（OS やランタイムのパッチはクラウド側） | 多め（ベースイメージの更新、ヘルスチェック、AWS Fargate ならロードバランサー） |
| 冗長化 | 自動 | AWS Fargate などでは自分で台数を確保する |
| 言語・ライブラリの自由度 | ランタイムに縛られる | ◎ 何でも動く |
| 移しやすさ | 低め（イベント形式がクラウドごとに違う） | ◎ コンテナならどこでも動く |
| ローカルとの差 | 出やすい | ほぼない |
7. 中間の選択肢が増えている
2025〜2026年にかけて、FaaS とコンテナの 中間にあたる選択肢 が増えています。
| サービス | 位置づけ |
|---|---|
| AWS Lambda Web Functions | FaaS だが、普通の HTTP サーバーを動かせて、同時処理も CPU 時間課金もある。コンテナに近い FaaS |
| AWS Lambda Managed Instances | AWS Lambda のプログラミングモデルのまま、EC2 の料金で動かす。高トラフィック向け |
| Google Cloud Run functions / Google Cloud Run | 同じ基盤の上で、課金方式を選べる |
| Azure Container Apps / Google Cloud Run / さくら AppRun 共用型 | ゼロスケールできるコンテナ。FaaS に近いコンテナ |
| Cloudflare Workers + Cloudflare Containers | 軽い処理は Cloudflare Workers、重い処理は Cloudflare Containers に振り分ける構成 |
左ほど「使った分だけ払う・運用が楽」、右ほど「常に動かす・単価が安い・自由度が高い」という並びです。
8. 選び方
まとめ
- コンテナ実行基盤は、複数のリクエストを同時に処理するのが前提 で、計算資源の単価も FaaS より安い。
- そのため、リクエストが途切れずに来るケースでは、基本的にコンテナのほうが安い。特に、待ち時間の長い処理と、リクエスト数が非常に多い処理で差が大きい。
- ただし、次の場合は例外になる。
- アクセスが少ない・波がある → FaaS が有利（ゼロスケールできるコンテナなら互角）
- CPU 時間だけで課金される FaaS（Cloudflare Workers、AWS Lambda Web Functions） → 待ち時間の長い処理では、コンテナと互角以上
- リクエスト料金がかかるコンテナ（Azure Container Apps） → リクエスト数が多いと FaaS と差がつかない
- 比べるべきは「FaaS かコンテナか」ではなく、「何に課金されるか」と「稼働率」。
- コスト以外では、FaaS は イベント連携と運用の楽さ、コンテナは 自由度と移しやすさ が強み。
次回は、マルチクラウド間の移しやすさ（ポータビリティ） を比べる予定です。今回わかった「コンテナは移しやすい」という点も、詳しく掘り下げます。
参考
- AWS Lambda 料金
- AWS Fargate 料金
- Elastic Load Balancing 料金
- Cloud Run の料金（Google Cloud）
- Azure Functions の料金
- Azure Container Apps の料金
- Cloudflare Workers Pricing
- Cloudflare Containers Pricing
- AppRun 共用型（さくらのクラウド）
- AppRun 専有型（さくらのクラウド）
- Scaling Lambda Web Functions（AWS）
- Scaling Lambda Managed Instances（AWS）
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の未来予想 |