Cloud Run vs Cloud Functions vs App Engine：GCP 無伺服器服務怎麼選？

開場：Serverless 不是只有一種選擇

「我想部署一個 API，用 Serverless 就好了吧？」

這句話在 2026 年的 GCP 生態系裡，可能會冒出三個完全不同的答案：Cloud Run、Cloud Functions（Cloud Run functions）、App Engine。它們都號稱「無伺服器」，都能自動擴充，也都不用你管 VM，但底層架構、計費邏輯、適用場景其實差很多。

選錯服務不會讓你的應用「壞掉」，但會害你：

多付 3-5 倍的帳單（例如用 App Engine Flexible 跑一個每天只被呼叫 10 次的 API）
承受不必要的冷啟動延遲（例如用 Cloud Functions Gen1 跑延遲敏感的即時服務）
被迫重構（例如需要 WebSocket 但選了不支援的服務）

這篇文章會用一張總覽表 + 六大面向比較 + 決策樹 + 部署範例，幫你在 5 分鐘內選對 GCP 無伺服器服務。

讀完這篇文章，你將學到：

Cloud Run、Cloud Functions、App Engine 三者的本質差異
六大關鍵面向的詳細比較（冷啟動、定價、Scale-to-zero、語言支援、觸發機制、部署方式）
一棵可直接使用的選型決策樹
每個服務的快速部署指令
2026 年 Google 的 Serverless 整合策略
5 題 ACE 考試常見的選型情境題

三大服務一覽比較表

先用一張大表抓個全貌，後面再一個一個細看。

面向	Cloud Run	Cloud Functions (Cloud Run functions)	App Engine Standard	App Engine Flexible
本質	容器即服務 (CaaS)	函式即服務 (FaaS)	平台即服務 (PaaS)	平台即服務 (PaaS)
部署單位	Docker 容器映像	單一函式（原始碼）	原始碼 + app.yaml	Docker 容器 + app.yaml
觸發方式	HTTP、gRPC、Pub/Sub、Eventarc	HTTP、Eventarc、Cloud Storage、Pub/Sub 等 30+ 事件源	HTTP 請求	HTTP 請求
Scale-to-zero	✅	✅	✅	❌（最少 1 個實例）
最大請求超時	60 分鐘	9 分鐘（Gen1）/ 60 分鐘（Gen2）	10 分鐘	60 分鐘
並行處理	每個實例最多 1000 個並行請求	每個實例 1 個請求（Gen1）/ 最多 1000（Gen2）	自動管理	自動管理
冷啟動	秒級（取決容器大小）	毫秒至秒級	毫秒級	分鐘級（啟動 VM）
語言限制	無限制（任何能跑在容器的語言）	指定 runtime（Node.js、Python、Go、Java、.NET、Ruby、PHP）	指定 runtime	無限制（Docker）
WebSocket	✅	❌	❌（Standard）/ ✅（Flexible）	✅
gRPC	✅	❌	❌	❌
HTTP/2	✅	✅（Gen2）	❌	❌
VPC 連接	直接 VPC Egress 或 Connector	VPC Connector	VPC Connector	原生 VPC
最低月費	$0（Scale-to-zero）	$0（Scale-to-zero）	$0（Scale-to-zero）	~$40+（至少 1 實例）
免費額度	每月 200 萬次請求 + 360,000 GiB-秒	每月 200 萬次呼叫 + 400,000 GB-秒	28 F-hours/天	無

重要名詞更新： 從 2024 年開始，Cloud Functions Gen2 已正式更名為 Cloud Run functions，底層完全跑在 Cloud Run 基礎設施上。Gen1 已進入維護模式（maintenance mode），新專案應一律使用 Gen2 / Cloud Run functions。

各服務深入介紹

Cloud Run：容器化 + Serverless 的最佳結合

Cloud Run 算是 GCP 無伺服器家族的「主角」。它的概念很單純：你給我一個容器映像，我幫你跑，你只付實際用掉的資源。

架構特色

