Google Cloud 運算選項

什麼是 Google Cloud 運算選項？

運算（Compute） 是執行應用程式程式碼的引擎。在 Google Cloud 上，「運算」並非單一產品，而是一個服務家族，橫跨從原始虛擬硬體到完全受管事件處理器的整個抽象層次。對於 Cloud Digital Leader（CDL）考試，您必須理解四大主要選項：Compute Engine（IaaS）、Google Kubernetes Engine（GKE）（受管容器）、Cloud Run（無伺服器容器）以及 App Engine / Cloud Functions（PaaS / FaaS）。

選擇正確的運算選項，是企業採用 Google Cloud 時最關鍵的決策之一。錯誤的選擇可能導致營運成本膨脹、版本發布週期緩慢，或工程時間浪費在基礎設施的管線工作上。正確的選擇能讓團隊專注於客戶價值，而非作業系統的日常維護。

CDL 考試不會要求您撰寫 kubectl 指令或挑選特定的機器類型。它考的是商業情境題：「一家零售商需要搬遷舊版 Java 應用程式而不重新撰寫程式碼，哪個運算選項最適合？」或「一家新創公司希望在沒有流量時完全不付費，應該使用什麼？」本章節以具體的 Google Cloud 產品名稱、責任共擔模型與台灣在地化類比，建構這套決策框架。

讀完本章節，您將能把任何商業情境對應到正確的 Google Cloud 運算服務、說明每個抽象層各自由誰負責管理，並清楚闡述從 IaaS 到 FaaS 在成本與營運方面的取捨。

IaaS、CaaS、PaaS、FaaS、SaaS 抽象層次

雲端運算服務位於一條抽象層次的軸線上。愈往「上層」走，Google 為您管理的事情愈多，您需要擔心的事情愈少。理解這條軸線是選擇運算選項最重要的核心概念。

基礎設施即服務（IaaS）

IaaS 提供您虛擬硬體：一台具備 CPU、RAM、磁碟與網路介面的虛擬機（VM）。Google 負責管理實體資料中心、虛擬化層（Hypervisor）以及底層網路。您負責管理 Hypervisor 以上的一切：作業系統、修補程式、執行環境函式庫、中介軟體、應用程式與資料。在 Google Cloud 上，IaaS 產品是 Compute Engine。

容器即服務（CaaS）

CaaS 將作業系統抽象化。您把應用程式打包成容器映像檔（通常為 Docker），Google 在受管的 Kubernetes 叢集上執行該容器。您不再需要修補作業系統核心，但仍需管理容器映像檔、其中的應用程式執行環境以及自動擴展策略。在 Google Cloud 上，這就是 Standard 模式的 Google Kubernetes Engine（GKE）。GKE Autopilot 更進一步，由 Google 代為管理節點。

平台即服務（PaaS）

PaaS 同時將作業系統與容器執行環境抽象化。您只需上傳原始碼，Google 自行決定如何執行——包括選擇執行環境、擴展執行個體，以及處理負載平衡。在 Google Cloud 上，這就是 App Engine（Standard 或 Flexible）以及以無伺服器容器混合形式呈現的 Cloud Run。

函式即服務（FaaS）

FaaS 是抽象程度最高的運算模型。您撰寫一個單一函式（例如：「當某個檔案上傳到這個儲存桶時，就執行縮圖處理」），Google 只在事件觸發時才執行該函式。沒有任何伺服器、容器或執行環境需要管理。在 Google Cloud 上，這就是 Cloud Functions（最新一代亦稱為 Cloud Run functions）。

軟體即服務（SaaS）

SaaS 是層次最高的選項——您完全不需要管理程式碼，直接使用應用程式即可。Google Workspace（Gmail、Docs、Drive）是最典型的 SaaS 範例，雖然它不在 CDL「運算選項」題目的討論範圍內。

白話文解釋

運算層次的概念在盯著控制台截圖時往往顯得抽象。最好的理解方式，是把每個選項對應到台灣人已經熟悉的日常場景。以下三個類比呈現的是同一個核心概念——從「全部自己來」到「只需消費」的漸進過程——但各自著重不同的決策面向。

類比 1 — 買車 vs 租車 vs 計程車 vs Uber

想像您每天都需要在台北市區移動。您有四種選擇。

自己買車（在地部署） 意味著高額的前期費用，您必須自行保養（機油更換、換胎、驗車），即使車子停在車庫裡也照樣要付停車費。這就是傳統資料中心：高資本支出（Capex）、高責任、低彈性。

