真實案例：一覺醒來帳單暴增 2,500 倍

澳洲開發者的 25,000 澳幣慘劇

澳洲 AI 顧問 Jesse Davies 在 LinkedIn 和 Reddit 分享了他的親身經歷。

他在 Google AI Studio 做了一個小測試專案，用「Deploy to Cloud Run」一鍵部署到雲端，之後就沒再理它。

帳戶預算通知設定是 10 澳幣（約新台幣 210 元）。

某天早上起床，信用卡已經被扣了 10,000 澳幣。

他立刻聯絡 Google 客服。但在等待回覆的過程中，帳戶又被多刷了 15,000 澳幣。

最終帳單是 25,672.86 澳幣，折合約 18,391 美元（新台幣 58 萬左右）。

攻擊者做了什麼？他們根本沒有偷走 API 金鑰。

他們只是找到 Jesse 部署在 Cloud Run 上的公開網址，直接朝這個網址送請求。

Cloud Run 容器裡以明碼形式存放的 API 金鑰，就會幫攻擊者一筆一筆簽好請求，送到 Vertex AI 上去跑。

短短一個晚上，攻擊者送出了超過 60,000 次請求。

最後 Google 同意撤銷這筆費用，但這個過程讓 Jesse 整整驚嚇了好幾天。

原始貼文如下：

Google Cloud 自動升級消費上限的隱藏機制

這個案例裡還有一個關鍵細節，很多人不知道。

Davies 的帳戶原本是 Tier 2，消費上限大約是 2,000 美元。

Google Cloud 的帳單/用量層級可能會依帳戶歷史消費與資格自動提升；在某些案例中，Tier 2 帳戶累積消費達到門檻後，可能被提升到更高層級，對應上限可達 20,000 至 100,000 美元以上。

雖然不是「偷偷加額度」，但確實代表預設風控不足時，帳單風險會被放大 。

注意 Google 的 AI Studio 帳戶建立超過 30 天、且終生消費達 1,000 美元的帳戶，系統可能自動將可用消費額提高至 100,000 美元。這個機制設計初衷是讓正常業務不中斷，但在 GCP 帳單爆炸的情境下，它反而成為放大損失的燃料。

詳情可以查看以下連結：

https://ai.google.dev/gemini-api/docs/rate-limits?hl=zh-tw

後來 Google 就在 AI Studio 加入每月專案支出上限設定，一旦專案的支出超過上限，系統將在約 10 分鐘內暫停該專案的請求。

但也因為這個延遲，在這段期間內仍可能產生超額費用，並且還是由使用者自行負擔。

為什麼 GCP 帳單爆炸這麼容易發生？

GCP 帳單爆炸之所以容易發生，是因為 Google Cloud 的預設設定把 9 項安全機制全部關閉、消費上限設計成可自動升級，而開發者往往在測試後忘記關閉公開服務。三個條件同時成立，帳單爆炸就只差一個攻擊者。

API 金鑰公開在前端的致命風險

API 金鑰（API Key）是一組用來識別呼叫者身份的字串，當它出現在公開的前端程式碼或 URL 中，任何人都能用它以你的身份呼叫付費服務。

Google Maps API 金鑰數年前被設計成允許放在前端使用，因為當時 Maps API 的計費邏輯相對友善。

但後來 Gemini、Veo 等高價模型加入之後，這個設計就變成潛在漏洞：如果同一把 API 金鑰被賦予存取 Gemini 的權限，任何拿到這把金鑰的人都能用它呼叫 Gemini，費用算在你頭上。

資安公司 Truffle Security 在 2026 年 2 月已公開警告這個問題，詳情可以看這篇文章。

Cloud Run 部署後忘記關閉的代價

Cloud Run 是 GCP 的容器化服務執行平台，讓你可以把應用程式打包成容器並部署到雲端對外提供服務，預設為公開可存取。

問題在於：你的服務有一個公開的 HTTPS 網址，任何人都可以發請求給它。如果你的容器裡有 API 金鑰（特別是明碼形式存放的），每一次外部請求都會觸發真實的 API 呼叫，並產生費用。

很多開發者在測試完之後，只是停用服務，沒有完整刪除。

只要網址還在、API 還沒停掉，攻擊者只要找到這個網址，就能開始刷費用。

GCP 預設關閉的 9 項安全機制是什麼

Davies 在事後整理發現，Google Cloud 內建了 9 項安全機制，可以有效阻擋這類攻擊。

但它們全部預設關閉，需要你自己進設定頁面逐一啟用。

這 9 項機制包含：

• API 金鑰的 HTTP referrer 限制
• IP 位址限制
• Cloud Audit Logs 稽核日誌
• Cost Anomaly Detection 成本異常偵測
• Cloud Armor 防護規則
• VPC Service Controls
• Budget Alert 預算警報
• Cloud Run 的身份驗證要求
• IAM 最小權限原則

後面的步驟章節會逐一說明如何啟用其中最關鍵的幾項。

防止 GCP 帳單爆炸：Step 1 保護你的 API 金鑰

API 金鑰是整個問題的核心。把它保護好，GCP 帳單爆炸的機率就降低 80% 以上。

不要把 API 金鑰以明碼形式放進環境變數

明碼環境變數（Plaintext Environment Variable）是指直接把 API 金鑰字串寫進容器設定或程式碼的做法，這樣做會讓任何能存取容器的人直接讀到金鑰值，是造成 GCP 帳單爆炸最常見的根本原因之一。

這樣做有 2 個根本問題：

1. 任何能存取容器的人（包含攻擊者）都能直接讀到金鑰值
2. 金鑰跟著容器映像一起存在，就算你之後想換金鑰，舊的映像版本裡還是有原本的金鑰

正確的做法是改用 GCP Secret Manager 或短期憑證來取代長期金鑰。

使用 GCP Secret Manager 管理敏感憑證

GCP Secret Manager 是 Google Cloud 提供的機密管理服務，讓你可以把 API 金鑰、密碼、憑證等敏感資料集中存放，並透過 IAM 權限控制誰可以讀取。

Secret Manager 的基本設定步驟

1. 在 GCP Console 搜尋「Secret Manager」，進入服務頁面
2. 點擊「建立密鑰」（Create Secret），輸入名稱（例如 gemini-api-key）
3. 在「密鑰值」欄位貼上你的 API 金鑰，點擊「建立密鑰版本」
4. 進入 IAM 頁面，只賦予你的 Cloud Run 服務帳號「Secret Manager Secret Accessor」這個角色
5. 在 Cloud Run 的程式碼中，改用 Secret Manager SDK 動態讀取金鑰，而不是從環境變數讀取