開發者
  │
  ├── 1. 寫程式碼（任何語言、任何框架）
  ├── 2. 打包成 Docker 容器
  ├── 3. 推送到 Artifact Registry
  └── 4. gcloud run deploy
        │
        ▼
  Cloud Run 平台
  ├── 自動分配 HTTPS 端點
  ├── 自動 TLS 證書
  ├── 根據流量自動擴充 0 → N 個實例
  ├── 支援自訂網域
  └── 整合 IAM、Cloud Logging、Cloud Trace

核心優勢

語言無限制：只要能打包成容器，Rust、Elixir、Haskell 都行
多協定支援：HTTP/1.1、HTTP/2、gRPC、WebSocket 全部支援
並行處理：單一實例可同時處理最多 1000 個請求，大幅降低冷啟動影響
最長超時 60 分鐘：適合長時間運算任務
Cloud Run Jobs：支援非 HTTP 的批次任務（資料處理、ML 推論、報表產生）
GPU 支援：2025 年起支援掛載 NVIDIA GPU，適合 AI/ML 推論工作負載
最小實例數：可設定 --min-instances 保持暖機，消除冷啟動

適用場景

微服務架構的 API 後端
需要自訂系統依賴（如 FFmpeg、ImageMagick）的應用
容器化的 Web 應用程式
需要 gRPC 或 WebSocket 的即時通訊服務
AI/ML 模型推論服務
從 Kubernetes 遷移但想降低維運負擔的團隊

不適合的場景

極端低延遲需求（冷啟動仍需數秒）
需要持久性磁碟存取（Cloud Run 是無狀態的）
需要 24/7 長連線的應用（有 60 分鐘超時限制）

Cloud Functions（Cloud Run functions）：事件驅動的輕量函式

Cloud Functions 的定位是最簡單的事件驅動運算。你只要寫一個函式，告訴它「某個事件發生時就跑」，剩下的丟給 Google 就好。

Gen1 vs Gen2（Cloud Run functions）

特性	Gen1（維護模式）	Gen2（Cloud Run functions）
底層	專屬 FaaS 基礎設施	Cloud Run
並行	每實例 1 個請求	每實例最多 1000 個請求
超時	最長 9 分鐘	最長 60 分鐘
流量分割	❌	✅（繼承 Cloud Run）
最小實例	❌	✅
事件來源	Cloud Storage、Pub/Sub、HTTP 等	Eventarc 整合 90+ 事件源
VPC	VPC Connector	VPC Connector 或直接 VPC Egress
狀態	仍可用但不再新增功能	推薦使用

考試重點： Gen2 / Cloud Run functions 的底層就是 Cloud Run，所以它繼承了 Cloud Run 的所有基礎設施特性（並行、超時、流量分割等）。

核心優勢

極簡開發體驗：不需要 Dockerfile、不需要 HTTP 框架，寫一個函式就完成
原生事件整合：Cloud Storage 檔案上傳、Pub/Sub 訊息、Firestore 文件變更等，開箱即用
最低學習曲線：適合後端經驗較少的前端開發者或資料工程師
自動依賴管理：只需 requirements.txt 或 package.json

適用場景

檔案上傳後的自動處理（壓縮圖片、轉檔、掃毒）
Pub/Sub 訊息消費者
排程任務（搭配 Cloud Scheduler）
Webhook 接收端點
IoT 資料流處理
資料庫觸發器（Firestore onChange）
簡單的 REST API（一兩個端點）

不適合的場景

完整的 Web 應用程式（多路由、中介軟體）
需要 WebSocket 或 gRPC 的即時服務
需要自訂系統依賴的工作負載（用 Cloud Run）
大型微服務架構（管理數十個函式會很痛苦）

App Engine：全託管平台（Standard vs Flexible）

App Engine 是 GCP 最老牌的服務（2008 年推出），也是世界上最早的雲端 PaaS 之一。到了 2026 年，它還是有它站得住腳的位置。

Standard vs Flexible 關鍵差異