長期租車（Compute Engine / IaaS） 就像租一年的轎車。您不擁有它，但您仍然自己駕駛、選擇路線、加油，並決定停在哪裡。您可以選租小客車、SUV 或貨車，視任務需求而定——就像在 Compute Engine 上選擇通用型、運算最佳化或記憶體最佳化機器系列一樣。VM 內的作業系統修補與應用程式堆疊，也由您自己負責。

搭計程車（App Engine / PaaS） 就像告訴司機「載我去台北 101」。您不挑車款、不開車、不加油。您只需指定目的地（應用程式程式碼）。司機（App Engine）自行決定用什麼車、走哪條路。按趟付費。

叫 Uber 按分鐘計費（Cloud Run / Cloud Functions） 更是隨需而生。您只有在車上的時間才付費，一到目的地計費就停止——這就是縮減到零（Scale to zero）。如果跨年夜一百萬人同時叫車，系統瞬間派出一百萬輛車。沒人叫車時，看不到任何一輛車，也不花您一分錢。這正是 Cloud Run 處理以 HTTP 請求驅動工作負載的方式。

類比 2 — 自己煮 vs 中央廚房 vs 外送平台 vs 自助餐

您的事業每天需要供應 1,000 位顧客。您要怎麼處理廚房？

自己在店裡開廚房（在地部署） 意味著購買烤箱、聘請廚師、維護排風設備，並應付衛生稽查。所有事情都壓在您身上。

租用中央廚房的設備（Compute Engine） 就像租下工業級烤箱和爐台。廠房與電力由廠方提供，但您仍需自行聘僱廚師、設計菜單，以及決定每天要備多少量。廚師辭職或烤箱故障，您自己處理。

使用標準化中央廚房工作站（GKE / 容器） 是現代連鎖餐飲的模式。每個「工作站」就是一個容器——預先封裝好的水餃線、麵食區、飲料吧。廚房經理（Kubernetes）根據客流量決定開幾個工作站，自動替換故障工作站，並將訂單路由到正確的站台。您不再管理個別的烤箱，管理的單位變成工作站。

使用外送平台按需叫餐（Cloud Run） 意味著您完全不需要廚房。有顧客下單時，外送員就從周邊餐廳取餐。一小時內沒人點餐，您一分錢也不用付。中午一千筆訂單湧入，一千位外送員即刻出動。這就是無狀態、以請求為驅動、縮減到零的無伺服器運算。

固定菜色的自助餐（App Engine Standard） 是精選化的 PaaS 體驗。業者控制菜單（支援的執行環境：Python、Java、Node.js、Go、PHP、Ruby）、工作站與動線。開發者只需帶著餐盤（原始碼）來取餐。速度快，但選擇受限。

類比 3 — 蓋房子 vs 租公寓 vs 住旅館 vs Airbnb

您的應用程式需要一個「家」。

在土地上從零蓋房子（在地部署） 是傳統資料中心。您擁有土地、澆灌混凝土、拉電線、修屋頂，全部自己來。

租公寓（Compute Engine） 是 IaaS。整棟建築（資料中心）由 Google 管理。您取得一間單位（VM），選擇坪數（機器類型，如 e2-medium、n2-standard-4），自己裝潢（安裝作業系統與應用程式），按月付租金。您可以長期住下去，但公寓內的害蟲防治（作業系統修補）要自己處理。

住旅館（App Engine / GKE Autopilot） 是 PaaS 風格。您帶著行李箱（程式碼）入住，旅館提供客房清掃、電力、早餐與保全。您不用擔心水管或電路。按夜付費，不住就不付錢。

訂 Airbnb 按夜計費（Cloud Run / Cloud Functions） 最具彈性。您只付實際入住的晚數，臨時取消不收費。需要一小時的會議室也辦得到。這就是事件驅動、按次執行計費的無伺服器運算。Cloud Functions 更進一步——您不是租整個房間，而是租一個僅用 30 秒的會議包廂。

Compute Engine（IaaS）— 完全自主控制的虛擬機

Compute Engine 是 Google Cloud 的旗艦 IaaS 產品。它在 Google 的全球基礎設施上提供 Linux 與 Windows 虛擬機（VM）。您選擇機器系列、規格大小、磁碟、作業系統映像檔以及網路設定，然後透過 SSH 登入並安裝任何所需軟體。

Compute Engine 的機器系列

Google Cloud 將 Compute Engine VM 依不同工作負載分類為幾大機器系列：