設定完成後，你的 API 金鑰不再存放於容器內部。就算攻擊者拿到容器映像，也讀不到金鑰內容。

搭配服務帳號短期 Token 取代長期金鑰

更進一步的做法是完全不使用 API 金鑰，改用服務帳號（Service Account）搭配短期 Token（OAuth 2.0 access token，一種有時效限制的身份驗證憑證）。

短期 Token 的有效期間最長為 3,600 秒（1 小時），到期後自動失效。

就算被攻擊者截取，也只有在有效期間內能被使用，損失窗口遠比長期 API 金鑰小得多。

設定方式：讓你的 Cloud Run 服務以特定服務帳號身份運行，並透過 Workload Identity 機制自動取得短期 Token，不需要手動管理任何長期憑證。

防止 GCP 帳單爆炸：Step 2 關閉或刪除閒置服務

就算你的 API 金鑰保護做得再好，只要有一個公開的服務端點還在運行，就是潛在的攻擊入口。

如何找出帳號內所有公開的 Cloud Run 服務

1. 進入 GCP Console，在左側選單點擊「Cloud Run」
2. 選擇你要檢查的專案，查看所有已部署的服務列表
3. 對每個服務點擊進入，查看「觸發條件」（Triggers）和「安全性」（Security）分頁
4. 確認「需要驗證」（Require authentication）是否已勾選，未勾選代表該服務完全公開
5. 如果你不確定這個服務還有沒有在用，查看「指標」（Metrics）分頁，若過去 30 天請求數為 0，直接刪除

建議每季做一次這個檢查，把所有不再使用的服務清掉。

這些服務沒在使用時，沒有機器也沒有費用產生，但設定和網址仍然保留，你點擊一下網址它們就恢復運行。

除非你直接刪除，要不然隨時都會有被啟動的風險。

如果你擔心刪除後需要回復，可以先把部署設定（Cloud Run YAML 或 Terraform 設定）存到版本控制系統，之後需要時重新部署即可。

App Engine 和 Cloud Functions 的相同風險

Cloud Run 不是唯一有這個問題的服務。App Engine 和 Cloud Functions 也有相同的風險：

1. App Engine 的版本（Version）在停用後，對應的 URL 在某些情況下仍然可存取
2. Cloud Functions 的 HTTP 觸發函式預設也是公開的
3. 這 2 個服務都需要同樣的定期清查動作

原則一樣：凡是超過 90 天沒有收到任何請求的服務，就直接刪除，不要只是停用。

防止 GCP 帳單爆炸：Step 3 設定消費上限與預算警報

API 金鑰保護和服務管理是預防攻擊，預算設定是當攻擊發生時的最後一道防線。

在 Google Cloud Console 建立預算通知

預算通知（Budget Alert）是 GCP 提供的消費警報機制，當你的消費達到設定門檻時，會發送 Email 通知。

設定步驟：

1. 進入 GCP Console，點擊左側選單的「帳單」（Billing）
2. 選擇「預算與快訊」（Budgets & alerts）
3. 點擊「建立預算」（Create budget）
4. 設定預算名稱和涵蓋範圍（可以只針對特定專案）
5. 設定預算金額（例如新台幣 500 元）
6. 在「快訊門檻」至少設定 50%、75%、100% 三個通知點
7. 在「通知方式」填入你的 Email，或設定 Pub/Sub 主題以觸發自動化動作

PS. 你也可以像我這麼極端，我的通知門檻是「每多 1 USD 就直接通知 1 次」，雖然常看到通知信很煩，但能確保時時都能收到通知。

重要提醒：預算通知不會自動停止計費，它只發送通知。要真正截斷消費，你需要額外設定自動化動作（見下方步驟）。

了解 GCP 自動升級帳戶等級的觸發條件

這是 Davies 案例中讓損失放大 50 倍的關鍵機制，你一定要了解。

1,000 美元門檻與 100,000 美元上限的來龍去脈

根據 Google 官方說明，GCP 帳戶有信用額度分層機制：

1. 新帳戶（建立未滿 30 天）：消費上限約在 2,000 美元
2. 舊帳戶（建立超過 30 天）且終生消費達 1,000 美元：系統可能自動將上限提高至 20,000 至 100,000 美元
3. 這個升級動作完全自動，不需要使用者確認，也不一定會發送通知

換句話說，你在不知情的狀況下，帳戶的實際可消費金額已經是你預期的 50 倍。

如何手動鎖定帳戶消費上限

GCP 目前沒有提供「硬性消費上限」功能（Hard Cap），只能透過以下 3 種方式控制：

1. 透過預算快訊 + Cloud Pub/Sub + Cloud Functions 建立自動化截斷機制：當消費達到設定金額時，自動停用指定的 API 或服務 (要注意這個自動停用的 Cloud Functions 程式，還是要自己寫)
2. 在個別 API 的 Google Cloud Console 設定中查看「配額」（Quota），把每日請求數限制在可接受的範圍
3. 聯絡 Google Cloud 支援，要求在帳戶層級設定更嚴格的消費限制

這是目前最接近「硬性上限」的做法。需要一點工程工作，但一次設好就能長期保護你。

2026 4 月開始，AI Studio 可以設定上限

請先到 Google AI Studio Dashboard 選單的 Spend，再點擊 Set spend cap

設定 Gemini API 的每月花費上限

防止 GCP 帳單爆炸：Step 4 啟用 GCP 內建的安全機制

GCP 內建了 9 項安全機制，但全部預設關閉。這一節帶你把最關鍵的 3 項打開。

9 項預設關閉的安全設定在哪裡找

這 9 項設定散落在 GCP Console 的不同位置，沒有統一入口。你需要逐一進入各個服務的設定頁面手動啟用。

最快的方法是使用 GCP 的「安全性指揮中心」（Security Command Center，一個集中管理 GCP 安全問題的控制台）。

進入 GCP Console，搜尋「Security Command Center」，點擊「漏洞」（Vulnerabilities）分頁。

這裡會列出你帳號中偵測到的安全問題，包含沒有啟用身份驗證的 Cloud Run 服務、過於寬鬆的 IAM 權限等。