App Engine Standard                    App Engine Flexible
┌─────────────────────┐               ┌─────────────────────┐
│   Google 沙盒容器     │               │   Compute Engine VM  │
│   (gVisor)          │               │   + Docker 容器       │
│                     │               │                     │
│ ✅ Scale-to-zero    │               │ ❌ 最少 1 個實例     │
│ ✅ 毫秒級啟動       │               │ ❌ 分鐘級啟動       │
│ ✅ 免費額度          │               │ ❌ 無免費額度        │
│ ❌ 指定語言 runtime  │               │ ✅ 任何語言          │
│ ❌ 唯讀檔案系統      │               │ ✅ 可寫檔案系統      │
│ ❌ 無 WebSocket     │               │ ✅ WebSocket         │
│ ❌ 無 SSH           │               │ ✅ 可 SSH 連入       │
└─────────────────────┘               └─────────────────────┘

核心優勢

極致簡化部署：gcloud app deploy 一行指令，不需要 Dockerfile
內建功能豐富：Cron 排程（cron.yaml）、Task Queue、流量分割、版本管理
流量分割：可在多個版本之間精確分割流量（金絲雀部署、A/B 測試）
一個專案一個應用：強制單一入口，簡化架構管理

App Engine 的限制（為什麼很多人轉向 Cloud Run）

一個專案只能有一個 App Engine 應用，且不可刪除、不可更換區域
Standard 語言版本更新慢（需要等 Google 提供新 runtime）
Flexible 不能 scale-to-zero，空閒時仍然計費
不支援容器映像的完全自訂（Standard）
第三方服務整合不如 Cloud Run 靈活

適用場景

快速原型驗證（最少配置即可上線）
傳統 Web 應用程式（MVC 架構）
需要內建 Cron 排程的應用
已有 App Engine 應用且運作良好（不需要為了「新潮」而遷移）
團隊不熟悉 Docker/容器化

不適合的場景

需要多區域部署的應用（App Engine 鎖定單一區域）
需要自訂系統層依賴的應用（Standard）
追求最低成本且流量不穩定的應用（Flexible 不能 scale-to-zero）
微服務架構（Cloud Run 更適合）

六大面向深入比較

面向一：冷啟動與效能

冷啟動是 Serverless 最讓人頭痛的地方。服務從零開始拉一個新實例來接請求時，使用者就會感覺到那段延遲。

服務	冷啟動時間	影響因素	最佳化方式
Cloud Run	500ms - 5s	容器映像大小、語言 runtime、初始化邏輯	最小實例（min-instances）、使用小映像（distroless/alpine）、延遲初始化
Cloud Functions Gen2	300ms - 3s	依賴套件大小、語言選擇	最小實例、減少依賴、選擇 Go/Node.js
App Engine Standard	100ms - 1s	runtime 類型、初始化邏輯	warmup 請求、最小實例
App Engine Flexible	30s - 3min	VM 啟動 + 容器啟動	始終至少 1 個實例（無法 scale-to-zero）

冷啟動對策略：

延遲敏感的 API（< 200ms）
  → App Engine Standard（最快冷啟動）
  → 或 Cloud Run + min-instances >= 1（消除冷啟動但持續付費）

偶爾呼叫的背景任務
  → Cloud Functions Gen2（冷啟動可接受）
  → Cloud Run（冷啟動可接受）

每秒數百請求的高流量服務
  → Cloud Run（並行處理減少實例數 → 減少冷啟動頻率）

面向二：定價模式

這大概是選型時最現實的考量了。三個服務的計費邏輯完全不一樣。

Cloud Run 定價

費用 = CPU 時間 + 記憶體時間 + 請求數

CPU:    $0.00002400 / vCPU-秒
記憶體:  $0.00000250 / GiB-秒
請求:    $0.40 / 百萬次請求

免費額度（每月）:
- 200 萬次請求
- 180,000 vCPU-秒
- 360,000 GiB-秒

Cloud Run 有兩種 CPU 分配模式：

僅在處理請求時分配 CPU（預設）：省錢，但背景任務會被暫停
始終分配 CPU：適合需要背景處理的服務，但費用較高

Cloud Functions 定價

費用 = 呼叫次數 + 運算時間 + 網路流出

呼叫:    $0.40 / 百萬次（前 200 萬次免費）
運算:    $0.0000025 / GB-秒（前 400,000 GB-秒免費）
網路:    $0.12 / GB（前 5 GB 免費）

App Engine 定價

Standard:
  費用 = 實例小時 × 實例等級費率
  F1: $0.05/hr | F2: $0.10/hr | F4: $0.20/hr
  免費: 28 F-hours/天

