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

走到第十三步，算力、資料庫、網路和復原方式都已經放進架構圖。還有兩件事要回頭檢查：誰能操作哪些資源，以及這套方案每月大概要花多少錢。

安全與成本不是圖畫完後才附上的兩個欄位。權限過寬會增加操作風險；只看服務單價、不算網路和備援，費用也可能與預估差很多。這篇會把兩者接回前面每一項設計選擇。

這也是 PCA 雲端架構師之旅 的最後一篇。我們會沿用前面的登雲書店案例，檢查設計裡容易漏掉的安全與費用問題。

安全與成本要一起看

架構選型不能只看安全功能，也不能只看月費。兩者都得回到案例要求：哪些風險必須控制，哪些費用有上限？

例如把所有人都授權 Editor，可能省下初期設定時間，卻讓存取範圍失控。反過來，把每個服務都做多區複製、所有金鑰都改成自管，也未必符合風險與預算。先找出不能妥協的要求，再比較能滿足它們的做法。

考題長相大概是這幾種：

• 「開發團隊不應該看得到 production 的資料」——先檢查身分、權限與環境隔離。
• 「處理支付卡資料，而且要限制外流」——先界定資料流與 PCI DSS 範圍，再選需要的控制措施。
• 「架構每月不得超過 $X」——除了算資源費，也要算流量、備援和維運成本。
• 「過去三個月帳單增加 50%」——先找出是哪個 SKU、哪段用量變了。

Data Transfer 是容易漏算的一項，但帳單變貴沒有固定答案；先看明細，再追查原因。

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

說明安全設計時，只列出「有開 firewall、有用 IAM」還不夠。先問要防的是誰、哪種操作或哪條資料路徑，再安排不同層的控制。這樣即使其中一道防線失效，也不會只剩下運氣。下面這張表可用來整理思路：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

不必死背整張表，可以拿情境練習：擔心公開入口遭到大量惡意請求，就檢查入口與 Cloud Armor 設定；擔心內部人員取得過多資料庫權限，就從 IAM 授權與稽核紀錄查起。同一個情境也可能需要不只一層控制。

flowchart TB
  T[威脅或合規要求] --> I{誰不該取得權限？}
  I -- 有明確身分風險 --> A[IAM＋<br/>Workload<br/>Identity<br/>最小權限]
  I -- 不是 --> N{攻擊來自網路入口？}
  N -- 是 --> F[Firewall＋<br/>Cloud Armor<br/>Private Access]
  N -- 否 --> D{資料或金鑰可能外流？}
  D -- 是 --> K[CMEK＋<br/>Secret Manager<br/>VPC Service<br/>Controls]
  D -- 否 --> O[Audit Logs＋<br/>SCC<br/>偵測與追溯]
  A --> V[組成縱深防禦]
  F --> V
  K --> V
  O --> V

安排這些控制時，有兩個原則很好用：

最小權限（Least Privilege）——先找符合工作需求的 predefined role，不夠用再評估 custom role，避免圖方便就給 Owner 或 Editor。臨時放寬權限也要設定檢查與收回時機，否則事後很難釐清誰能操作哪些資源。

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

📝 考場提點

比較 IAM 角色時，除了確認它能完成工作，也要看是否包含不必要的權限。Owner 或 Editor 可能讓操作成功，卻不符合最小權限要求；應選足夠但不過寬的角色，並把授權範圍限制在真正需要的資源。

flowchart TB
  R[Principal 需要完成工作] --> P[列出必要 permissions]
  P --> D{有符合的 predefined role？}
  D -- 是 --> G[在最低必要層級授予]
  D -- 否 --> C[建立最窄 custom role]
  C --> G
  G --> T{只在事故期間需要？}
  T -- 是 --> A[PAM 臨時提升<br/>自動到期]
  T -- 否 --> V[保留固定最小權限]
  A --> L[Audit Logs<br/>留下授權與操作證據]
  V --> L
  L --> E[定期審查並移除未使用權限]

成本：先看帳單由哪些項目組成

只算 VM 的 vCPU、記憶體和時數，很容易漏掉資料庫、儲存、傳輸與監控費用。就算每項估算都對，少算幾類資源，總額仍會差很多。

先把費用分成幾類：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Data Transfer 容易在估價時被漏掉，尤其是跨 region 或對外的流量。例如分析工作每天把 A region 的資料搬到另一個 region 跑報表，就要把持續產生的傳輸費用算進去，不只看 BigQuery 的查詢費。

若題目說帳單突然增加，可以先比對各 SKU 的變化；如果 Data Transfer 增幅明顯，再查是否新增跨 region 複製或大量對外流量。