Security Command Center 的詳情可以查看這篇文章。

API 金鑰限制：綁定 HTTP referrer 與 IP 位址

如果你的 API 金鑰無法立刻換成 Secret Manager，至少要做這件事：限制 API 金鑰的使用範圍。

設定步驟：

1. 進入 GCP Console，搜尋「API 和服務」（APIs & Services）
2. 點擊「憑證」（Credentials）
3. 找到你要保護的 API 金鑰，點擊進入編輯
4. 在「應用程式限制」（Application restrictions）選擇「HTTP referrer（網站）」，填入你的網域（例如 https://yourdomain.com/*）
5. 在「API 限制」（API restrictions）選擇「限制金鑰」，只勾選這把金鑰真正需要使用的 API
6. 點擊「儲存」

完成後，就算有人拿到你的 API 金鑰字串，在非你網域的環境下使用它，GCP 會直接拒絕這個請求。

設定只能呼叫哪些 API

啟用 Cloud Audit Logs 追蹤異常呼叫

Cloud Audit Logs（雲端稽核日誌）是 GCP 記錄所有 API 呼叫行為的機制，讓你在事後追查「誰在什麼時間呼叫了什麼 API」。

預設只有管理活動日誌（Admin Activity Logs）是開啟的。

資料存取日誌（Data Access Logs）預設關閉，但這才是追蹤異常 API 呼叫最重要的日誌。

啟用方式：

1. 進入 GCP Console，搜尋「IAM 與管理員」（IAM & Admin）
2. 點擊「稽核日誌」（Audit Logs）
3. 找到你要啟用的服務（例如 AI Platform、Cloud Run），勾選「資料讀取」和「資料寫入」
4. 點擊「儲存」

啟用之後，你就能在 Cloud Logging 中查詢：過去 24 小時內，所有 Gemini API 的呼叫次數、來源 IP、使用的金鑰。在異常發生時，你有完整的事後追查能力，也能把日誌資料提供給 Google 客服作為退款申請的佐證。

防止 GCP 帳單爆炸：Step 5 建立異常偵測與即時告警

前面 4 個步驟都是預防，這個步驟是監控——讓你在帳單失控的前 30 分鐘就收到通知，而不是睡一覺起來才發現。

Cost Anomaly Detection 的設定方式

Cost Anomaly Detection（成本異常偵測）是 GCP 的自動化機制，會分析你的歷史消費模式，當消費突然偏離預期時，發送警報 Email。

啟用方式：

1. 進入 GCP Console，點擊「帳單」（Billing）
2. 選擇「異常狀況」（Cost anomalies）分頁
3. 點擊「管理異常狀況」，設定要自動產生門檻，或手動自己設定
4. 在「通知設定」填入你想接收警報的 Email 地址

但要記住 AWS 那個案例的教訓：Cost Anomaly Detection 只涵蓋直接計費的服務。如果你透過 Marketplace 或第三方管道計費，這個偵測在那些項目上無效。記得確認你所有 GCP 服務的計費路徑。

為什麼光靠預算通知還不夠

預算通知有 2 個根本限制：

1. Email 通知有延遲，GCP 帳單的計算週期不是即時的，有時候通知寄到的時候，費用早就超標了
2. 預算通知只有在你的帳戶達到設定門檻時才發送，如果攻擊在短短幾小時內讓費用從 0 衝到 5,000 美元，中間你不會收到任何通知

這就是為什麼需要加上 Cloud Monitoring 的即時 Alerting Policy。

結合 Cloud Monitoring 設定即時 Alerting Policy

Cloud Monitoring（雲端監控）是 GCP 的指標監控服務，可以讓你針對任何 GCP 指標設定即時警報。

設定步驟：

1. 進入 GCP Console，搜尋「Monitoring」，進入 Cloud Monitoring
2. 點擊「警報」（Alerting），再點擊「建立政策」（Create Policy）
3. 在「選取指標」中，搜尋 serviceruntime.googleapis.com/api/request_count（API 請求次數）
4. 設定觸發條件：例如「過去 10 分鐘內，Gemini API 的請求次數超過 1,000 次」
5. 在「通知管道」設定你的 Email 或 Slack 通知
6. 點擊「儲存」

完成後，當有人在 10 分鐘內對你的 API 發出超過 1,000 次請求，你的手機就會立刻收到警報，而不是隔天早上才看到帳單。

常見問題：帳單已經爆了，現在怎麼辦？

如果你看到這篇文章時，帳單已經在爆炸了，這個章節是給你的。動作越快，損失越小。

立刻停用金鑰和服務的操作順序

按照這個順序執行：

1. 進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有 API 金鑰，點擊刪除或停用
2. 進入「Cloud Run」，找到所有公開服務，點擊「刪除」
3. 進入「IAM 與管理員」，找到異常的服務帳號，點擊「停用」
4. 進入「帳單」，查看「本月消費明細」，確認是哪個服務在產生費用
5. 直接停用該服務對應的 API（進入「API 和服務」→「已啟用的 API 和服務」，找到對應的 API，點擊停用）

整個流程在 10 分鐘內應該可以完成。每晚一分鐘，就多幾美元的損失。

如何向 Google Cloud 申請帳單減免

Davies 的案例最後有退款，但這不是自動的，需要你主動申請。

申請步驟：

1. 進入 GCP Console，點擊右上角的「支援」（Support）圖示 （要注意你有購買 Google 官方的技術支援方案）
2. 選擇「建立案例」（Create case）
3. 在問題類型選擇「帳單」（Billing）
4. 詳細描述事件：攻擊發生的時間、你發現的方式、你已採取的緊急措施
5. 附上 Cloud Audit Logs 的截圖或匯出資料，作為攻擊行為的佐證
6. 明確要求「費用撤銷」（Credit request 或 Billing adjustment）

Google 不保證一定退款。但根據公開案例，在能提供明確攻擊證據、且帳號本身沒有不當行為的情況下，退款機率相當高。

隱藏密技，從這裡點選就不需要先購買技術支援方案。

被扣款後帳號被鎖定，怎麼取回日誌權限

這是 Davies 案例中最令人抓狂的環節：因為帳單欠款，GCP 帳號被限制，他一度無法進入 Cloud Logging 查看攻擊日誌。

如果你遇到這個狀況：