• 通用型（E2、N2、N2D、N4）： 均衡的 CPU 與記憶體，適合網頁伺服器、小型資料庫、開發／測試及大多數日常工作負載。E2 注重成本效益；N4 是最新效能世代。
• 運算最佳化（C2、C3、C4）： 高時脈速度與 CPU 效能，適合遊戲伺服器、高效能運算（HPC）模擬及 CPU 密集型批次作業。
• 記憶體最佳化（M1、M2、M3）： 高記憶體對 CPU 比例，適合 SAP HANA 等記憶體內資料庫、大型 Redis 快取或高效能分析。
• 加速器最佳化（A2、A3、G2）： 附掛 NVIDIA GPU（T4、L4、A100、H100）或 Cloud TPU 的 VM，用於 AI／ML 訓練與推論。
• 儲存最佳化（Z3）： 本地 SSD 密集型節點，適合高 IOPS 工作負載。

搶佔式 VM 與 Spot VM

針對可容錯的批次工作負載，Google 提供 Spot VM（前身稱為 Preemptible VM）。Spot VM 比標準 VM 便宜 60～91%，但 Google 可隨時以 30 秒前通知的方式收回資源。它非常適合影片轉碼、科學運算或大規模批次分析等可設定檢查點並恢復的工作負載。

何時選用 Compute Engine

• 直接搬遷（Lift-and-shift）： 無法容器化的舊版應用程式，需要特定作業系統版本、核心模組或授權軟體。
• GPU 工作負載： AI 訓練、3D 渲染、科學模擬。這類需求幾乎都在 Compute Engine A3／G2 VM 上執行，因為它們需要直接存取 GPU。
• 自訂核心或網路： 需要原始 Socket 存取、自訂路由或特定 Linux 核心模組的應用程式。
• 長期、可預測的工作負載： 使用 承諾使用折扣（CUDs） 簽署 1 年或 3 年合約，節省 20～60%。

Google Kubernetes Engine（GKE）— 容器編排

Google Kubernetes Engine（GKE） 是 Google 的受管 Kubernetes 服務。Kubernetes 本身由 Google 發明（基於內部的「Borg」系統），並捐贈給雲端原生運算基金會（CNCF）。GKE 代您執行 Kubernetes，處理控制平面升級、節點佈建，以及與 Google Cloud 其他服務的整合。

Standard 模式 vs Autopilot 模式

GKE 提供兩種版本：

• GKE Standard： 您管理節點池（執行容器的 VM）。您選擇節點規格、自動擴展規則與版本升級。無論節點忙碌或閒置，您都要付費。
• GKE Autopilot： Google 代您管理節點。您只需指定工作負載（Pod 定義），Google 自行決定背後要佈建什麼 VM。依 Pod 秒數（vCPU 與記憶體）計費——與無伺服器計費模型更為接近。

何時選用 GKE

• 微服務架構： 數十到數百個需要互相通訊的小型服務，需要滾動部署、服務發現與流量管理。
• 多雲或混合雲： Kubernetes 具有可攜性，相同的 Manifest 可在 GKE、透過 GKE Enterprise 的在地環境，或 AWS／Azure 上執行。
• 有強烈編排需求的有狀態工作負載： 具自訂複製機制的資料庫、佇列系統或串流處理器，需要 Kubernetes Operator 提供生命週期自動化管理。
• 現有 Kubernetes 專業知識： 已熟悉 kubectl、Helm 與 Operator 的團隊可立即上手並發揮生產力。

Cloud Run — 無伺服器容器

Cloud Run 以無伺服器服務的方式執行您的容器映像檔。您建置一個 Docker 容器，推送到 Artifact Registry，Cloud Run 處理其餘所有事情：HTTPS 端點、負載平衡、從零自動擴展到數千個執行個體，以及金絲雀版本發布的流量分流。

Cloud Run 的核心特性

• 縮減到零（Scale to zero）： 沒有流量時，執行個體自動縮減到零，您完全不需付費。
• 按請求計費： 只對實際服務請求時使用的 CPU 與記憶體付費，以最近的 100 毫秒為計費單位。
• 預設無狀態： 每個請求彼此獨立；持久狀態應存放於 Cloud SQL、Firestore 或 Cloud Storage。
• 任意語言、任意函式庫： 只要能在 Linux 容器中執行且監聽 $PORT，Cloud Run 就能執行。

Cloud Run Services vs Cloud Run Jobs

