PCA 雲端架構師之旅 13 — 安全與成本

走到第 13 步，架構的骨架都立起來了。算力、資料庫、網路、容錯、DR 全都安排好了，圖也畫得漂漂亮亮。但還剩兩件事沒收，而這兩件常常才是一個架構「過不過得了老闆那關」的關鍵：安全讓它不會出事、成本讓它不會被砍掉。

我看過不少團隊架構做得很乾淨，技術選型也挑不出毛病，結果在主管會議上被一句「這要花多少錢？我看不懂」打回票。也看過反過來的——成本壓得很漂亮，上線三個月後一個權限沒收好，把 production 資料庫整個刪了。安全跟成本就是這樣，平常沒人在意，出事一次全公司都記得你。

這是 13 步驟 PCA 雲端架構師之旅 的最後一站。前面十二步學的東西，這一篇要全部串起來收尾。

---

為什麼考試把這兩件事綁在一起

PCA 的 case study 題目，安全跟成本幾乎不會分開考。原因很簡單：現實裡它們本來就在互相拉扯。

便宜但不安全的設計過不了——你把所有東西丟在一個 default network 裡、IAM 全開 Editor，是省了不少設定工，但只要題目提到合規或資料隔離，這種答案直接出局。安全但超預算的設計也過不了——每個服務都上 HA、每個 region 都複製一份、加密金鑰全自己管，安全是滿分了，可是老闆說的「每月不得超過 $X」你完全沒理會，一樣不會過。

考題長相大概是這幾種：

• 「開發團隊不應該看得到 production 的資料」——這在問你 IAM 怎麼分離。
• 「PCI-DSS 合規、金流資料不能外流」——這在問你 VPC Service Controls。
• 「老闆說這個架構每月不得超過 $X」——這在問你會不會估成本。
• 「過去三個月帳單暴增 50%，找出原因」——這在問你會不會做成本歸因跟最佳化。

最後那種「帳單暴增找原因」的題目特別愛考，因為它逼你跳脫「列服務」的思維，去想「哪一項最容易失控」。劇透一下：答案幾乎都跟 egress 有關，下面會講。

---

安全：分層想，而不是列清單

剛入行的人講安全，常常變成「我有開 firewall、我有用 IAM」這種列清單式的回答。但 GCP 的安全設計真正的精神是分層——每一層管一種威脅，某一層被穿破，還有下一層頂著。考試很愛用這個角度切，所以你最好心裡有一張清楚的分層圖：

層級	GCP 工具	對應威脅
身分與存取	IAM、Workload Identity、Service Account	權限外洩、內部濫權
網路邊界	VPC firewall、Cloud Armor、Private Google Access	DDoS、SQL injection、路由暴露
資料保護	CMEK（客戶管理金鑰）、Secret Manager、DLP API	資料外流、金鑰管理
服務邊界	VPC Service Controls、Shared VPC	API 資料外洩、跨團隊隔離
監控與稽核	Cloud Audit Logs、Security Command Center	異常行為偵測、合規稽核

這張表你不用死背欄位，但要能反應：題目給你一個威脅，你立刻知道它落在哪一層、該拿哪個工具。題目說「擔心有人從外部打 DDoS」，你腦中就要跳出網路邊界那一格的 Cloud Armor；說「怕內部工程師亂搞資料庫」，你想的是身分與存取那一格的最小權限。

撐起整張表的，其實就兩條原則：

最小權限（Least Privilege）——永遠選最窄的那個 predefined role，不夠用再考慮 custom role，最後才輪到 Owner / Editor。實務上我看過太多專案圖方便，一律給 Editor，反正「先讓它跑起來」。問題是這種「暫時的」權限永遠不會被收回，等到資安稽核或真的出事，沒人說得清楚誰能動什麼。考題對這點零容忍——只要選項裡有人拿到超出他工作需要的權限，那個選項就是錯的，沒有灰色地帶。

縱深防禦（Defense in Depth）——不要把所有賭注押在單一防線。Cloud Armor 擋住外部攻擊，不代表內部就安全；VPC 隔離做好了，金鑰還是得管好。多一層，攻擊者就多一道關卡。

📝 考場提點