1. 先嘗試透過 Google Cloud Console 的帳單頁面補繳欠款，部分情況下補繳後帳號限制會立刻解除
2. 如果無法補繳（例如信用卡已被鎖定），直接聯絡 Google Cloud 支援，說明你正在收集攻擊佐證，需要暫時恢復日誌存取權限
3. 要求 Google 客服協助匯出你帳號的 Audit Logs，這是他們技術上可以做到的事
4. 同步提出費用撤銷申請，兩件事可以一起處理

結語：GCP 帳單爆炸不是你的錯，但防護是你的責任

GCP 的預設設定就是把 9 項安全機制全部關掉，把消費上限設計成會自動升級。這確實是平台設計的問題。

但等 Google 改好設計，可能要等很久。

防止 GCP 帳單爆炸，你能做的就是這 5 件事：保護 API 金鑰、刪除閒置服務、設定預算上限、啟用安全機制、建立即時監控。每一步都花不到一小時。但少做任何一步，都有機會讓你睡一覺起來帳單多出台幣 58 萬。

現在就去 GCP Console 打開那 9 項設定吧。

常見問題（FAQ）

Q1：GCP 預算通知設定後，消費真的會被自動停止嗎？ A：GCP 帳單爆炸最常見的誤解就是這個——預算通知只發 Email，不會自動停止計費。要實現自動截斷，需要額外設定 Cloud Pub/Sub 加上 Cloud Functions，讓警報觸發自動停用服務的程式。這個架構需要一點工程工作，但做一次就能保護所有專案。

Q2：我只是用 GCP 跑實驗，金額很小，需要這麼麻煩嗎？ A：需要。Davies 的案例就是從「只是跑個實驗」開始的。攻擊者不管你的帳戶是否在活躍使用，只要 Cloud Run 網址存在、API 金鑰有效，就是攻擊目標。實驗完成後，刪除服務是最小成本的防護動作，花不到 2 分鐘。

Q3：Secret Manager 收費嗎？費用大概是多少？ A：收費，但金額很小。根據 GCP 官方定價，Secret Manager 每 10,000 次存取操作收費 0.03 美元，每個活躍密鑰版本每月收費 0.06 美元。對大多數開發者來說，每月費用會在 1 美元以下，比起 GCP 帳單爆炸的風險，這筆錢完全值得。

Q4：我有多個 GCP 專案，每個都要做一遍嗎？ A：金鑰保護和服務清查需要在每個專案個別執行。但預算設定可以在帳單帳戶（Billing Account）層級設定，一次涵蓋所有專案。Cost Anomaly Detection 也可以在帳單帳戶層級啟用，不需要逐一設定。

Q5：如果我用的是 Firebase，也有同樣的風險嗎？ A：有。Firebase 專案底層就是 GCP 專案，Firebase 的 API 金鑰同樣可以用來呼叫 GCP 的付費服務。如果你在 Firebase 專案中啟用了 Gemini API 或其他付費服務，一樣需要做 API 金鑰的限制設定。

Q6：Cloud Armor 是什麼？它能防止帳單爆炸嗎？ A：Cloud Armor 是 GCP 的 Web Application Firewall（Web 應用程式防火牆），可以封鎖特定 IP、地區或請求模式。它能減少惡意請求的數量，但不能直接限制消費金額。建議把 Cloud Armor 當作補充防護，而不是主要防線，且它需要額外費用，適合已有穩定流量的正式服務。

Q7：Google Maps API 金鑰和 Gemini API 金鑰是同一把嗎？ A：在 GCP Console 裡，同一個專案的 API 金鑰預設可以存取該專案啟用的所有 API。如果你在同一個專案裡同時啟用了 Maps API 和 Gemini API，你的 Maps API 金鑰在技術上也能呼叫 Gemini。正確做法是在 API 金鑰設定中明確指定這把金鑰只能用於哪些 API。

Q8：我已經把 API 金鑰換掉了，舊金鑰還需要特別處理嗎？ A：需要立刻刪除舊金鑰。進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有舊的 API 金鑰，點擊「刪除」而不是只是停用。停用的金鑰在特定條件下可能被重新啟用；刪除才能確保舊金鑰永久失效，是防止 GCP 帳單爆炸的必要步驟。

Q9：攻擊者是怎麼找到我的 Cloud Run 網址的？ A：常見的途徑有 3 種：在 GitHub、GitLab 或 Bitbucket 的公開 repo 中搜尋 Cloud Run 網址（攻擊者有自動化工具掃描這些平台）；透過搜尋引擎索引到公開的 API 文件或設定檔；從 Google AI Studio 的部署紀錄或相關社群貼文中找到。任何 Cloud Run 網址都不要出現在公開的程式碼或文件裡。

Q10：除了 GCP，其他雲端服務（AWS、Azure）也有同樣的問題嗎？ A：有，而且 AWS 還有額外的盲點。透過 AWS Marketplace 計費的 Bedrock 服務不在 AWS Cost Anomaly Detection 的偵測範圍內。Azure 的 API Management 服務有類似的公開端點風險。每個雲端平台的預設安全設定都不夠嚴格，原則相同：任何公開端點加上任何付費 API 的組合，都需要額外的保護機制。

The post GCP 帳單爆炸防護指南：5 個步驟讓你不再睡醒崩潰 first appeared on 東東 GCP 教學 - GCP 實戰講師.

【新書上巿】《Google Cloud 從雲端小白到黑帶高手》正式發表 ！

書籍簡介

經過一年的努力撰寫，我把 10 年 GCP 實戰經驗精華寫進這本書裡…

本書專門針對想自學 GCP 的朋友，提供「完全從零開始」的手把手教學，即使你完全不懂 GCP，只要跟著本書實作，一樣能夠架設 GCP 雲端服務。

讓你讀完本書，會發現原來自己也懂了 GCP。

本書特色

・從零開始：連註冊帳號、申請試用都教你，完全不怕沒基礎
・手把手實作：每個步驟都有詳細截圖和說明，跟著做就對了
・大白話解釋：把艱澀的技術名詞變成生活化比喻
・核心服務實戰：虛擬機器、自動擴充、負載平衡⋯通通實作給你看
・進階服務導覽：大數據 BigQuery、機器學習、生成式 AI、GKE⋯讓你掌握完整生態系
・帳單管理：使用雲端最怕不小心花太多錢，教你保護你的荷包
・雲端架構師簡介：工作角色與職責、職涯發展建議和轉職攻略
・雲端架構師考證指南：提供學習資源與準備方式，讓你能靠自學並考取證照
・企業上雲指南：教你幫助公司，踏出上雲的第一步