• Cloud Run services 處理 HTTP、gRPC 或 WebSocket 請求——典型的網頁應用程式、API 與 Webhook。
• Cloud Run jobs 將批次任務執行至完成（例如：每晚的資料庫匯出）。不需要 HTTP 監聽器。

何時選用 Cloud Run

• 無狀態網頁應用程式與 API： 特別適合流量忽高忽低的模式。
• 內部微服務： 在不需要叢集管理費用的情況下，取代小型的 GKE 部署。
• Webhook 與事件處理器： Pub/Sub 推送訂閱、GitHub Webhook、Stripe 回呼。
• 任何可打包成容器的工作負載： 包括 Python ML 推論、Node.js API 或 Go 二進位檔。

App Engine 與 Cloud Functions — PaaS 與 FaaS

App Engine

App Engine 是 Google Cloud 於 2008 年推出的原創 PaaS。您以支援的語言（Python、Java、Node.js、Go、PHP、Ruby、.NET）上傳原始碼，App Engine 處理其餘所有事情——執行環境、擴展、負載平衡，甚至包括藍綠部署的版本管理與流量分流。

App Engine 提供兩種版本：

• App Engine Standard： 高度標準化的執行環境，擴展速度極快（毫秒級），可縮減到零。最適合使用支援語言開發的典型網頁應用程式。
• App Engine Flexible： 在 Compute Engine VM 上的 Docker 容器中執行您的應用程式。擴展較慢（分鐘級），無法縮減到零，但支援任意語言或自訂相依套件。

Cloud Functions

Cloud Functions（FaaS 服務，現也透過 Cloud Run functions 提供）以事件回應方式執行單一函式。觸發來源包括：

• HTTP 請求
• Pub/Sub 訊息
• Cloud Storage 物件事件（新檔案上傳、檔案刪除）
• Firestore 文件變更
• Cloud Scheduler 排程任務

您撰寫函式、部署，Google 處理其餘一切。函式自動從零擴展到數千個並行執行。

何時選用 App Engine vs Cloud Functions vs Cloud Run

• App Engine Standard： 傳統整合型或小型服務網頁應用程式，希望零營運負擔且不需要自訂容器。
• Cloud Functions： 事件驅動的「黏合程式碼」——上傳時縮圖、資料列插入時發送通知、凌晨 3 點執行定期清理。
• Cloud Run： 需要完整語言彈性、更長請求持續時間（最長 60 分鐘）或更大記憶體的容器化工作負載。

決策框架：如何選擇正確的運算選項

Google 在 https://cloud.google.com/docs/choosing-a-compute-option 發布了官方的**「選擇運算選項」指南**，CDL 考試預期您能推演類似的取捨邏輯。以下是簡化的決策框架：

步驟 1 — 您需要完整的作業系統控制權嗎？

• 是（自訂核心、GPU、舊版二進位檔、授權鎖定軟體）： 選用 Compute Engine。
• 否： 繼續。

步驟 2 — 工作負載是否已容器化？

• 是，且有複雜的編排需求（微服務、StatefulSet）： 選用 GKE（建議使用 Autopilot）。
• 是，且為無狀態 HTTP 服務： 選用 Cloud Run。
• 否，只有原始碼： 繼續。

步驟 3 — 是事件驅動還是請求驅動？

• 事件驅動的單一用途函式： 選用 Cloud Functions。
• 具有多個端點的完整網頁應用程式： 選用 App Engine 或 Cloud Run。

步驟 4 — 您需要縮減到零嗎？

• 是： 選用 Cloud Run、Cloud Functions 或 App Engine Standard。
• 否（工作負載穩定）： 搭配承諾使用折扣的 Compute Engine 是最低成本方案。

各運算選項的自動擴展機制

自動擴展（Autoscaling） 是運算平台根據負載自動增減容量的能力。每個 Google Cloud 運算選項都支援某種形式的自動擴展，但機制各有不同。

• Compute Engine： 受管執行個體群組（MIGs） 根據 CPU 使用率、負載平衡器每秒請求數或自訂指標擴展 VM。擴展時間約 30～90 秒（開機時間）。
• GKE： 水平 Pod 自動擴展器（HPA） 根據 CPU／記憶體或自訂指標擴展 Pod。叢集自動擴展器擴展底層節點。因為容器在幾秒鐘內就能啟動，擴展速度比 Compute Engine 快。
• Cloud Run： 依每個執行個體的並行請求數（預設 80）擴展。擴展在次秒級完成。縮減（包括縮減到零）為漸進式，以避免冷啟動。
• App Engine Standard： 根據請求佇列長度與待處理請求擴展。次秒級擴展。
• Cloud Functions： 依事件逐一擴展。每個事件觸發一次函式執行；並行數量以執行個體為單位，可調整設定。