看到 IAM 角色的選項，先做一個動作：把每個選項裡「最寬的那個權限」圈出來，比誰給得最窄。只要某個選項出現 Owner / Editor，而題目又強調隔離、合規、最小權限，那它幾乎篤定是陷阱選項。Google 出題很愛擺一個「功能上做得到、但權限給太大」的答案在那邊釣你，看起來能解決問題，其實違反原則。記住考試的判準不是「能不能動」，是「該不該給」。

---

成本：你以為貴的不貴，真正貴的你常忘記算

成本這塊，新手最大的盲點是只盯著看得到的那一項。看到 VM 就算 vCPU、記憶體、時數，算得很仔細，然後帳單來了傻眼——明明 compute 沒那麼貴，怎麼總額多了一大截？

因為 GCP 的帳單從來不是單一一項，它是好幾塊加起來的：

成分	主導因素	降低方式
Compute	vCPU、記憶體、執行時數	CUD / Sustained Use Discount、Spot VM、Cloud Run
Storage	容量、儲存類別、region	生命週期規則、Nearline/Coldline/Archive
Data Transfer	Egress 量（region 間、出 internet）	同 region 部署、善用 Cloud CDN、Private Google Access
Managed Services	固定月費或量計費	用量對齊 SKU、避免過度設計

四項裡面最容易爆雷的是 Data Transfer，尤其是 egress（流出）。原因是它最隱形——你開服務的時候沒人提醒你「等等這個流量會收錢」，它就靜靜地累積。我看過最痛的一種狀況：分析團隊把 production 資料庫（在 A region）的資料拉到另一個 region 的 BigQuery 跑報表，跨 region 傳輸天天跑，月底 data transfer 那一項比 compute 還貴，查了老半天才發現是這個。

所以那道「帳單暴增 50% 找原因」的考題，第一個該懷疑的就是 egress：是不是新加了跨 region 的複製？是不是有東西在大量出 internet 卻沒走 CDN？這個直覺要先建立起來。

降成本的手段，PCA 要你會幾招：

• CUD（Committed Use Discounts）——承諾用 1 年或 3 年換折扣，折扣依機型與 commitment 類型而異。resource-based CUD（綁機型，一般用途約 1 年 37% / 3 年 55%，記憶體優化機型 3 年最高 70%）比 spend-based / flexible CUD（綁花費、可跨 Compute / GKE / Cloud Run，約 1 年 28% / 3 年 46%）折扣更深。換句話說，穩定長跑的 production 工作負載拿來綁 CUD，省最多。
• Sustained Use Discounts——Compute Engine 跑滿一個月自動給折扣，不用你做任何事，比例依機型而異：多數現行機型（N2/N2D/C2 等）最高約 20%，N1 / sole-tenant 最高 30%。但要注意 E2 機型不適用 SUD——這點下面成本範例會踩到，E2 本身單價就壓得低，所以不另外給 SUD。
• Spot VM——相對標準機型有大幅折扣，代價是隨時可能被回收。production 的 web 服務絕對不能用，但 batch、容錯型的工作很適合。
• Cloud Storage 儲存類別——Standard → Nearline → Coldline → Archive，資料越少讀越便宜。冷資料還放 Standard 等於白白多付錢。

---

兩件事一起想：先安全、再算錢

實務上做架構，這兩件事我會分兩輪過。

安全先把這幾個問清楚：誰能存取這個資源，每個 principal 是不是只拿到他需要的 role；資料會經過哪些網路邊界，每一段是 public 還是 private、有沒有加密；金鑰由誰管，是 Google 預設管、還是 CMEK、還是要到 CSEK 那種程度；最後是出事查得到嗎，audit log 有沒有開、留多久。這四個問完，安全的骨架就出來了。

成本再過一輪：固定費用跟變動費用各佔多少（固定費用是你的底線，變動費用決定尖峰會衝多高）；egress 從哪裡來（跨 region？跨雲？出 internet？——這是最大的隱形成本）；哪些資源根本可以關掉（非 production 的 VM 晚上關、dev 環境週末關，這種沒人記得做但省超多）；哪些服務其實不用全套 HA（不是每個東西都需要高可用，非關鍵的單區跑就好）。