最後，如果想自行購買支持：

實體書

天瓏電腦書局 78 折 (可直接預購, 不用加入會員)
https://www.tenlong.com.tw/products/9786264142984

博客來 79 折
https://www.books.com.tw/products/0011031431

Momo 79 折
https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=14401840

誠品 88 折
https://www.eslite.com/product/10072302132683040876002

PCHome 24H 購物 79 折
https://24h.pchome.com.tw/books/prod/DJAA2V-A900JCTT4

墊腳石 9 折
https://www.tcsb.com.tw/SalePage/Index/11102660?lang=zh-TW

電子書

博客來
https://www.books.com.tw/products/E050300444

Momo
https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=14670384

PCHome
https://24h.pchome.com.tw/books/prod/DJBQ2S-D900JG07Q

讀墨 Readmoo
https://readmoo.com/book/210428103000101

Pubu
https://www.pubu.com.tw/ebook/628771

Kobo
https://www.kobo.com/tw/zh/ebook/google-cloud-1

目錄

第一章 | 認識雲端與 Google Cloud
1-1 雲端運算是什麼？為什麼要使用雲端？
1-2 Google Cloud 是什麼？核心服務與優勢介紹
1-3 Google Cloud 的發展

第二章 | 雲端架構師的角色與職責
2-1 什麼是雲端架構師？
2-2 雲端架構師的日常工作
2-3 成功雲端架構師的關鍵能力

第三章 | 啟用你的 Google Cloud 環境
3-1 使用 Google Cloud 的帳號準備
3-2 申請 Google Cloud 300 美元試用環境
3-3 Google Cloud 的初始畫面介紹
3-4 Google Cloud 的帳單和預算設定
3-5 Google Cloud 的資源層級結構
3-6 Google Cloud 權限與角色管理工具 Cloud IAM
3-7 免費的雲端測試機 Cloud Shell
3-8 在地端操作 Google Cloud 的 Cloud SDK

第四章 | Compute Engine 虛擬機器平台簡介
4-1 Compute Engine 是什麼？
4-2 建立並連線到虛擬機器
4-3 在虛擬機器上架設一個 Apache 網站
4-4 給虛擬機器建立快照備份並還原
4-5 映像檔和機器映像檔
4-6 執行個體範本

第五章 | Google Cloud 的維運和監控
5-1 使用 Cloud Monitoring 監控虛擬機器的效能
5-2 設定監控警告通知
5-3 使用 Cloud Logging 查詢虛擬機器的記錄

第六章 | Google Cloud 的網路基礎知識
6-1 Vitual Private Cloud（VPC）和 Subnet 介紹
6-2 防火牆規則
6-3 安全連線到虛擬機器的三種方法（SSH Key、gcloud、Cloud IAP）

第七章 | Google Cloud 的儲存服務
7-1 雲端檔案儲存 Google Cloud Storage 介紹與基本操作
7-2 雲端資料庫 Cloud SQL 介紹與基本操作
7-3 其他資料儲存服務簡介

第八章 | 打造高可用與自動擴展的雲端架構
8-1 建立自動擴充的執行個體群組
8-2 建立負載平衡器並啟用 Cloud CDN
8-3 網路攻擊防禦 Cloud Armor
8-4 其他網路服務介紹

第九章 | 無伺服器平台與 CI/CD 服務
9-1 上傳程式碼就能跑——Google App Engine 和 Cloud Run Function
9-2 容器相關服務 Artifact Registry、 Cloud Run 和 GKE
9-3 CI/CD工具 Cloud Build

第十章 | 大數據、機器學習和 AI
10-1 大數據工具介紹
10-2 機器學習服務
10-3 生成式 AI 服務

第十一章 | Google Cloud 的資安服務
11-1 Google Cloud 的重要資安概念
11-2 組織治理與監控
11-3 資料保護與加密

第十二章 | 企業使用 Google Cloud 的相關議題
12-1 將系統搬上 Google Cloud 的評估考量
12-2 主機搬遷上雲的執行方法
12-3 Google Cloud 的帳單分析與成本管控

第十三章 | Google Cloud 認證之路
13-1 Google Cloud 認證考試介紹
13-2 準備 Google Cloud 認證考試的策略

第十四章 | 雲端架構師的職涯規劃與發展
14-1 IT 人員到 Google Cloud 架構師的轉型之路
14-2 雲端架構師轉職與面試技巧
14-3 Google Cloud 的細分職業路線
14-4 產業趨勢與架構師角色演進

附錄 A：相關參考資源——Google Cloud 重要參考資源列表

讀者好評

The post 新書上巿 Google Cloud 從雲端小白到黑帶高手 正式發表 first appeared on 東東 GCP 教學 - GCP 實戰講師.

近年來，企業使用雲端已是趨勢，

你常常會聽到某知名公司採用雲端之後，

加強了效率，或是提昇業績等等，好像上雲之後就更成功了。

但是那些內容，到底是真是假？能否相信？

其實到底要不要上雲，問你自己，不要看別人上，你就跟著上。

為此，本文以 GCP 為上雲標的，

給你10個充份的上雲理由、15個評估面向與6大好處，

讓你可以跟老闆報告下定決心。

一、企業上雲的十大理由

1.節省成本 – 單筆大額採購轉成按需付費 

雲端是每月依使用量計費，每月付款，

企業可以從一次性大額採購的「資本支出」，

轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機是放在機房，

因此也要考慮機房、水電的建置和維護成本。

還有一種看不見的成本，就是人力，

主機買來需要插上電源、連上網路、安裝作業系統，各種維護工作，

以及人員是否有足夠能力和意願維護各項基礎建設，

還有離職的風險，其成本可能更難以估算。

相對於不可控的維護人員，直接採用雲端就是比較省事的做法。

2.擴展性 – 根據業務需求隨時調整用量

例如在離峰時間，可保持 1~2 台機器維持服務的基本運作要求，

而尖峰時間，可以彈性增加機器數量來因應使用者需求。

而傳統地端環境無法即時擴充，缺機器的時候，

往往要走採購流程包含詢價、議價、選商，以及後結續的安裝建置，

和雲端相比之下，早就喪失了先機，

這是地端環境遠遠比不上雲端的一大因素。

3.自動化 – 串接各項服務完成工作