Flexible:
  費用 = vCPU 小時 + 記憶體小時
  vCPU: $0.0526/hr
  記憶體: $0.0071/GB-hr
  ⚠️ 沒有免費額度、不能 scale-to-zero

不同流量模式的月費估算

場景	月請求數	Cloud Run	Cloud Functions	App Engine Standard
個人部落格 API	1 萬	~$0（免費額度內）	~$0（免費額度內）	~$0（免費額度內）
中小型 SaaS	100 萬	~$5-15	~$8-20	~$15-30
高流量電商	1 億	~$150-400	~$200-500	~$300-600
背景批次處理	1 千（但每次 10 分鐘）	~$20-50	~$15-40	N/A（超時限制）

省錢提示： 如果你的服務流量很低且不規律，Cloud Run 和 Cloud Functions 的 scale-to-zero 能力是最大的省錢利器。App Engine Flexible 即使沒流量也要付最少約 $40/月。

面向三：Scale-to-zero

Scale-to-zero 的意思是「沒流量的時候，一個實例都不留，所以也不會產生費用」。

服務	Scale-to-zero	備註
Cloud Run	✅	預設行為
Cloud Functions	✅	預設行為
App Engine Standard	✅	預設行為
App Engine Flexible	❌	最少 1 個實例始終運行

                    流量曲線
請求數  ▲
        │     ╱╲
        │    ╱  ╲        ╱╲
        │   ╱    ╲      ╱  ╲
        │  ╱      ╲    ╱    ╲
        │ ╱        ╲  ╱      ╲
────────┼───────────╲╱────────╲──────→ 時間

Cloud Run 實例數:
        │     ╱╲
        │    ╱  ╲        ╱╲
        │   ╱    ╲      ╱  ╲
   0 ───┼──╱──────╲────╱────╲────── ← 空閒時回到 0
        │
        └─────────────────────────→

App Engine Flexible 實例數:
        │     ╱╲
        │    ╱  ╲        ╱╲
        │   ╱    ╲      ╱  ╲
   1 ───┼──╱──────╲──1─╱────╲──1── ← 永遠至少 1 個
        │
        └─────────────────────────→

面向四：語言與框架支援

服務	支援語言	框架限制
Cloud Run	任何語言（只要能容器化）	無限制——Django、FastAPI、Express、Gin、Actix、Phoenix…
Cloud Functions	Node.js、Python、Go、Java、.NET、Ruby、PHP	必須使用 Functions Framework，不能自訂 HTTP 伺服器
App Engine Standard	Python、Java、Go、Node.js、PHP、Ruby	必須使用指定 runtime 版本
App Engine Flexible	任何語言（Docker）	需提供 Dockerfile 或使用預設 runtime

結論：

如果你用主流語言寫簡單函式 → Cloud Functions 最方便
如果你用主流語言寫 Web 應用 → App Engine Standard 最簡單
如果你用任何語言或需要完全自訂環境 → Cloud Run

面向五：事件觸發 vs HTTP

這是 Cloud Functions 最大的差異化優勢。

Cloud Functions 事件觸發生態系：

┌─────────────────┐     ┌─────────────────┐
│ Cloud Storage    │────▶│                 │
│ (檔案上傳/刪除)  │     │                 │
└─────────────────┘     │                 │
                        │  Cloud          │     ┌──────────────┐
┌─────────────────┐     │  Functions      │────▶│  你的業務邏輯  │
│ Pub/Sub          │────▶│  (Cloud Run     │     └──────────────┘
│ (訊息推送)       │     │   functions)    │
└─────────────────┘     │                 │
                        │                 │
┌─────────────────┐     │                 │
│ Firestore        │────▶│                 │
│ (文件 CRUD)      │     │                 │
└─────────────────┘     └─────────────────┘

┌─────────────────┐
│ Cloud Scheduler  │────▶ 定時觸發
└─────────────────┘

┌─────────────────┐
│ Eventarc         │────▶ 90+ GCP 服務事件
│ (Audit Log 觸發) │      (VM 建立、IAM 變更、BigQuery Job 完成...)
└─────────────────┘