通則：抽象層次愈高，自動擴展的回應速度愈快，因為需要佈建的基礎設施愈少。

定價與成本最佳化

每個運算選項都有不同的定價模型。理解這些模型對 Google Cloud Architecture Framework 的成本最佳化支柱至關重要。

• Compute Engine： 按秒計費（最低 1 分鐘）。折扣方案：持續使用折扣（SUDs） 對每月使用 ≥ 25% 時間的 VM 自動套用。承諾使用折扣（CUDs） 適用 1 年或 3 年合約。Spot VM 用於可容錯工作負載。
• GKE Standard： 依底層節點（Compute Engine 定價）加上小額叢集管理費計費。
• GKE Autopilot： 依請求的 vCPU、記憶體與暫時性儲存空間的 Pod 秒數計費。無閒置節點費用。
• Cloud Run： 依服務請求期間使用的 CPU 與記憶體計費（也可選擇永遠分配 CPU）。每 100 毫秒計費。
• App Engine Standard： 依執行個體小時計費。免費配額每天包含 28 個前端執行個體小時。
• Cloud Functions： 依呼叫次數 + 運算時間 + 記憶體計費。每月 200 萬次免費呼叫配額。

對於 CDL 考試中「流量不可預測時如何降低浪費」的問題，答案幾乎都是無伺服器選項（Cloud Run、Cloud Functions 或 App Engine Standard），因為它們可縮減到零。對於「可預測的穩態工作負載以最低成本執行」，答案是搭配承諾使用折扣的 Compute Engine。

運算選項與其他 Google Cloud 服務的整合

沒有任何運算選項是孤立存在的。每個選項都與 Google Cloud 更廣泛的生態系統整合：

• 網路： 所有運算選項都可放在 Cloud Load Balancing 與 Cloud CDN 後方，實現全球分散。
• 身分識別： IAM 控制誰可以部署、管理與呼叫運算資源。服務帳號讓工作負載本身也擁有存取其他 Google Cloud 服務所需的身分識別。
• 儲存： Cloud Storage 存放物件，Cloud SQL 存放關聯式資料，Firestore 與 Spanner 用於 NoSQL 與全球一致性資料，BigQuery 用於分析。
• 訊息傳遞： Pub/Sub 處理非同步事件，觸發 Cloud Functions 或 Cloud Run。
• 可觀測性： Cloud Logging 與 Cloud Monitoring 自動擷取每個運算服務的指標與日誌。
• CI/CD： Cloud Build 建置容器映像檔並部署到任何運算目標。Artifact Registry 儲存這些映像檔。

這種整合正是雲端價值主張的體現：選擇 Google Cloud 運算服務的同時，您也獲得了一個完全整合的平台，無需自行串接各個元件。更多詳情請參閱 /en/certs/gcp/cdl/topics/cloud-value-proposition。

遷移路徑：從虛擬機到容器到無伺服器

許多企業遵循一條現代化旅程，橫跨各個運算選項：

1. 直接搬遷至 Compute Engine： 將現有的在地 VM 原封不動地搬遷到 Compute Engine。遷移速度快，程式碼改動極少。工具：Migrate to Virtual Machines（前身為 Migrate for Compute Engine）。
2. 將應用程式容器化： 將應用程式打包成 Docker 容器。在 GKE 上執行以進行容器編排，或在 Cloud Run 上執行以享有無伺服器的簡便性。
3. 分解為微服務： 將整合型應用程式拆分成小型服務，每個服務部署為 Cloud Run 服務或 GKE 工作負載。使用 Pub/Sub 進行非同步通訊。
4. 將黏合程式碼提取至 Cloud Functions： 定期任務、事件處理器與整合功能移至 Cloud Functions，實現零營運負擔的執行。

每個步驟都能降低營運負擔並提升敏捷性，但同時也需要更多的重構工作。CDL 考試中關於「現代化策略」的題目，預期您能識別這個演進過程。有關 VM 到容器轉變的更多背景，請參閱 /en/certs/gcp/cdl/topics/containers-vs-vms。

運算工作負載的成本治理

一個常見的 CDL 考題：「企業如何防止運算成本失控？」Google Cloud 提供幾項治理工具：