當你把系統各項元件，都部署在同一個 GCP 環境之後，

不同服務之間的串接，就變得非常方便。

尤其是自動化流程的設定，

除了最基本的 CI/CD 流程，可以觸發 Cloud Build 幫你測試程式、

建立容器映像檔和部署到 Cloud Run 或 GKE 之外，

還可以透過 Cloud Schduler 定期呼叫 Cloud Function，

來執行各項排程工作，例如自動開關機、擴展或縮減機器、

備份資料、生成報表、檢查閒置資源、

發送各種提醒、更新系統、資料處理等等，

你不再需要第三方工具，整合方便，

也不會因為某一台 Linux 主機異常，

導致內建的 Cronjob 無法執行。

4.業務持續性 – 內建備份備援輕易維持運作

地端系統的備份和備援，如果不仰賴第三方工具，

全部都由自己查資料、自己設定的話，通常耗時耗力。

一旦環境有任何變動，就必須隨之調整，以免備份或備援機制失效。

而在 GCP 上，主機和資料庫的自動備份只需簡單的滑鼠點擊，

萬一主機有問題，可以使用區域性永久磁碟，

讓重建的主機擁有最新的資料，

資料庫也可一鍵啟用高可用性 (High Availability)，

不管發生任何問題，備援的資料庫會自動頂替主要資料庫，

持續對外服務，不用人力介入修改連線資訊，非常方便。

5.攻擊防禦 – 各種防禦規則過濾流量

傳統地端環境總是必須購買資安設備，

並且依公司加以設定，才能防禦外部攻擊或入侵。

而在 GCP 上，即使你只有啟用負載平衡器，

就已經內建 DDoS 攻擊的機制，

如果想要再強化防禦，可再加上 Cloud Armor，

從 Layer 3、Layer 4 到 Layer 7 都可以設定規則，

過濾網路流量，保護後端主機。

尤其是 Cloud Armor 依使用量計費，不需一次性支出大筆金額購買。

6.遠端存取 – 任何地點都能安全連線

主機在雲端上，使用者勢必連上 Internet 才能連線，

而主機的外部 IP 曝露在外，也可能引來駭客入侵，

但 GCP 已經發展出各種連線方案，

方便使用者不論在何處，都能進行安全的連線。

除了使用 SSH Key 搭配防火牆限定來源 IP 的連線方式，

也能使用 OS Login 或是 Cloud IAP 來強制身份驗證，

代表你不是有 Key 就可以連線，你必須經過身份驗證才能連進主機，

甚至主機不需要外部 IP，完全阻絕駭客入侵的可能。

相較於 VPN 只能依照流量來源來決定放行，

GCP 的身份驗證機制嚴格且安全的多。

7.先進技術 – 輕易導入大數據分析與 AI

如果你的公司還沒有投入心力做資料分析、機器學習或人工智慧，

你要知道在 GCP 上做到根本太方便，

只要有 CSV、JSON 格式，可直接匯入 BigQuery，

用你本來就懂的 SQL 語法就能馬上分析資料，

並且透過免費的 Looker Studio 將分析結果做成圖表。

而傳統上需要有專家才能做到的機器學習或人工智慧，

Google 已經有現成的模型可以直接呼叫，

如果要客製化的模型，也不需要你懂演算法，

只要提供整理好的資料，就可以訓練你想要的模型，

並且直接部署上線，提供服務給用戶。

在生成式 AI 上，也有 Vertex AI Studio，

不管是生成文字、語音或圖片，

都已經準備好各種模型，

你可以直接調整參數來優化你想生成的內容。

8.環境友善 – 自動產生合規的碳足跡報告

當大家還在煩惱如何執行碳足跡的報告時，

GCP 早已整理好符合 GHGP 的減碳成果，

並且以報告直接呈現，你也可以再匯入 BigQuery，

依照公司需求，製作客製化的報告。

9.專注核心業務 – 將IT基礎設施外包給專業供應商

你不用再支出水電費、機房維護費，不用花時間採購機器。

你也不用再維護實體機了，不用再跑機房接網路線、買最新的乖乖，

機器有問題或設定錯誤，就直接刪除重建，隨時換新機器。

沒有什麼不能重新再來的，不用背負任何包袱或技術債。

10.合規性 – 雲端服務提供商遵循各種法規標準

Google 非常積極地向各大國際組織申請認證，

在台灣也遵守「FSC 銀行外包法規」和「FSC 保險外包行政規則」，

針對「個人資料保護法」，Google 也提供 Google Cloud 白皮書，

協助客戶建立完善的隱私權與安全性的保護機制。

以上希望可以給你充分的上雲理由。

二、企業上雲的15個評估面向

當你們公司決定要上雲了，總是要具體檢視公司現況，

確認是否可以上雲，以及上雲後是否能真正發揮效益。

這裡給你15個具體評估面向，幫助你完成一份強而有力的評估報告。

1.預估雲端成本是否低於地端IT成本

除了「地端一次性採購」 VS  「雲端每月支出」的比較，

你還要考慮攤提的年限，你用5年來比，可能雲端比較便宜，

你改成10年，就變地端便宜。

而且每批設備的採購都在不同時間點，

除了伺服器、防火牆、路由器，

還要計算機櫃、交換機、UPS、冷卻、監控系統等等，

計費方式不同，攤提年限不同，非常複雜，

這部分要動手腳很容易，務必謹慎計算。

此外，往年地端的支出是否都符合預算，

還是每年都有規劃之外的支出，

例如本來今年預算是200萬，

結果發生了資安事件造成資料外洩，

賠償150萬，導入資安工具再花120萬。

預估金額的準確性也會影響到成本的評估。

2.成本掌控程度提昇

如前段所提，地端設備成本計算複雜，

而採用雲端之後，是否能快速列出主機清單，

公司使用多少機器一目了然，

GCP 能針對使用率低的機器或閒置資源，

主動提供降規建議，幫你省錢。

在帳單方面，GCP 有分門別類的帳單明細報表，

還可以依專案、依服務設定不同的帳單警示，

這些都可以確認成本掌控度是否有效提昇。

3.是否能發揮長期策略效益

這部分可以分成「導入新系統」和「推出新產品」兩個面向，

在「導入新系統」部分，

例如公司平常儲存大量的資料，

但都沒使用機器學習或生成式 AI，

未來是否有機會立即採用 GCP 的相關服務，