對比：

Cloud Functions：原生支援事件觸發，設定觸發源就完成
Cloud Run：需透過 Eventarc 或 Pub/Sub push subscription 來接收事件（多一層設定）
App Engine：主要是 HTTP 請求驅動，排程任務用 cron.yaml

考試重點： 當題目提到「自動回應 Cloud Storage 檔案上傳」或「Pub/Sub 訊息觸發處理」，Cloud Functions 通常是最佳答案——除非有額外需求（如自訂容器、WebSocket 等）。

面向六：容器化 vs 原始碼部署

部署方式	服務	開發者需要做的事
原始碼部署	Cloud Functions	寫函式 + requirements.txt → `gcloud functions deploy`
原始碼部署	App Engine Standard	寫應用 + app.yaml → `gcloud app deploy`
容器部署	Cloud Run	寫應用 + Dockerfile → `docker build` → `gcloud run deploy`
原始碼部署	Cloud Run（Source Deploy）	寫應用 + Dockerfile 或 Buildpack → `gcloud run deploy --source .`
容器部署	App Engine Flexible	寫應用 + Dockerfile + app.yaml → `gcloud app deploy`

注意： Cloud Run 也支援 source-based deploy（gcloud run deploy --source .），系統會用 Cloud Build + Buildpacks 自動幫你建構容器。這讓 Cloud Run 的使用體驗接近 App Engine 的簡單度，同時保有容器化的彈性。

選型決策樹

懶得看上面那一大串分析？用這棵決策樹，3 個問題就能選對服務：

                        開始
                         │
                         ▼
              ┌─────────────────────┐
              │ 需要回應事件觸發？     │
              │ (Storage/Pub/Sub/   │
              │  Firestore 等)      │
              └──────┬──────┬───────┘
                     │      │
                    是      否
                     │      │
                     ▼      ▼
         ┌──────────────┐  ┌──────────────────┐
         │ 邏輯很簡單？   │  │ 需要 WebSocket/   │
         │ (單一函式,    │  │ gRPC/自訂容器？    │
         │  < 10 分鐘)   │  └──────┬──────┬────┘
         └──┬──────┬────┘         │      │
            │      │             是      否
           是      否             │      │
            │      │             ▼      ▼
            ▼      ▼      ┌──────────┐  ┌──────────────┐
    ┌──────────┐  ┌────┐  │Cloud Run │  │ 需要最簡單的  │
    │  Cloud   │  │Cloud│  │          │  │ 部署體驗？    │
    │Functions │  │ Run │  │(容器化+  │  │ (不想寫      │
    │(Gen2)    │  │     │  │ 全協定)  │  │  Dockerfile) │
    └──────────┘  └────┘  └──────────┘  └──┬──────┬────┘
                                           │      │
                                          是      否
                                           │      │
                                           ▼      ▼
                                    ┌──────────┐  ┌──────────┐
                                    │App Engine│  │Cloud Run  │
                                    │Standard  │  │(推薦預設  │
                                    │          │  │ 選擇)     │
                                    └──────────┘  └──────────┘

速記口訣：

事件觸發選 Functions，
容器自訂選 Cloud Run，
快速上線選 App Engine，
拿不定主意選 Cloud Run。

Cloud Run 是 2026 年 GCP 無伺服器的「安全牌」，它幾乎什麼場景都應付得來，又是 Google 現在投資最多的服務。

實戰部署範例

Cloud Run：部署一個容器化 Python API

# 1. 建立專案結構
mkdir my-api && cd my-api

# 2. 撰寫 main.py
cat > main.py << 'EOF'
from flask import Flask, jsonify
import os

app = Flask(__name__)

@app.route("/")
def hello():
    return jsonify({
        "message": "Hello from Cloud Run!",
        "service": os.environ.get("K_SERVICE", "unknown"),
        "revision": os.environ.get("K_REVISION", "unknown")
    })

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

# 3. 撰寫 Dockerfile
cat > Dockerfile << 'EOF'
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install flask gunicorn
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 main:app
EOF

# 4. 一鍵部署（Source Deploy 方式，免手動 docker build）
gcloud run deploy my-api \
  --source . \
  --region asia-east1 \
  --allow-unauthenticated \
  --memory 256Mi \
  --cpu 1 \
  --max-instances 10 \
  --min-instances 0