順序很重要：先把安全的紅線顧好，再來談錢。因為安全那幾條——最小權限、加密、audit log——是不能拿來省的。下面範例會看到，就算預算砍半，這幾條也得留著。

---

走一遍範例 — 登雲書店

前面十二步我們陪登雲書店把架構一路搭起來，最後這一步幫它把安全收緊、把成本算清楚。

安全設計

IAM 角色規劃

角色群組	Project	授予權限
dev-team@	cloudon-dev	roles/editor（僅限 dev 專案）
dev-team@	cloudon-prod	roles/viewer（read-only，看 log 除錯）
ops-team@	cloudon-prod	roles/compute.instanceAdmin、roles/iam.serviceAccountUser
sre-oncall@	cloudon-prod	透過 PAM 臨時授予 roles/editor，2 小時過期
billing-admin@	組織層	roles/billing.admin 僅限 2 位

這張表回應的正是 case study 裡那句「開發團隊不應該看得到 production 的資料」。注意 dev-team 在 prod 只有 viewer——能看 log 除錯，但動不了任何東西。on-call 那行也值得學：平常不給 prod 的寫權限，真的出事才透過 PAM 臨時開兩小時、過期自動收回。這就是最小權限的活用——權限不是給或不給的二選一，還能「需要的時候才給、用完就還」。

網路邊界

• 所有 public 入口走 Global External Application LB + Cloud Armor。
• Cloud Armor 規則：rate limit（每 IP 每分鐘 300 req）+ OWASP Top 10 preconfigured rules + 國家白名單（若業務僅限亞洲）。
• VPC firewall：預設 deny all、明確列出允許的 tag → tag 流向。「預設拒絕、白名單放行」這個方向比「預設放行、黑名單封鎖」安全得多，考題很愛用這點分高下。
• Cloud SQL、Memorystore 一律走 Private Service Access，不給 public IP。資料庫掛 public IP 是最常見的踩雷之一，等於把後門開在大街上。

金鑰與機密

• Cloud SQL、Cloud Storage 使用 CMEK（by Cloud KMS）——金流相關資料用自己管的金鑰，合規稽核時你說得清楚金鑰生命週期由誰掌控。
• 應用機密（API key、DB password）放 Secret Manager，Pod 透過 Workload Identity 讀取，不寫進 image。把密碼硬編進 image 或環境變數是另一個經典死法，image 一外流密碼跟著走。

服務邊界

• 金流相關服務用 VPC Service Controls 建 service perimeter，防止資料被 exfiltrate 到外部 GCS bucket。這直接對應 case study 的「PCI DSS 合規、金流資料不能外流」。
• Shared VPC：網路由中央網管團隊管（host project），app 團隊只用 service project，網路設定不會被各團隊各搞各的。

成本估算（月費估算邏輯）

下面這張表的數字是用公開 pricing 邏輯推估的，給你建立量級感，實際金額一律以 GCP Pricing Calculator 為準——考場上不會要你算到個位數，但會要你知道「哪一項是大頭、哪一項可以砍」。

類別	服務與規格	估算邏輯	月費級距
Compute	GKE regional cluster，平均 15 個 e2-standard-4 node	15 × $100 左右 vCPU/RAM 費	$1,500 級距
Compute	Cloud Run 後端，月請求 3,000 萬、平均 200ms	請求數 × 執行秒數 × 記憶體 三軸計費	$300 級距
Database	Cloud SQL PostgreSQL HA db-custom-4-16 + 2 replica	primary + HA standby + 2 replica 各自計費	$900 級距
Database	Bigtable 3 節點 SSD asia-east1	節點數 × 時數 + 儲存 GB	$1,500 級距
Storage	Cloud Storage 10 TB Standard + 20 TB Coldline	Standard 每 GB 單價遠高於 Coldline	$400 級距
Network	Egress 到 internet 3 TB/月	Egress 依流出 region 與量計費	$300 級距
CDN/LB	Global LB + Cloud CDN	LB 轉發費 + CDN cache fill / egress	$250 級距
監控	Cloud Logging + Monitoring + Error Reporting	logs ingest GB 數為主	$200 級距

粗估月費區間：約 $5,000 - $6,000 美元級距（未計年度承諾折扣）。