訓練自己想要的模型，預測關鍵的訊息。

而在「推出新產品」部分，

代表上雲是否可以快速找到合適的資源，

例如品牌公司能否快速架設產品或活動頁面，

媒體公司能否快速上傳和發布內容，

遊戲公司能否部署大量機器供玩家連線使用。

和原始地端環境相比，是否更夠靈活地反應巿場。

4.敏感資料是否能有效控管

原本資料存在地端，只要不對外開放，

至少可以阻隔資料外洩的風險，

但如今上雲，雲端是否能夠建立各種安全機制，

防止駭客入侵，或內部人員堅守自盜？

這一點反而需要請雲端專業人員加以評估。

5.上雲後是否依然合規

你可能會害怕，目前在地端的系統都是合規，結果上雲之後反而不合規。

因此 Google 對於台灣的個資法有提供白皮書，

可以給企業在 GCP 上處理資料時做為指引；

另外金管會對於銀行、保險業者製訂了「銀行外包規定」和「保險外包行政規則」，

Google 也針對 GCP 在銀行業和保險業的規範製作對照表，

都可以幫助你評估是否能夠滿足法規要求。

6.是否能順利移植應用程式

許多經營數十年的企業，內部累積了各式各樣的舊系統和技術債，

(技術債：軟體開發為了便宜行事，短期方便但造成長期負擔的設定)

導致系統的移植變得非常困難。

再加上人員的流動，通常新人無法理解前人的程式碼，

對其就是「只要可以跑，就不要動它」的心態，

除非公司有足夠的開發能量，直接將系統「重寫」，

才能直接採用新的架構部署上雲。

另一個考量點是向外部購買的授權系統，

例如 ERP (企業資源規劃)、CRM (客戶關係管理)、簽核、財會或人資系統等，

可能需要找到廠商重新授權，額外多付一點費用還算小事，

如果該廠商早已倒閉，這才是真正麻煩的地方。

因此，這個面向需要考慮系統重寫的人力，

或是重新購買軟體授權的費用，公司是否可以承擔。

7.資料移轉是否容易

主要分成現有資料和新生成的資料，

現有的資料庫，在 GCP 上是否有對應的版本，

除了資料本身的遷移之外，

還要評估 Schema、Index、Stored Procedure 或 Trigger 是否都能順利重建。

對於新生成的資料，是否能夠接直指向雲端儲存位置，或是必須額外處理，

例如撰寫排程程式，每天夜間執行上傳。

還有移轉期間是否會中斷對外服務，都是要納入評估的重點。

8.是否能整合雲端服務

以監控系統為例，傳統上都是透過安裝在主機上的代理程式 (Agent) ，

來收集指標和 Log，再集中到伺服器端並以圖表呈現，

你也可以依照這個清單，來判斷是否能夠安裝 OPs Agent，

將指標和 Log 傳送到 Monitoring 和 Logging，

也不用再集中到某台機器上，也避免機器異常導致監控失效。

通知功能也能一併調整，像是主機異常或效能警示，

都可以透過 GCP 使用 Email、APP 或簡訊直接發送給相關人員。

另外關於身份驗證的部分，如果系統本身沒有驗證機制，只要搬上 GCP 之後，

也可以直接採用 Cloud IAP，系統本身不需做任何修改。

另外，公司電腦如果採用 Windows 10 專業版以上版本的話，

可以安裝 GCPW (Google Credential Provider for Windows)，

使用者連本機電腦都可以使用 Google 帳密登入，再搭配兩步驟驗證，

即使電腦被偷，他人也無法輕易登入電腦。

少記一組帳密之外，公司也能順勢將裝置納入管理，

例如禁用藍芽或禁用 USB 插槽等，更加提高了資訊安全。

上述提到的監控與身份驗證機制，

如果與 GCP 的整合性越高，未來在各個系統操作的方便性就越高。

9.是否能夠提升頻寬

公司系統的對外網路，是否曾經遇到頻寬限制，

例如使用者觀看影片總是塞車，

可以先確認向網路營運商購買的寬頻方案，

也可以直接在網站主機使用此 Fast 工具來測試當下頻寬大小。

另一方面關於網頁載入速度，

也可以透過 Google 提供的 PageSpeed Insights 來檢查網頁內容載入是否過慢。

此時可以評估透過 Cloud Storage 儲存影片，並使用 Cloud CDN 加速影片發布，

然後模擬大量人員湧入時，影片的觀看是否順暢，

確認是否能夠減少網路塞車的情況。

10.是否能夠降低延遲 

對於需要即時傳輸資料的場景，

例如金融交易、線上遊戲、直播串流和物聯網等等，

對延遲的敏感度非常高，

因此企業可以針對重要的對外服務，建立測試的架構，

測量延遲改善的程度，是否能增添上雲的必要性。

11.是否能提昇可用性

許多企業在上雲之前，應用程式都只部署在一台主機，

萬一碰到效能問題或其他異常，就是直接停止服務，需要人工介入處理。

而在雲端上，不論是主機、資料庫或檔案儲存，

都可以輕易設定成高可用性模式，

有任何一台機器異常，另一台機器仍然可以持續對外服務，不過要注意成本較高。

但即使企業因成本考量，只能部署一台，

也可以設定自動重建，有異常時直接重建，可讓中斷時間變短。

因此企業可以多加評估可用性的部分，是否也能提升用戶體驗。

12.是否能提昇災難復原能力

通常災難復原能力取決於企業的預算是否足夠，

對於較無預算的中小企業而言，災難復原能力總是不足，

如果公司機房因天災人禍造成巨大損害，幾乎影響公司的存續。

而在雲端上，公有雲資料中心通常具有完善的機房規劃，

機房遭逢天災人禍也不會輕易就被摧毀，

而且許多服務都可以設定跨區域 (Region) 儲存，

即使台灣資料中心嚴重損毀，仍然可由國外的另一個資料中心來恢復服務。

企業可依系統和資料的重要性，在可用的預算範圍內，

評估雲端服務是否能提昇災難復原能力。

13.具有備份和還原機制

各大企業通常對於現有系統都有基本的備份和還原機制，

而雲端不論是主機、資料庫和儲存，也都具備。

因此考量重點會著重在費用上，

因為地端的備份和還原機制通常會依賴第三方廠商，有額外花費，

而其在雲端就只是一個內建的功能，額外花費不多。