Cloud Functions（Gen2 / Cloud Run functions）：部署事件驅動函式

# 部署一個 Cloud Storage 觸發的圖片處理函式
cat > main.py << 'EOF'
import functions_framework
from google.cloud import storage

@functions_framework.cloud_event
def process_image(cloud_event):
    data = cloud_event.data
    bucket = data["bucket"]
    name = data["name"]
    print(f"Processing file: gs://{bucket}/{name}")
    # 在此加入圖片處理邏輯（壓縮、轉檔等）
EOF

cat > requirements.txt << 'EOF'
functions-framework==3.*
google-cloud-storage==2.*
EOF

# 部署（Gen2）
gcloud functions deploy process-image \
  --gen2 \
  --runtime python312 \
  --region asia-east1 \
  --source . \
  --entry-point process_image \
  --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
  --trigger-event-filters="bucket=my-image-bucket" \
  --memory 256Mi \
  --timeout 120s

App Engine Standard：部署一個 Web 應用

# 1. 建立專案結構
mkdir my-webapp && cd my-webapp

# 2. 撰寫 main.py
cat > main.py << 'EOF'
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello from App Engine!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)
EOF

# 3. 撰寫 requirements.txt
cat > requirements.txt << 'EOF'
flask==3.0.*
gunicorn==22.*
EOF

# 4. 撰寫 app.yaml（這就是 App Engine 的精髓——一個 YAML 搞定）
cat > app.yaml << 'EOF'
runtime: python312
instance_class: F2

automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 0
  max_instances: 5

entrypoint: gunicorn -b :$PORT main:app
EOF

# 5. 部署
gcloud app deploy --quiet

2026 年 Google 的策略方向

Cloud Functions → Cloud Run functions 整合趨勢

從 2024 年開始，Google 就一步步把 Cloud Functions 和 Cloud Run 併在一起：

2020-2023:  Cloud Functions (Gen1)    Cloud Run        App Engine
            獨立基礎設施               獨立服務          獨立服務
            │                         │                │
2024-2025:  Cloud Functions Gen2      Cloud Run        App Engine
            (更名為 Cloud Run          │                │
             functions, 底層是         │                │
             Cloud Run)               │                │
            └─────────┬───────────────┘                │
                      │                                │
2026+:      ┌─────────┴───────────┐                    │
            │  Cloud Run 統一平台   │                    │
            │  ├── Services       │    App Engine      │
            │  ├── Functions      │    (維護模式,       │
            │  └── Jobs           │     持續支援)       │
            └─────────────────────┘                    │

這對開發者意味著什麼？

新專案優先選 Cloud Run：它是 Google 投資最多的無伺服器平台
Cloud Functions Gen1 應遷移至 Gen2：Gen1 已不再新增功能
App Engine 不會消失：Google 承諾持續支援，但新功能開發幾乎停滯
學一套 Cloud Run，覆蓋三種工作負載：HTTP 服務（Services）、事件函式（Functions）、批次任務（Jobs）

Cloud Run 的最新功能（2025-2026）

GPU 支援：可掛載 NVIDIA L4/T4 GPU，適合 AI 推論
Always-on CPU：非請求期間也持續分配 CPU
Cloud Run Jobs：非 HTTP 的批次工作負載
多區域服務：搭配 Global External Application Load Balancer 實現多區域部署
Direct VPC Egress：不需要 VPC Connector 即可存取 VPC 資源
Sidecar 容器：支援多容器部署（主容器 + Sidecar）

ACE 考試常見選型題

題目 1

你的團隊需要建立一個服務，當使用者上傳檔案到 Cloud Storage 時，自動產生縮圖。這個處理每張圖片大約需要 30 秒。請問最適合的服務是？

A. Compute Engine B. Cloud Run C. Cloud Functions (Gen2) D. App Engine Standard

查看答案

答案：C

解析： 這是典型的事件驅動場景——「Cloud Storage 檔案上傳觸發處理」。Cloud Functions 原生支援 Cloud Storage 事件觸發，且 30 秒的處理時間遠在超時限制內。雖然 Cloud Run 搭配 Eventarc 也能做到，但 Cloud Functions 是最簡單直接的選擇。

