はじめに
前回（#2）では、主要クラウドの FaaS を 仕様（制約、料金、言語、閉域網など）で比べました。今回は 運用 の観点で比べます。
採用したあとに効いてくるのは、次のような点です。
- デプロイやロールバックを安全に、楽にできるか
- ログ、メトリクス、トレースが標準でどこまでそろっているか
- ローカルで動いたのに、クラウドに上げたら動かない という事態をどこまで防げるか
- ランタイムのサポート終了（EOL）に、どれくらい追われるか
比較対象は前回と同じです。
- AWS Lambda（Event Functions）
- Google Cloud Run functions
- Azure Functions（Flex Consumption プラン）
- Cloudflare Workers
- さくら AppRun（さくらのクラウド AppRun 共用型）
この記事の情報は 2026年11月時点 の各社の公式ドキュメントに基づいています。運用まわりのツールは更新が速いので、最新の情報は公式ドキュメントで確認してください。
総合比較マトリクス
| 項目 | AWS Lambda | Google Cloud Run functions | Azure Functions | Cloudflare Workers | さくら AppRun |
|---|---|---|---|---|---|
| 主なデプロイ手段 | SAM / CDK / CLI / コンソール |
gcloud / コンソール |
func / az / VS Code |
Wrangler | コンソール / API / apprun-cli |
| 公式の IaC | CloudFormation（SAM、CDK） | ― | Bicep / ARM | ― | ― |
| Terraform | ◎ | ◎ | ◎ | ◎ | ○（公式プロバイダー） |
| バージョン管理 | バージョンとエイリアス | リビジョン | ―（スロットなし） | バージョン（直近100件） | バージョン |
| トラフィック分割 | ○ エイリアスの重み付け、CodeDeploy | ○ リビジョンごとに割合を指定 | ×（ローリング更新のみ） | ○ 段階的デプロイ | ○ 最大4バージョン |
| ロールバック | ◎ エイリアスの付け替え、CodeDeploy で自動 | ◎ トラフィックを戻す | △ 前のバージョンを再デプロイ | ◎ wrangler rollback
|
○ トラフィックを戻す |
| ローカル実行 | SAM CLI（Docker） | Functions Framework / コンテナ | Core Tools + Azurite | Wrangler（workerd） | Docker |
| ローカルとクラウドの再現度 | △ | ○ | △ | ◎ | ◎ |
| クラウド上でのデバッグ | ○ リモートデバッグ（VS Code） | △ | △ | ○ 実リソースへのリモートバインディング | × |
| 標準のログ | CloudWatch Logs | Cloud Logging | Application Insights | Cloudflare Workers Logs（保存期間は最大7日） | モニタリングスイート |
| 標準のメトリクス | CloudWatch | Cloud Monitoring | Azure Monitor | ダッシュボード | モニタリングスイート |
| 分散トレース | X-Ray / OpenTelemetry（ADOT） | Cloud Trace / OpenTelemetry | Application Insights / OpenTelemetry | Traces（ベータ）/ OpenTelemetry へのエクスポート | ― |
| ランタイムの EOL 対応 | 必要（180日前に通知） | 必要 | 必要 | 基本的に不要（互換性日付で管理） | 自分で管理（ベースイメージ） |
| ワークロード ID | 実行ロール（IAM） | サービスアカウント | マネージド ID | バインディング | ―（シークレットの環境変数で渡す） |
ここからは、項目ごとに詳しく見ていきます。
1. デプロイ
デプロイ手段と IaC
| サービス | CLI | 公式の IaC | Terraform | CI/CD との連携 |
|---|---|---|---|---|
| AWS Lambda |
aws / sam
|
SAM、CDK（CloudFormation） | ◎ | GitHub Actions（OIDC）、CodePipeline |
| Google Cloud Run functions | gcloud run deploy --source |
―（Terraform が事実上の標準） | ◎ | GitHub Actions（Workload Identity 連携）、Cloud Build |
| Azure Functions |
func azure functionapp publish / az
|
Bicep / ARM | ◎ | GitHub Actions（OIDC）、Azure Pipelines |
| Cloudflare Workers | wrangler deploy |
―（wrangler.toml / wrangler.jsonc が定義ファイルを兼ねる） |
◎ | GitHub Actions（API トークン）、Cloudflare Workers Builds |
| さくら AppRun | apprun-cli deploy |
― | ○ 公式プロバイダー | GitHub Actions（apprun-cli） |
デプロイコマンドの例
同じ「HTTP の関数を1つデプロイする」操作でも、コマンドはかなり違います。
AWS Lambda（SAM）
sam build && sam deploy --guided
Google Cloud Run functions
gcloud run deploy my-func --source . --function handler \
--base-image nodejs24 --region asia-northeast1
Azure Functions（Flex Consumption）
func azure functionapp publish my-func-app
Cloudflare Workers
npx wrangler deploy
さくら AppRun（apprun-cli）
# アプリ定義（JSON / Jsonnet）とクラウド上の設定の差分を確認する
apprun-cli diff --app app.json
# デプロイする（アプリ名が新しければ、アプリが新規作成される）
apprun-cli deploy --app app.json
さくら AppRun の apprun-cli diff は、ローカルの定義とクラウド上の設定の差分を、デプロイ前に表示できます。ほかのサービスでは、Terraform の plan や CloudFormation の変更セットが同じ役割を果たします。
さくら AppRun のデプロイの流れ
さくら AppRun は コンテナイメージを登録してから、アプリの設定でそのイメージを参照する という2段階になります。
-
docker build --platform linux/amd64でイメージを作る（arm64 は動かない） - さくらのクラウドのコンテナレジストリ（または外部のレジストリ）に push する
- apprun-cli やコントロールパネルで、アプリのイメージのタグを更新する
2. バージョン管理・トラフィック分割・ロールバック
カナリアリリース（新しいバージョンに少しずつトラフィックを流すこと）ができるかどうかは、本番運用の安全性に直結します。
| サービス | 仕組み | カナリアリリース | ロールバック |
|---|---|---|---|
| AWS Lambda | 不変の バージョン と、それを指す エイリアス | ◎ エイリアスの重み付けルーティング。CodeDeploy を使えば、段階的な切り替えとアラームによる自動ロールバックができる | ◎ エイリアスを前のバージョンに付け替える |
| Google Cloud Run functions | デプロイのたびに リビジョン が作られる | ◎ リビジョンごとに割合を指定。タグ付きの URL で、新しいリビジョンだけを先に確認できる | ◎ トラフィックを前のリビジョンに戻す |
| Azure Functions | アプリに1つの状態を持つ（Flex は デプロイスロット非対応） | × | △ 前の正常なバージョンを再デプロイする（自動ロールバックはない） |
| Cloudflare Workers | アップロードのたびに バージョン が作られる | ◎ 段階的デプロイで割合を指定（直近100バージョンから選べる） | ◎ wrangler rollback
|
| さくら AppRun | 設定を変えるたびに バージョン が作られる | ○ 最大4バージョンに割合で振り分け | ○ トラフィックを前のバージョンに戻す |
Azure Functions（Flex Consumption）にはデプロイスロットがありません。 2026年6月に ローリング更新 が GA になり、ダウンタイムなしでデプロイできるようになりました。ただし、割合を指定したカナリアリリースや、自動のロールバックはできません。従来のプランでスロットを使っていた場合は、運用の設計を見直す必要があります。
3. ローカル開発と、クラウドとの差分
今回いちばん掘り下げたいテーマです。
各サービスのローカル実行の方法
| サービス | 主なツール | 仕組み | 再現度 |
|---|---|---|---|
| AWS Lambda | SAM CLI（sam local invoke / start-api） |
AWS Lambda の公式イメージを Docker で動かす | △ 関数本体は再現できるが、周りの AWS サービスは別途用意する必要がある |
| Google Cloud Run functions | Functions Framework / コンテナの実行 | 本番と同じコンテナイメージをそのまま動かせる | ○ |
| Azure Functions | Core Tools（func start）+ Azurite |
Functions ホストをローカルで動かし、ストレージはエミュレーターを使う | △ |
| Cloudflare Workers | Wrangler（wrangler dev）/ Vite プラグイン |
本番と同じ workerd ランタイム をローカルで動かす | ◎ |
| さくら AppRun | Docker | 本番と同じコンテナイメージをそのまま動かせる | ◎ |
LocalStack の提供形態が変わりました。 2026年3月に Community 版のサポートが終わり、Docker イメージを使うにはアカウントと認証トークンが必要になりました。非商用なら無料プランがありますが、商用では有料プランが必要 です。CI で localstack/localstack:latest を使っていた場合は、見直しが必要です。
「ローカルでは動いたのに、クラウドでは動かない」の原因
ローカルとクラウドで差が出やすいポイントを、カテゴリごとに整理しました。
| カテゴリ | AWS Lambda | Google Cloud Run functions | Azure Functions | Cloudflare Workers | さくら AppRun |
|---|---|---|---|---|---|
| 実行環境 | ほぼ同じ（公式イメージ） | 同じ（同じイメージ） | ホストのバージョンが違うことがある | 同じ（workerd） | 同じ（同じイメージ） |
| CPU アーキテクチャ | arm64 / x86 を合わせる必要あり | ― | ― | ― | amd64 のみ。Apple Silicon でのビルドに注意 |
| 権限 | ローカルは自分の IAM、本番は実行ロール。権限不足が最も多い | ローカルは自分の認証情報、本番はサービスアカウント | ローカルは接続文字列、本番は マネージド ID になりやすい | API トークンとバインディング | 差は少ない |
| イベントソース | S3 や SQS のイベントは JSON を手で用意する | Eventarc 経由のイベントは再現しにくい | キューや Blob のトリガーは Azurite で一部だけ再現できる | Queues や Cron はローカルでも再現できる | HTTP のみなので差は少ない |
| ネットワーク | VPC 内の RDS などにローカルから届かない | VPC 内のリソースに届かない | VNet 内のリソースに届かない | Cloudflare Workers VPC 経由の接続はローカルで再現しにくい | 共用型は閉域網に入れないので差は少ない |
| 設定・シークレット | 環境変数、Secrets Manager | 環境変数、Secret Manager |
local.settings.json は デプロイされない
|
.dev.vars はローカル専用 |
環境変数、シークレット |
| 制限値 | タイムアウト、メモリ、ペイロード 6 MB | タイムアウト、同時処理数 | HTTP の応答は230秒まで、起動は30秒まで | CPU 時間、メモリ 128 MB | リクエストのタイムアウト（既定 60秒）、使えないポート がある |
| 同時実行 | ローカルは1つずつ | ローカルは同時処理数を再現しにくい | 同時処理数の違いでスレッドセーフの問題が出る | ― | ― |
| コールドスタート | ローカルでは体感できない | 同左 | 同左 | ほぼ問題なし | ゼロスケール時に数秒〜十数秒 |
サービスごとのハマりどころ
AWS Lambda
- IAM 権限の不足 が最も多い原因です。ローカルでは開発者の強い権限で動くので、本番の実行ロールに必要な権限が足りないことに気づけません。
- VPC 内のリソース（RDS、ElastiCache など）には、ローカルから直接つなげません。
- re:Invent 2025 で、クラウド上で動いている関数を VS Code からリモートデバッグ できる機能が発表されました。本物の IAM ロールや VPC の上でブレークポイントを置けるので、「クラウドでしか起きないバグ」の調査がかなり楽になります（開発・テスト用の機能です）。
Google Cloud Run functions
- 中身はコンテナなので、ローカルとクラウドの差は小さい ほうです。
- 差が出るのは、Eventarc 経由のイベントの形式と、サービスアカウントの権限です。
- Pub/Sub や Firestore には公式のエミュレーターがあります。
Azure Functions
-
local.settings.jsonはデプロイされません。 設定をアプリ設定に入れ忘れると、本番だけ動きません。 - ローカルでは接続文字列を使い、本番では マネージド ID（ID ベースの接続）を使う構成にしがちです。認証方式の違いで本番だけ失敗する、というパターンに注意しましょう。
- Flex Consumption には固有の制約があります。たとえば、起動の初期化は30秒でタイムアウト（変更不可）し、
TZやWEBSITE_TIME_ZONEの設定にも対応していません。
Cloudflare Workers
- ローカルでも 本番と同じ workerd ランタイム が動くので、5サービスの中では最も再現度が高いです。タイムゾーンも UTC にそろえてくれます。
- KV、R2、D1 などのバインディングは、ローカルではシミュレーションで動きます（中身は空の状態から始まる）。
- Cloudflare Workers AI や Vectorize などはローカルで再現できません。バインディングに
remote: trueを付けると、コードはローカルで動かしたまま、本番のリソースにつなげます。ただし、本番のデータに書き込まれ、料金もかかるので注意が必要です。
さくら AppRun
- コンテナがそのまま動くので、ローカルとクラウドの差はほぼありません。
- 注意点は次の3つです。
-
amd64 でビルドしているか（Apple Silicon の Mac では
--platform linux/amd64を付ける） - 使えないポート（8008、8012、8013、8022、8443、9090、9091）を使っていないか
- ゼロスケールからの起動時間（数秒〜十数秒）を許容できるか
-
amd64 でビルドしているか（Apple Silicon の Mac では
差分を減らすための実践チェックリスト
- 本番と 同じ権限 のロールで、ステージング環境を用意する
- CPU アーキテクチャ（arm64 / amd64）を、ローカルと本番でそろえる
- 設定とシークレットは IaC で管理し、ローカル専用のファイルに頼らない
- タイムアウトやペイロードの上限など、本番の制限値で負荷テスト をする
- イベントのサンプル JSON を、本番で実際に届いたものから作る
- 同時処理数を 1 より大きくするなら、スレッドセーフかどうかを確認する
-
最後の確認は必ずクラウド上で行う（AWS Lambda のリモートデバッグ、Cloudflare Workers の
remote: trueなどを活用する）
4. 監視・可観測性
ログ
| サービス | 標準の出力先 | 保存期間 | 料金の考え方 |
|---|---|---|---|
| AWS Lambda | CloudWatch Logs | 自分で設定（既定は無期限） | 取り込み量と保存量で課金。AWS Lambda のログは量に応じた段階的な料金 |
| Google Cloud Run functions | Cloud Logging | 既定 30日 | 取り込み量で課金（毎月の無料枠あり） |
| Azure Functions | Application Insights（Log Analytics） | 既定 90日 | 取り込み量で課金（毎月の無料枠あり） |
| Cloudflare Workers | Cloudflare Workers Logs | Free: 3日 / 有料: 7日（最大7日） | 有料プランは月2,000万件まで込み、超過は100万件あたり $0.60（2026年12月から料金体系が変わる予定） |
| さくら AppRun | モニタリングスイート | モニタリングスイートの設定による | モニタリングスイートの料金 |
Cloudflare Workers Logs の保存期間は最大7日です。 長期間の保存や監査が必要なら、Logpush で R2 や S3 などに転送しましょう。
メトリクス・トレース
| サービス | メトリクス | 分散トレース | OpenTelemetry |
|---|---|---|---|
| AWS Lambda | CloudWatch（呼び出し数、エラー、実行時間、スロットリング、同時実行数など） | X-Ray | ◎ ADOT（AWS Distro for OpenTelemetry）のレイヤー |
| Google Cloud Run functions | Cloud Monitoring（リクエスト数、レイテンシ、インスタンス数、CPU、メモリ） | Cloud Trace | ◎ |
| Azure Functions | Azure Monitor / Application Insights | Application Insights | ◎ |
| Cloudflare Workers | ダッシュボード（リクエスト数、エラー率、CPU 時間、経過時間） | Traces（ベータ、自動計装） | ○ ログとトレースをエクスポートできる |
| さくら AppRun | モニタリングスイート（リクエスト数、レイテンシ、インスタンス数、CPU、メモリ、再起動回数） | ― | △ アプリ側で OpenTelemetry を組み込み、外部の基盤に送る |
- Azure Functions の Application Insights は、ログ、メトリクス、トレース、依存関係のマップまで1つにまとまっています。標準機能の充実度では一歩リードしています。
- さくら AppRun はメトリクスとログはそろっていますが、分散トレースの標準機能はありません。
5. ランタイムの EOL（サポート終了）への対応
長く運用するほど効いてくる項目です。
| サービス | 方針 | 古いランタイムのまま放置するとどうなるか |
|---|---|---|
| AWS Lambda | 非推奨になる 180日以上前に通知。非推奨になってから、30日以降に新規作成、60日以降に更新がブロックされる（多くのランタイムは、実際にはもっと後ろ倒し） | 呼び出しは続けられるが、パッチが当たらず、サポートも受けられない |
| Google Cloud Run functions | ランタイムごとに非推奨日と廃止日が決まっている（例: Node.js 20 は非推奨から約6か月後に廃止） | 廃止後は、そのランタイムでデプロイできない |
| Azure Functions | 言語のバージョンごとにサポート期限がある | 動き続けるが、サポート対象外になる |
| Cloudflare Workers | 互換性日付（compatibility date）で挙動を固定する方式。ランタイムの EOL という概念が基本的にない | 古い互換性日付のままでも動き続ける |
| さくら AppRun | ベースイメージは 自分で管理 する | 強制的な EOL はないが、脆弱性対応は自己責任 |
AWS Lambda のランタイム管理: 既定の「Auto」モードでは、マイナーバージョンのセキュリティパッチを AWS が自動で当てます。メジャーバージョンを上げる（例: Python 3.12 → 3.14）のは利用者の作業です。
Cloudflare Workers の互換性日付 は、運用の負担を大きく減らせる仕組みです。wrangler.toml に compatibility_date = "2026-11-01" のように日付を書くと、その日時点の挙動に固定されます。新しい挙動を使いたくなったら、日付を進めればよいだけです。
6. 権限管理（ワークロード ID）
関数がほかのクラウドリソースにアクセスするときの、認証の仕組みです。
| サービス | 仕組み | シークレットなしで認証できるか |
|---|---|---|
| AWS Lambda | 実行ロール（IAM ロール） | ◎ |
| Google Cloud Run functions | サービスアカウント | ◎ |
| Azure Functions | マネージド ID（システム割り当て / ユーザー割り当て） | ◎ |
| Cloudflare Workers | バインディング（KV、R2、D1 など Cloudflare のリソース） | ○ Cloudflare のリソースなら可。外部のクラウドには API キーなどが必要 |
| さくら AppRun | ―（公開されている情報では、ワークロード ID に相当する仕組みを確認できず） | × シークレットの環境変数で認証情報を渡す |
7. 運用のしやすさの総合評価
| 観点 | AWS Lambda | Google Cloud Run functions | Azure Functions | Cloudflare Workers | さくら AppRun |
|---|---|---|---|---|---|
| デプロイ | ◎ | ◎ | ○ | ◎ | ○ |
| リリースの安全性（カナリア・ロールバック） | ◎ | ◎ | △ | ◎ | ○ |
| ローカルとクラウドの再現度 | △ | ○ | △ | ◎ | ◎ |
| 可観測性 | ◎ | ◎ | ◎ | ○ | △ |
| EOL 対応の手間 | △ | △ | △ | ◎ | ○（自分で管理） |
| 権限管理 | ◎ | ◎ | ◎ | ○ | △ |
まとめ
- AWS Lambda は、デプロイ、リリース、監視の機能が最も成熟しています。一方で、ローカルでの再現度は低めです。リモートデバッグやステージング環境で補う前提で設計しましょう。
- Google Cloud Run functions は、コンテナベースなのでローカルとの差が小さく、リビジョンによるトラフィック分割も使いやすいです。
- Azure Functions Flex は、Application Insights による可観測性が強みです。ただし、デプロイスロットがない ので、リリース戦略には注意が必要です。
- Cloudflare Workers は、ローカルの再現度が最も高く、互換性日付のおかげで EOL 対応もほぼ不要です。ログの保存期間（最大7日）とトレース（ベータ）が弱点です。
-
さくら AppRun は、コンテナなのでローカルとの差がほぼなく、
apprun-cli diffのような地に足のついたツールもあります。一方で、分散トレースやワークロード ID はまだそろっていません。
次回（#4）は、マルチクラウド間の移しやすさ（ポータビリティ） を比べる予定です。
参考
- AWS Lambda ランタイムの非推奨ポリシー（AWS）
- AWS Lambda ランタイムの更新（AWS）
- re:Invent 2025 – Debug Lambda functions deployed in cloud like never before（AWS re:Post）
- Important Updates to Pricing & Packaging for LocalStack for AWS（LocalStack）
- Google Cloud Run functions のランタイム（Google Cloud）
- Azure Functions のローカル開発（Microsoft Learn）
- Flex Consumption の更新戦略（Microsoft Learn）
- Generally Available: Rolling updates in Flex Consumption
- Azure Functions Flex Consumption プラン（Microsoft Learn）
- Workers のローカル開発（Cloudflare）
- Workers Observability（Cloudflare）
- Cloudflare Workers Logs（Cloudflare）
- Gradual deployments（Cloudflare）
- さくら AppRun コントロールパネル操作ガイド（さくらのクラウド）
- さくらのAppRun正式版がリリースされる、その前に（Zenn / さくらインターネット）
- さくらのAppRunとは？料金と共用型・専有型の違い（issoh）
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の未来予想 |