再來是設定的難易度，多一家廠商就多一個工具要學習，

在雲端上則可以輕易設定完成。

故企業可以從費用和設定的難易度切入，來評估備份和還原機制是否有加分效果。

14.公司人員是否有足夠的雲端維運能力

公有雲原廠，不管是 GCP、AWS 或 Azure，

由於面對全球大企業的需求，

其支援能力都能達到一定的標準，

反而是公司內部必須盤點現有人員，是否具備雲端維運能力。

雲端雖然很方便，但不代表可以完全不去管理，

或是把責任推托給原廠。

當面臨人力不足的情況下，可以評估是否委由專業的代理商協助。

企業可以就支援時間、回應速度、回覆內容專業性、解決問題能力和費用來綜合比較，

選擇具有專業技術，能夠快速解決問題的代理商。

15.服務水平協議是否保證高可用性

每個公有雲，對旗下各個雲端產品，都有相對應的 SLA，

而每一份 SLA 也有詳細說明服務中斷的認定標準、中斷時間的計算方法，

甚至求償方式也都有相對應的說明，務必看仔細。

簡單來說，不是斷線就會賠錢，你可能要設定 HA 才符合賠償標準，

賠錢也不一定會賠現金，可能只會折抵下月費用。

更重要的是，賠償金額遠遠無法覆蓋你的損失，

所以賠多少錢不是重點，你要做的是，

盡可能部署在 SLA 較高的服務，以減少服務中斷的時間。

這裡也提供你一張表格，讓你可以具體判斷目前適不適合上雲，輸入Email免費下載。

當你將各項評估完成之後，可以加總得到一個分數，滿分為75分，決策標準如下：

60分以上，強烈建議上雲。

45～59分，可以評估考慮上雲。

44分以下，暫時不考慮上雲。

當我們有了具體的評估分數，相信你可以更清楚地判斷上雲的必要性。

最後再提醒一點，上雲也不是一口氣全上，某些系統也可能永遠保持在地端，

你可以製作分階段的上雲計畫，先把非關鍵、或測試的系統上雲，

然後觀察一段時間，確認上雲的流程是否有需要調整或注意的地方，

再把核心系統搬上雲端，確保整個過程可以「平步青雲」。

三、上雲的 6 大好處

其實 GCP 還有很多額外的好處，是上雲之後才能慢慢發現的，

因為剛開始上雲，以穩定運作為首要考量，其他都是次要的，

等到系統穩定下來，並且熟悉雲端基本功能和操作後，

就能再擴展其他雲端的使用，並感受到更多好處。

這裡再分述如下：

1.快速部署和擴展新服務 

靈活應對巿場，才能抓住商機，機會是不等人的。

若某個商品爆紅，你在 GCP 可以馬上找到機器，部署銷售頁面。

若你的遊戲爆紅，GCP 可以馬上擴充，應付海量的玩家連線。

只要採用 GCP，你永遠比別人更一步進入巿場，搶佔先機。

2.全球部署，符合法規

你可以在最靠近使用者的位置部署服務，

減少資訊傳輸的延遲； 

也可以因應法規需求 (例如 GDPR)，

讓資料留在當地，不會外洩到其他地方。

3.快速掌握最新技術

生成式 AI 的軍備競賽，Google 早已大量投入，

讓你隨時可以站在巨人的肩膀上，

掌握最前沿的技術優勢。

此外面試日益嚴峻的資安環境，

Google 也在今年推出各種 AI 防禦方案，

讓你可以安心地使用 GCP。

4.營運不中斷，更好的客戶體驗

以往服務要更新，總是要對外公告，然後用戶被迫在某些時間不能使用服務，

但現在，你可以輕易在 GCP 上執行 Canary Deployment，

針對新版發送少部分流量，若碰到問題可以馬上把流量導回舊版，

若新版沒問題，也可以逐步增加流量，再慢慢把舊版下架。

新舊版無縫接軌，使用者渾然不知，達到更好的客戶體驗。

5.一致的環境，更安全的資料傳輸

GCP 統一使用 Google 帳號驗證，

即使你使用 Windows AD (Active Directory)，

也可以透過 AD FS (Active Directory Federation Service)，

讓使用者輸入 AD 的帳號密碼來登入 GCP，

不需要兩組帳密，避免忘記密碼或密碼被偷的風險。

而系統之間的串接和 API 的呼叫統一使用 Service Account 來驗證，

你再也不用把個人帳密放在程式碼裡面，

減少帳密被偷、系統被駭的機率。

另外在 GCP 的網路中，你可以透過內網存取或串接服務，

不需要把系統 IP 曝露在外，或是讓流量經過網際網路，

而且服務之間的傳輸，在 GCP 是預設加密的，

都可以讓你更安全地使用 GCP。

6.激發創新，快速迭代

以往員工有新的 Idea，想要快速開發 Prototype，

最麻煩的就是要找機器，以及設定對外服務的 IP 或網域。

甚至還要跑簽核流程，看主管的臉色跟心情。

現在你只要滑鼠點兩下，機器就開好了，

或是程式碼 Commit 出去，Cloud Run 就開始對外服務。

你再也不用找機器，也不用等簽核，

上線之前不用花半毛錢，測完之後可以馬上下架。

想做什麼都是立刻、當下，

快速試錯與驗證，根據巿場回饋快速迭代，

一周就推出一個版本，一年後你的產品已經搶下整個巿場。

結語

最後，近幾年有個非常紅的「思維黃金圈」理論，

你可以思考你們公司的「經營使命」或「創業初衷」是什麼？

例如 Google 「我們的使命是匯整全球資訊，供大眾使用，使人人受惠。」

Amazon 「努力成為地球上最以客戶為中心的公司。」

如果聽起來太虛無飄渺，我們來看便利商店的經營使命：

7-11 「提供消費者全方位的便利，創造引領消費者新優質生活型態」

全家 「以顧客為核心，成為無所不在的跨產業便利生活服務平台」

你可以回想，公司的使命是什麼？

而上雲的這些理由跟好處當中，是不是有些對公司的使命有所幫助。

如果是的話，你還在猶豫什麼呢？

本文同時刊登於 思想科技官方網站 《企業上雲的 10 大理由和 6 大好處》與《企業上雲必知的 15 個評估面向》。

The post 企業上雲的10大理由、15個評估面向與6大好處 first appeared on 東東 GCP 教學 - GCP 實戰講師.