題目 2

你需要部署一個使用 Rust 語言開發的 gRPC 微服務，需要處理即時雙向串流。請問最適合的 GCP 無伺服器服務是？

A. Cloud Functions B. App Engine Standard C. Cloud Run D. App Engine Flexible

查看答案

答案：C

解析： 三個關鍵需求決定了答案：(1) Rust 語言——只有 Cloud Run 和 App Engine Flexible 支援任意語言；(2) gRPC——只有 Cloud Run 支援；(3) 雙向串流——需要 HTTP/2 + gRPC，只有 Cloud Run 支援。Cloud Run 是唯一同時滿足三個需求的選項。

題目 3

你的公司有一個低流量的內部工具網站，每天大約 50 次存取。團隊不熟悉 Docker，想用最低成本部署。這個網站用 Python Flask 開發。請問最適合的服務是？

A. Cloud Run B. App Engine Standard C. App Engine Flexible D. Compute Engine (f1-micro)

查看答案

答案：B

解析： 關鍵條件：(1) 低流量 → 需要 scale-to-zero 降低成本，排除 C（Flexible 不能 scale-to-zero）和 D（VM 持續計費）；(2) 不熟悉 Docker → App Engine Standard 只需 app.yaml，不需 Dockerfile；(3) Python Flask → Standard 原生支援。雖然 Cloud Run 支援 source deploy，但 App Engine Standard 的部署體驗更簡單，且有免費額度（28 F-hours/天足夠 50 次存取）。

題目 4

你正在建構一個即時聊天應用，需要 WebSocket 連線，預期高峰期有 5000 個同時連線。你的團隊想使用無伺服器架構以降低維運負擔。請問最適合的方案是？

A. App Engine Standard B. Cloud Functions C. Cloud Run D. App Engine Flexible

查看答案

答案：C

解析： WebSocket 支援是關鍵需求。App Engine Standard 和 Cloud Functions 都不支援 WebSocket。App Engine Flexible 支援 WebSocket，但不能 scale-to-zero，且啟動慢（分鐘級）。Cloud Run 支援 WebSocket，且能自動擴充、scale-to-zero，是無伺服器 + WebSocket 的最佳選擇。

題目 5

你的 Cloud Functions Gen1 函式經常因為超過 9 分鐘的超時限制而失敗。這些函式處理大型 CSV 檔案，平均需要 15 分鐘。在不重寫應用邏輯的前提下，最快的解決方案是？

A. 將函式遷移到 Compute Engine B. 將函式升級到 Cloud Functions Gen2 C. 將函式拆分為多個小函式 D. 使用 Cloud Run Jobs

查看答案

答案：B

解析： 題目強調「不重寫應用邏輯」和「最快的解決方案」。Cloud Functions Gen2（Cloud Run functions）的超時上限為 60 分鐘，只需將 Gen1 升級到 Gen2 即可解決問題，程式碼幾乎不需要修改。選 A 需要大幅重構，選 C 需要重寫邏輯，選 D 雖然可行但需要調整部署方式。

FAQ

Q1：Cloud Functions Gen2 和 Cloud Run 到底有什麼差別？既然底層都是 Cloud Run？

A：主要差別在開發者體驗和觸發方式。Cloud Functions Gen2（Cloud Run functions）提供了更簡化的事件觸發設定（直接在部署指令中指定觸發源），不需要寫 Dockerfile，且會自動處理 Eventarc 的設定。Cloud Run 則給你完整的容器控制權和更多協定支援（gRPC、WebSocket）。如果你的需求是「回應事件 + 簡單函式」，用 Cloud Functions 更快；如果需要「完整 Web 服務 + 自訂容器」，用 Cloud Run。

Q2：App Engine 會被 Google 淘汰嗎？

A：短期內不會。Google 在 2025 年明確表示會持續支援 App Engine，但新功能開發的重心已經轉向 Cloud Run。如果你的 App Engine 應用運作良好，沒有必要為了「跟上潮流」而遷移。但新專案建議優先考慮 Cloud Run。