flowchart TB
  B[帳單異常增加] --> A[先按 project、<br/>service、SKU<br/>與 label 做歸因]
  A --> E{Data Transfer／<br/>egress 增加？}
  E -- 是 --> E1[查跨 region、<br/>跨雲與未走<br/>CDN 的流量]
  E -- 否 --> I{閒置或過度配置資源？}
  I -- 是 --> I1[關閉 dev／test<br/>Rightsize<br/>與 autoscaling]
  I -- 否 --> S{Storage／Logs 成長？}
  S -- 是 --> S1[調整生命週期、<br/>保留期與<br/>exclusion filter]
  S -- 否 --> C[檢查新 SKU、<br/>複寫與<br/>managed<br/>service]
  E1 --> V[修正後重新驗證帳單與 SLO]
  I1 --> V
  S1 --> V
  C --> V

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

• CUD（Committed Use Discounts）——承諾用 1 年或 3 年換折扣，折扣依機型與 commitment 類型而異。Compute Engine 的 resource-based CUD（承諾特定區域的 vCPU／記憶體用量；1 年最高 37%，3 年最高 55%，記憶體最佳化機型 3 年最高 70%）通常比 Compute flexible CUD 折扣更深。後者屬於 spend-based，承諾的是每小時支出，一份承諾可涵蓋 Compute Engine、GKE 與 Cloud Run：多數機型系列與 GKE 是 1 年 28%／3 年 46%，以請求計費的 Cloud Run 服務只有 17%，記憶體最佳化機型則要 3 年期才有折扣。Cloud SQL、Bigtable、Spanner 等服務另有各自的 spend-based CUD，折扣依產品而異。不論哪一種，適合拿來綁 CUD 的都是穩定長跑的 production 工作負載。
• Sustained Use Discounts——符合條件的 Compute Engine 資源，當月使用時間越長，可能自動取得較高折扣；比例依機型而異。估價時要注意 E2 機型不適用 SUD，下面的 E2 成本範例不能再扣這項折扣。
• Spot VM——相對標準機型有大幅折扣，代價是隨時可能被回收。適合 batch 等可中斷工作；若要承載線上流量，必須另外安排穩定容量與故障切換。
• Cloud Storage 儲存類別——存取頻率低的資料，可以比較 Nearline、Coldline 和 Archive；除了儲存單價，也要算取回費與最低保存期。

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

回到登雲書店，可以分兩輪檢查。

安全先問：誰能存取資源，權限是否只涵蓋工作所需？資料會經過哪些公開或私有路徑？金鑰由誰管理，稽核紀錄要保留多久？這些問題先有答案，才能判斷需要哪些額外控制。

成本再看固定與變動費用各佔多少、Data Transfer 從哪裡產生、非 production 資源何時可以停用，以及哪些工作負載真的需要高可用。不要先假設 egress 一定最大，或每個非關鍵服務都能改成單區；都要拿用量和 SLO 驗證。

預算不足時，應調整容量、保留期限或可用性等可協商項目，而不是讓必要的存取控制與稽核失效。下面用一份粗估帳單示範如何找出可調整的地方。

走一遍範例 — 登雲書店

前面已經為登雲書店選好主要服務。現在用同一個案例檢查權限、網路、機密和每月費用。

安全設計

IAM 角色規劃

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這張表先示範開發、維運與帳務人員如何分開授權。case study 若要求開發團隊不能看到 production 資料，就不要因為 roles/viewer 名稱看起來是「唯讀」，直接授予整個 production 專案；日誌也可能包含敏感資訊。on-call 可透過 PAM 在事故期間取得限時權限，事後再核對操作紀錄。

網路邊界

• 所有 public 入口走 Global External Application LB + Cloud Armor。
• Cloud Armor 規則：rate limit（每 IP 每分鐘 300 req）+ OWASP Top 10 preconfigured rules + 國家白名單（若業務僅限亞洲）。
• VPC firewall：先盤點服務間必要的流量，再明確設定允許規則；沒被任何規則允許的 ingress 會被隱含規則拒絕，egress 則預設允許，要限制對外連線得另外建立 egress deny 規則。
• 這個案例讓 Cloud SQL、Memorystore 走私有連線，並限制能連入的服務；若使用公開位址，還得清楚交代驗證、允許來源與監控方式。

金鑰與機密

• Cloud SQL、Cloud Storage 使用 CMEK（by Cloud KMS）——金流相關資料用自己管的金鑰，合規稽核時你說得清楚金鑰生命週期由誰掌控。
• 應用機密（API key、DB password）放 Secret Manager，Pod 透過 Workload Identity Federation for GKE（原 Workload Identity）讀取，不寫進 image。否則 image 被複製或外流時，機密也會跟著暴露。

服務邊界

• 金流相關服務用 VPC Service Controls 建 service perimeter，降低資料被 exfiltrate 到外部 GCS bucket 的風險。這是回應登雲書店「符合個資法與 PCI DSS 4.0.1」這項需求的控制之一：Google 的 PCI DSS 架構指引也用 VPC Service Controls 來降低資料外流風險；但是否合規，仍要看持卡人資料的範圍與其他控制。
• Shared VPC：由中央網管團隊管理 host project 的網路，應用團隊在 service project 使用核准的網路資源。

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