看這張表的時候，重點不是背數字，是看「結構」：compute 跟 database 兩塊就佔了大半，這告訴你最佳化要先從這裡下手；egress 雖然只有 $300 級距，但它是最容易在某次架構調整後悄悄翻倍的一項，要盯著。

最佳化怎麼做：

• GKE node 綁 3 年 CUD：compute 部分可省約 55%（resource-based、一般用途機型，跟前面講的折扣口徑一致）。production 長跑的算力綁起來，這是 CP 值最高的一招。
• 開發環境 Cloud Run min instances 設 0——沒人用就完全不收錢，代價是第一個請求要忍受冷啟動，dev 環境完全可以接受。
• Bigtable 非尖峰時段用腳本自動縮節點，白天忙、半夜閒，沒道理整天養滿。
• Cloud Storage 加 lifecycle rule：30 天 → Nearline、90 天 → Coldline、365 天 → Archive，讓冷資料自己往便宜的儲存類別搬。

如果題目逼你砍預算

case study 很愛追問一句：「如果預算要砍半呢？」這題在考你的取捨判斷力——你知不知道什麼能砍、什麼絕對不能砍。

可以砍的：DR 層級從 warm standby 降到 pilot light（復原慢一點，但成本掉一大塊）；Bigtable 那套分析改用單一 Cloud SQL read replica 頂著；GKE 改 Cloud Run，省掉節點空轉的錢。

絕對不能砍的：IAM 最小權限、加密、audit log。這三條一旦為了省錢拿掉，等於把整個架構的安全地基抽掉——而且考題答案永遠是「保留」。記住一件事：成本可以妥協，合規與安全不行。預算砍半是商業決定，但拿掉加密是合規事故，兩者不在同一個量級。

📝 考場提點

「帳單暴增找原因」「預算砍半怎麼辦」這類開放追問，時間有限的話用一個固定順序掃：先看 egress（最常見的隱形大頭，跨 region 複製、沒走 CDN 的對外流量），再看 沒關的閒置資源（dev/test 環境、非尖峰的算力），接著是 儲存類別沒下放（冷資料還放 Standard）、沒綁 CUD 的長跑 compute。砍的時候由外往內：先動 DR 等級、再降非關鍵服務的 HA，最後也絕不碰 IAM、加密、audit log。把這個順序記熟，這類題目你就有一套穩定的答法，不用每次臨場硬想。

---

幾個容易在考場被釣的細節

走到終章，留幾個我看過最多人栽進去的點給你收尾：

Custom IAM role 的範圍搞混。 custom role 在 org、folder、project 不同層級套用，影響範圍不一樣。常見的死法是給了一個 project owner 等級的 custom role，卻沒注意它夾帶某個敏感 permission（例如 iam.serviceAccounts.actAs，這權限能讓人冒用 service account 的身分）。考題會故意把這種「看起來合理、但偷塞危險權限」的 custom role 擺進來。

log ingest 的錢忘了算。 GKE 把 debug log 全開、應用程式的 INFO 全部 ingest 進 Cloud Logging，一個月累積好幾 TB 不誇張，帳單能讓你嚇一跳。實務上一定要設 log exclusion filter，只留真正有用的；考成本題的時候，log ingest 也是個容易被忽略的成分。

Shared VPC 跟 VPC Service Controls 分不清。 這兩個名字像、但管的事完全不同——Shared VPC 是網路資源共用（host project 提供網路、service project 來用）；VPC Service Controls 是 API 呼叫的資料邊界（限制資料被搬到 perimeter 外）。它們互補、不互斥，一個架構可以兩個都用。考題最愛挑一個出來，看你會不會張冠李戴。

---

延伸閱讀

• Google Cloud 架構框架：安全
• IAM 最佳實踐
• VPC Service Controls 總覽
• GCP Pricing Calculator

---

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 12 — 災難復原 (DR)

13 步走完了。從第一篇搞懂業務需求，一路收斂到這張成本表，你手上拿到的不只是一張架構圖，而是一套能在 PCA 案例題上重複套用的思考流程。接下來就是多跑幾次真實的 case study 把它練順——練到夠熟，考場上每一題都會變成你早就走過的步驟。

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 13 填入你的 case study，邊寫邊內化。