Q3：我的專案同時需要 HTTP API 和事件處理，該怎麼架構？

A：推薦的模式是 Cloud Run（HTTP API）+ Cloud Functions（事件處理）。例如：

Cloud Run 服務處理使用者的 REST API 請求
Cloud Functions 監聽 Cloud Storage 事件做檔案處理
Cloud Functions 消費 Pub/Sub 訊息做非同步任務

這樣每個元件都挑到最合適的服務，彼此再用 Pub/Sub 或直接 HTTP 呼叫溝通就好。

Q4：如何從 App Engine 遷移到 Cloud Run？

A：遷移步驟通常是：

為你的 App Engine 應用撰寫 Dockerfile
確認應用監聽 $PORT 環境變數
將 app.yaml 的配置轉換為 Cloud Run 的部署參數
用 gcloud run deploy 部署
如果有用到 App Engine 特有功能（cron.yaml → Cloud Scheduler、Task Queue → Cloud Tasks），需要逐一替換

Google 也提供了官方的 App Engine to Cloud Run 遷移指南。

Q5：Cloud Run 的 60 分鐘超時不夠用怎麼辦？

A：如果你的任務需要超過 60 分鐘：

Cloud Run Jobs：單一任務最長可執行 24 小時
Compute Engine：無超時限制
GKE：無超時限制
拆分任務：將長時間任務拆成多個步驟，用 Cloud Workflows 編排

總結

如果你…	選擇
想要最大彈性和控制權	Cloud Run
需要回應 GCP 事件且邏輯簡單	Cloud Functions (Gen2)
想要最簡單的部署體驗且不懂 Docker	App Engine Standard
需要 WebSocket / gRPC	Cloud Run
需要任意語言 + Serverless	Cloud Run
流量極低想省到極致	Cloud Run 或 Cloud Functions（scale-to-zero）
拿不定主意	Cloud Run（2026 年的安全預設選擇）

記住那句口訣：事件選 Functions，容器選 Cloud Run，快速上線選 App Engine，拿不定主意選 Cloud Run。

開場：Serverless 不是只有一種選擇

三大服務一覽比較表

各服務深入介紹

Cloud Run：容器化 + Serverless 的最佳結合

架構特色

核心優勢

適用場景

不適合的場景

Cloud Functions（Cloud Run functions）：事件驅動的輕量函式

Gen1 vs Gen2（Cloud Run functions）

核心優勢

適用場景

不適合的場景

App Engine：全託管平台（Standard vs Flexible）

Standard vs Flexible 關鍵差異

核心優勢

App Engine 的限制（為什麼很多人轉向 Cloud Run）

適用場景

不適合的場景

六大面向深入比較

面向一：冷啟動與效能

面向二：定價模式

Cloud Run 定價

Cloud Functions 定價

App Engine 定價

不同流量模式的月費估算

面向三：Scale-to-zero

面向四：語言與框架支援

面向五：事件觸發 vs HTTP

面向六：容器化 vs 原始碼部署

選型決策樹

實戰部署範例

Cloud Run：部署一個容器化 Python API

Cloud Functions（Gen2 / Cloud Run functions）：部署事件驅動函式

App Engine Standard：部署一個 Web 應用

2026 年 Google 的策略方向

Cloud Functions → Cloud Run functions 整合趨勢

Cloud Run 的最新功能（2025-2026）

ACE 考試常見選型題

題目 1

題目 2

題目 3

題目 4

題目 5

FAQ

Q1：Cloud Functions Gen2 和 Cloud Run 到底有什麼差別？既然底層都是 Cloud Run？

Q2：App Engine 會被 Google 淘汰嗎？

Q3：我的專案同時需要 HTTP API 和事件處理，該怎麼架構？

Q4：如何從 App Engine 遷移到 Cloud Run？

Q5：Cloud Run 的 60 分鐘超時不夠用怎麼辦？

延伸閱讀

總結

相關文章

Cloud Run vs Cloud Functions vs App Engine：GCP 無伺服器服務怎麼選？

GCP-109：Cloud Run 入門——零運維容器部署完全指南

無伺服器時代：App Engine、Cloud Run 與 GKE 選型策略完全指南

相關學習資源

留言討論