• 預算與預算警示：帳單主控台在支出超過門檻時通知財務團隊。
• 配額（Quotas）：限制專案可消耗的最大運算資源量。
• 標籤（Labels）：為 VM、GKE 工作負載與 Cloud Run 服務標記成本中心與環境，用於**回佔（Chargeback）與展示（Showback）**報告。
• Recommender：建議調整規格的機會——使用率不足的 VM 可縮小規格，或閒置的執行個體可刪除。

有關這些工具的深入說明，請參閱 /en/certs/gcp/cdl/topics/cloud-financial-governance。

常見問題

Q：目前還沒有流量的新創公司，應該選哪個 Google Cloud 運算選項？

A： Cloud Run。它可縮減到零，因此在客戶到來之前，帳單基本上為零。它支援任何打包成容器的語言。隨著新創公司成長，Cloud Run 可處理每秒數十萬個請求；當微服務複雜度提升時，相同的容器映像檔可以以最少的工作量遷移至 GKE Autopilot。

Q：我可以在 Cloud Run 上執行 Windows 應用程式嗎？

A： 一般情況下不行——Cloud Run 執行的是 Linux 容器。對於 Windows 工作負載（例如需要 Windows Server 的舊版 .NET Framework 應用程式），請使用附有 Windows Server 映像檔的 Compute Engine。現代的 .NET（Core / 6+） 應用程式可以作為 Linux 容器在 Cloud Run 上正常執行。

Q：GKE Standard 與 GKE Autopilot 有什麼差別？

A： GKE Standard 讓您完全控制節點池——您選擇機器類型、管理自動擴展，並為節點付費，無論忙碌或閒置。GKE Autopilot 則由 Google 代為管理節點，依請求資源的 Pod 秒數計費。Autopilot 是新工作負載的建議預設選擇；Standard 適用於需要精細節點控制的情況（例如自訂核心或特定機器類型）。

Q：App Engine 即將被 Cloud Run 取代而停止支援嗎？

A： 不會。App Engine 仍是完全受支援的 PaaS 選項，許多正式環境應用程式仍在其上執行。然而，Google 的策略方向是將 Cloud Run 作為新無伺服器工作負載的首選，因為它提供更大的彈性（任意容器、任意語言），同時仍可縮減到零。對於偏好純原始碼部署體驗的團隊，App Engine Standard 依然是極具吸引力的選擇。

Q：什麼情況下應該選用 Cloud Functions 而非 Cloud Run？

A： 當工作負載是單一用途、事件驅動的函式時，選用 Cloud Functions——例如「檔案上傳至 Cloud Storage 時執行縮圖處理」或「Pub/Sub 訊息到達時傳送 Slack 通知」。當您有完整的網頁應用程式、多個端點、較長的請求持續時間，或需要精細控制容器映像檔時，選用 Cloud Run。最新一代的 Cloud Functions（Cloud Run functions）實際上運行在 Cloud Run 平台上，兩者的界線已逐漸模糊。

Q：CDL 考試需要懂 Kubernetes 嗎？

A： 技術層面不需要——考試不會要求您撰寫 YAML 或 kubectl 指令。但您應該了解 Kubernetes 的功能（容器編排、自動擴展、服務發現）以及 GKE 何時是正確答案（微服務、多雲可攜性、複雜編排需求）。

總結

Google Cloud 提供橫跨 IaaS、CaaS、PaaS 與 FaaS 的完整運算選項系列：

• Compute Engine（IaaS）： 具備機器系列、GPU 與 Spot 定價的完整自主控制 VM。最適合直接搬遷、GPU 工作負載及作業系統層級的自訂需求。
• GKE（CaaS）： 用於容器化微服務的受管 Kubernetes。Autopilot 模式大幅降低營運負擔。
• Cloud Run（無伺服器容器）： 可縮減到零、支援任意語言與容器的無狀態 HTTP 服務。
• App Engine（PaaS）： 使用受管執行環境進行原始碼部署。Standard 模式可縮減到零。
• Cloud Functions（FaaS）： 依呼叫次數計費的事件驅動函式。

正確的選擇取決於商業優先考量：完整控制 vs 最小化營運、可預測成本 vs 縮減到零、自訂作業系統 vs 受管執行環境。身為 Cloud Digital Leader，您的職責是將每個商業情境對應到正確的服務，並向利害關係人清楚闡述取捨之道。掌握這套框架，您就能有信心回答 CDL 考試中所有與運算相關的題目。