下面用粗估數字示範怎麼拆帳單。它不是報價：Region、規格、流量與折扣都會改變結果，實際預算仍要用 Google Cloud Pricing Calculator 按自己的條件重算。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Cloud Run 那一列這樣算：採 request-based 計費、asia-east1（Tier 1）單價，假設每個執行個體是預設的 1 vCPU／512 MiB、每個請求各佔 0.2 秒來估上限——600 萬 vCPU 秒 × $0.000024 ＋ 300 萬 GiB 秒 × $0.0000025 ＋ 3,000 萬次請求 × $0.40／百萬次 ≈ $164。這個數字沒有扣每月免費額度，也不含 min instances 的閒置費；同一個執行個體並行處理多個請求時，實際計費秒數會更少。

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

在這份示範估算裡，運算和資料庫佔了較多費用，可以先檢查它們的用量與規格。Egress 目前較小，但如果新增跨區複製或改變資料流，也要重新估算。

最佳化怎麼做：

• 長期穩定運行的 GKE node，可以比較承諾使用折扣與按量付費；先確認用量夠穩定，再決定承諾年限。
• 開發環境的 Cloud Run 可將 min instances 設為 0，減少閒置時的運算費；仍要估冷啟動及其他使用量費用。
• Bigtable 可依負載評估調整節點數，但要先確認最低容量、調整速度與尖峰效能。
• Cloud Storage 可依存取頻率設定 lifecycle rule；轉入 Nearline、Coldline 或 Archive 前，先核對最短儲存時間與取回費用。

預算需要再縮減時

如果題目要求大幅縮減預算，先區分哪些設定可以調整，哪些是安全與合規底線。

可以評估的：非關鍵服務若容許較長復原時間，看看 warm standby 能否改成 pilot light；長期空轉的運算資源，則比較是否能縮容或搬到 Cloud Run。至於 Bigtable 承接的大量事件，不該為了省錢就直接搬到一台 Cloud SQL read replica；先量出讀寫量與查詢需求，再找成本較低的替代管線。

不要為了省錢直接移除 IAM 最小權限、必要的加密或稽核日誌；這些控制若有合規要求，更不能只以費用決定去留。先檢查資源規格、閒置容量和非關鍵服務的可用性配置，再確認調整後仍符合要求。

📝 考場提點

帳單突然增加時，先用 Billing 報表確認哪個 SKU 和用量變動，再查 Data Transfer、閒置資源、儲存、運算等可能原因。若要壓低預算，先移除浪費並調整規格；需要降低 DR 或 HA 等級時，重新核對 RTO／RPO 與 SLO。必要的權限、加密和稽核控制不能在沒評估風險與合規要求前直接刪掉。

flowchart TB
  P[需要降低總成本] --> G[先標出不可妥協護欄<br/>IAM、加密、<br/>Audit Logs、法規]
  G --> W[移除閒置資源<br/>與非必要 egress]
  W --> R[Rightsize、<br/>autoscaling、儲存分層]
  R --> C[穩定長跑負載評估 CUD]
  C --> D{仍需繼續削減？}
  D -- 是 --> H[降低非關鍵服務 HA<br/>或 DR 等級]
  D -- 否 --> V[驗證預算、SLO 與安全控制]
  H --> B{碰到安全或合規底線？}
  B -- 是 --> X[停止削減並協商需求]
  B -- 否 --> V

還有哪些細節容易漏掉？

最後再檢查幾個容易漏掉的細節：

只看自訂角色的名稱，沒檢查權限。 角色名稱無法告訴你它實際能做什麼。授權前應檢查包含哪些 permission、授權作用範圍，以及是否含有 iam.serviceAccounts.actAs 這類需要特別留意的權限。

忘了估算日誌費用。 如果長期收集大量 DEBUG 或 INFO 日誌，Cloud Logging 的費用可能超出預期。先定義哪些日誌需要保存、要留多久，再評估排除規則；排除前也要確認不會丟掉除錯、稽核或資安調查所需的資料。

混淆 Shared VPC 與 VPC Service Controls。 Shared VPC 用來讓 Service Project 共用 Host Project 的網路；VPC Service Controls 則為支援的服務設定存取邊界。兩者解決不同問題，也可能一起使用。

延伸閱讀

• Google Cloud Well-Architected Framework：安全性、隱私權和法規遵循支柱
• IAM 最佳實踐
• VPC Service Controls 總覽
• GCP Pricing Calculator

系列導航

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

這個系列從業務需求談到可靠性、安全與成本。練習新的案例時，可以沿用同一個順序：先確認限制與成功標準，再比較方案，最後用成本和維運能力檢查設計是否落得下來。不同案例的答案不會一樣，但這個檢查流程能幫你發現漏掉的條件。

🎯 換你練習

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