簡介
Network Service Tiers 讓 Google Cloud 客戶能以「資源為單位」決定對外流量是要走 Google 自家的私有全球骨幹網（Premium Tier），還是走 公開網際網路（Standard Tier）。這個選擇會改變路由行為、可用的負載平衡器類型、可預留的靜態 IP 種類、Google 提供的 SLA，以及最直觀的——每 GB 的 egress 單價。對 PCNE 考生而言，這個階層幾乎出現在所有「為多區域 Web 應用設計網路」的情境裡，因為選錯階層會悄悄打斷 Global External Load Balancing、Cloud CDN 與 BYOIP。本篇研讀筆記涵蓋路由物理層、計價模式、如何在專案或單一資源層級切換階層、計費可視性，以及 Premium Tier 不容妥協的數個場景。
Network Service Tier 是 Google Cloud 的一個設定旋鈕（PREMIUM 或 STANDARD），用於選擇外部 IP 流量在 Google 網路與公開網際網路之間的遞送方式。它套用在 forwarding rule、外部 IP 位址與持有暫時性外部 IP 的 Compute Engine 執行個體上。它不適用於內部 VPC 流量、Cloud Interconnect 或 Cloud VPN。
Premium Tier：Google 全球骨幹網與冷土豆路由
Premium Tier 將流量從發起端使用者沿著 Google 私有光纖骨幹網 一路送到目的區域。封包在 離使用者最近的邊緣 POP（全球超過 200 個）進入 Google 網路，穿越 Google 自有光纖與海底電纜，僅在抵達承載工作負載的區域時才離開 Google 網路。回程流量走的是同一條反向路徑。
冷土豆路由解析
「冷土豆 (Cold Potato)」意思是 Google 會盡可能「握緊」封包——讓它保持涼的、不要丟出去——越久越好。決策邏輯：在入境 POP，Google 會查出哪一個區域服務目的 IP，然後用 Google 內部路由協定把封包送上自家骨幹。公開網際網路只負責最後一段——從終端使用者的 ISP 到 Google 最近的 POP，這通常只是一個 AS hop。
單一 anycast IP 涵蓋全球
Premium Tier 是 Google 全球 anycast 廣播能力的基礎。一個 --global 外部 IP（例如附加在 Global External Application Load Balancer 上）會從每一個 Google POP 同時廣播。東京、法蘭克福、聖保羅的使用者都打同一個 IP，由 BGP 把每位使用者送到最近的 POP。這也是 --global forwarding rule 必須使用 Premium Tier 的原因。
SLA 與可靠性
Google 為外部流量公開的 VPC SLA 99.99% 可用性 僅涵蓋 Premium Tier。Standard Tier 流量落在區域基礎設施 SLA 之下，並繼承底層網際網路路徑提供的可用性。對承載營收的客戶流量而言，Premium Tier 是唯一受財務補償保障的階層。
Premium Tier 是 Compute Engine VM 在指定 --network-tier=PREMIUM 或完全省略旗標時的預設值。要切換到 Standard 必須明確設定——這代表你第一個臨時 VM 幾乎一定跑在 Premium 上，會讓編列「便宜實驗環境」預算的團隊大吃一驚。用 gcloud compute project-info update --default-network-tier=STANDARD 設定專案層級預設可以避免這種狀況。
Standard Tier：公開網際網路與熱土豆路由
Standard Tier 在 盡可能靠近目的區域邊緣的位置 把流量交給公開網際網路。封包從靠近工作負載的區域 POP 離開 Google 網路，經由一個或多個轉接 ISP 送達終端使用者，沿途穿越 Google 無法掌控的網路。
熱土豆路由解析
「熱土豆 (Hot Potato)」意思是 Google 把封包當作燙手山芋，盡快丟到下一個網路上。出口決策在區域層級做：Google 的路由器挑選最近的 IXP 或 transit peer，找出能到達終端使用者的路由，封包從那一刻起就自求多福。效能取決於所選 transit 路徑的品質，受擁塞、路由變動，以及 Google 無法掌控的網路 BGP 收斂影響。
僅支援區域 anycast
Standard Tier 外部 IP 是區域層級的，使用 --region=REGION 預留。你無法把同一個 Standard Tier IP 從多個區域同時廣播；每個區域跑自己的 forwarding rule 與自己的 IP。這就是為什麼 Standard Tier 無法支撐全球負載平衡器——根本沒有一個可全球宣告的單一 IP。
成本效益的 Egress
團隊選 Standard Tier 的頭號理由就是價格。對相同目的地而言，Standard Tier 的網際網路 egress 比 Premium Tier 大約便宜 30-50%，依來源區域而異。對於把大量位元組送往單一地理區的工作負載（例如東京 CDN 來源站串流給東京訂閱用戶），節省的金額會迅速累積。
可接受延遲變動的場景
Standard Tier 的延遲變動很大。聖保羅使用者到 us-central1 的 Standard Tier VM 的請求，可能會經由邁阿密、亞特蘭大、再到芝加哥的兩個不同 ISP，比 Premium Tier 路徑多加 50-150 ms。對背景批次流量、內部管理工具或非互動式爬蟲而言這無關緊要。對即時遊戲後端就是無法接受。
PCNE 混淆題會把 Standard Tier 包裝成「全球分散式電商應用」的「成本優化選項」。這是錯的：Standard Tier 不能承載全球 anycast IP，所以架構會退化成每個區域一個區域 LB，使用者必須透過 DNS 被分流到特定的區域 hostname——失去單一 IP 的簡潔性、TLS 變得複雜，也完全打斷 Cloud CDN。
計價模式與 Egress 成本差異
Network Service Tier 計價是疊加在底層 LB、NAT 或 VM 計費上的獨立項目。Google 在 VPC 網路計價 頁面公開每個來源區域對每個目的洲別的費率。
Premium Tier 分量級計價（示意）
從 us-central1 出發的 Premium Tier egress 對全球目的地以三層用量計費：
- 0-1 TB/月：到大多數目的地約
$0.12/GB。 - 1-10 TB/月：約
$0.11/GB。 - 10 TB 以上/月：約
$0.08/GB。
跨洲目的地（澳洲、中國）會在北美牌價上加價 50-100%。請務必查閱最新計價頁面，費率會變動。
Standard Tier 計價
從 us-central1 到北美的 Standard Tier egress 約 $0.085/GB 統一價（沒有分量級折扣），到亞洲或南美則約 $0.11-0.14/GB。統一結構意味著當 egress 用量很大（每月 >50 TB），Standard Tier 開始失去對 Premium Tier 分量級折扣的價格優勢，所以成本案例最強的是中等用量、單一地理區的流量。
Cache fill 與跨區域細節
Premium Tier 後端的 Cloud CDN cache fill 走 Google 骨幹，依 Premium egress 計費。把 LB 切到 Standard Tier 不會改變 cache fill 成本，因為 cache fill 是 Google 內部流量。但是 cache egress 到客戶端 會改變：Standard Tier 只從區域 POP 遞送，所以雪梨使用者從 us-central1 的 Standard Tier LB 拉內容時，付的是跨洲 Standard egress，不是 Premium egress。
階層價格是單向的、依「來源-目的」配對計算。入境流量（進入 Google）在兩種階層都免費。Premium 在 1 TB 與 10 TB 用量門檻會啟動折扣；Standard 完全沒有用量折扣。對每月 1 TB 以下的工作負載，每 GB 差價小到 Premium 的可靠性通常在 TCO 上勝出，一旦把支援工單與 on-call 半夜被叫醒的成本算進去就更明顯。
依 VM 與依負載平衡器選擇階層
階層設定在負載平衡器的 forwarding rule 上，以及帶有外部 IP 的 Compute Engine VM 的 access config 上。同一 VPC、同一專案，甚至同一應用裡可以自由混用階層——沒有全域鎖。
依 VM 選層
VM 上的暫時性外部 IP：
gcloud compute instances create batch-worker \
--zone=us-central1-a \
--network-tier=STANDARD
--network-tier 旗標在佈建時就附加正確類型的外部 IP。事後要改階層，必須移除 access config、在目標階層預留新的靜態 IP、然後附加上去——無法原地切換。
依負載平衡器選層
對 Network Load Balancer 或 Regional External Application LB 而言，階層設在 forwarding rule：
gcloud compute forwarding-rules create my-fr \
--region=us-central1 \
--network-tier=STANDARD \
--ip-protocol=TCP \
--ports=443 \
--backend-service=my-bs
Global External Application Load Balancer 與 Global Network Load Balancer 只能使用 --network-tier=PREMIUM；指定 Standard 會在驗證階段直接失敗。
依階層預留靜態 IP
靜態 IP 也是在預留當下就被階層鎖定：
# Premium 全球 anycast IP，給 gXLB
gcloud compute addresses create premium-ip --global
# Standard 區域 IP，給區域 NLB
gcloud compute addresses create std-ip \
--region=us-central1 --network-tier=STANDARD
預留好的 IP 無法在階層之間轉換。從第一天就要把 IP 配置規劃在階層選擇上，特別是當外部客戶已經把你的 IP 加入白名單、而你想在不強迫他們更新防火牆規則的情況下換階層時。
對於多區域應用——每個區域前端要求成本敏感、但全球邊緣需要 anycast——可以採用雙層架構：邊緣放 Premium Tier 全球外部 LB 提供 anycast 與 Cloud CDN，內部轉發到每個區域的 Standard Tier 區域 LB。便宜的區域 LB 不直接對網際網路公開，所以你能在跨區域來源拉取上保留 Standard 價格，而不會失去 Premium 邊緣行為。
專案層級預設階層
與其在每一台 VM 與每一個 LB 上都標註，不如為整個專案設一個預設階層，讓沒指定階層的資源繼承它。
設定預設值
gcloud compute project-info update \
--default-network-tier=STANDARD
設定後，任何沒帶 --network-tier 旗標而建立的資源都會預設為 Standard。預設值對 新建 資源即時生效；既有資源在被重新建立前仍保留原本的階層。
何時專案預設值有用
- 重視成本的實驗與開發專案——把預設值翻成 Standard，工程師就不會在臨時 VM 上意外累積 Premium 費用。
- 單一區域的正式環境專案——若整個應用本來就設計成區域型（例如僅限東京的叫車服務），預設為 Standard，僅在必要時明確讓 VM 加入 Premium。
注意事項
把預設設成 Standard 會讓 gcloud compute forwarding-rules create --global 在驗證階段失敗，因為全球 forwarding rule 需要 Premium。錯誤訊息很明確：network tier STANDARD is not supported for global forwarding rule。同樣地，嘗試把 Cloud CDN 附加在 Standard Tier 後端服務上會在建立時被拒絕。
- 預設階層作用範圍：專案層級，僅套用於新資源。
- 旗標：
gcloud compute project-info update --default-network-tier=PREMIUM|STANDARD。 - 用
gcloud compute project-info describe --format="value(defaultNetworkTier)"檢視目前預設值。 - 資源上明確指定
--network-tier永遠覆蓋專案預設。
計費報表中的階層可視性
Google Cloud Billing 會在每一個項目的 SKU 中標註 network tier，所以你能用 BigQuery 或 Billing 主控台在幾分鐘內把 egress 開銷歸屬到 Premium 對 Standard。
SKU 命名慣例
Premium Tier 網際網路 egress SKU 採用 Network Internet Egress from REGION to CONTINENT 模式（Premium）；Standard 採用 Standard Tier Internet Egress from REGION to CONTINENT。SKU 描述只要適用就會帶有字串 "Standard Tier"；Premium SKU 在較舊的報表裡不一定帶有 "Premium" 這個字，這點容易讓人混淆。
在 Billing 主控台篩選
在 Reports 檢視中，依 SKU 分組，並用 sku.description:"Standard Tier" 篩選即可隔離出 Standard 的支出。把 Cost breakdown 檢視篩選到 Networking 服務，可以看出每個階層在總 egress 中的相對權重。
BigQuery 匯出查詢
Billing 資料匯出到 BigQuery 後，下列查詢可以把 egress 成本依階層拆開：
SELECT
REGEXP_EXTRACT(sku.description, r'^(Standard Tier|Premium Tier|Network)') AS tier_bucket,
service.description AS service,
SUM(cost) AS total_cost
FROM `project.dataset.gcp_billing_export_v1_xxx`
WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND service.description = 'Compute Engine'
AND sku.description LIKE '%Egress%'
GROUP BY tier_bucket, service
ORDER BY total_cost DESC;
這讓 FinOps 團隊能在核准任何未來的階層遷移之前，先量化金額影響。
依階層分析的 Cloud Monitoring 指標
指標 networking.googleapis.com/vm_flow/egress_bytes_count 帶有 network_tier 標籤（PREMIUM 或 STANDARD），紀錄 VM 發起的 egress。把它與計費 SKU 組合起來，可以建立比對「送出的位元組」對「實際計費金額」的儀表板。
Premium Tier 強制必要的場景
有些 Google Cloud 服務必須使用 Premium Tier，在佈建階段就會拒絕 Standard。把這份清單背熟在 PCNE 考試上是高效益的。
Global External Application Load Balancer (gXLB)
全球 LB 必須從每個 POP 廣播同一個 anycast IP，這在本質上就是 Premium Tier 能力。傳統 Global HTTP(S) LB 與新版 Global External Application LB 在全球 forwarding rule 上都需要 --network-tier=PREMIUM。Regional External Application LB 可以用 Standard，但會放棄 anycast 與 Cloud CDN。
Cloud CDN
Cloud CDN 安裝在 Global External Application LB（或傳統 classic global HTTPS LB）上，這兩者都需要 Premium。Standard Tier 區域 LB 沒有 Cloud CDN 整合。在 LB 建立時的錯誤訊息是 Cloud CDN can only be enabled on Premium Tier backends。
多區域 (multi-region) Cloud Storage egress
multi-region GCS bucket（例如 US、EU、ASIA）會從最靠近請求者的子區域送出物件，這只有在流量能跨 Google 骨幹路由到正確子區域時才行得通。多區域 bucket 對網際網路的 egress 是以 Premium Tier 計價與路由。區域型 bucket（僅 us-central1）若前面放一個區域 LB，可以走 Standard Tier，但會失去多區域可用性承諾。
跨區域 Cloud Interconnect VLAN attachment
跨區域 VLAN attachment 場景（例如 us-east4 的 Dedicated Interconnect 連到 us-west1 的工作負載）依賴 Google 骨幹，這屬於 Premium 範圍。這個設定是隱含的——你不會在 VLAN attachment 上選階層——但底層傳輸就是 Premium。
IPv6 的 Cloud Load Balancing
全球 IPv6 forwarding rule 需要 Premium Tier；Standard Tier IPv6 只能在區域層級用、且僅限特定 LB 類型。PCNE 題目經常把「為 IPv6 做未來準備」與「Premium Tier」配在一起作為正確答案。
外部位址的 BYOIP
Cloud Load Balancing 與 Cloud CDN 的 Bring-Your-Own-IP 僅限 Premium Tier。前綴會透過 Google 全球 anycast 從每個 POP 宣告——Standard Tier 的區域宣告會違背把前綴全球宣告的目的。
把 Premium-only 清單背熟：Global LB（Application + Network）、Cloud CDN、multi-region GCS 對網際網路的 egress、BYOIP、全球 IPv6 forwarding rule，以及任何提到 "anycast" 或 "global" 的功能。題目若出現「global anycast IP」「單一 IP 服務所有區域」或「Cloud CDN 邊緣快取」，階層答案永遠是 Premium。
Standard Tier 才是正解的場景
Standard Tier 不是「比較差的 Premium」——它是另一個產品，為一組較窄的工作負載最佳化。PCNE 期望你能辨識出這些情境。
單一區域、重視成本的工作負載
一家僅從 asia-east1 服務台灣使用者的 SaaS 公司，可以在區域 Network Load Balancer 上使用 Standard Tier，把 egress 省下 30-50%。延遲代價可以忽略，因為使用者與 LB 都在亞洲，路由路徑很短。只要成長計畫不包含擴展到歐洲或美洲，這個階層降級就是長期有效的。
來自第三方 CDN 的靜態內容
如果你的 CDN 策略是在 GCP 前面用 Cloudflare 或 Akamai，本來就不會用到 Cloud CDN。在這個架構裡 GCP 來源站可以是 Standard Tier 區域 LB 或 VM，因為第三方 CDN 處理全球邊緣快取。GCP egress 帳單下降，而第三方 CDN 吸收延遲變動。
批次處理與後台流量
從 us-central1 VM 寫到 S3 的 ETL 作業、或是呼叫第三方 API 的管理工具，對額外幾毫秒的延遲不敏感。用 --network-tier=STANDARD 佈建 VM，那些（通常是大量）資料搬移的 egress 成本就會跟著降低。
遷移與 lift-and-shift POC
評估 GCP 是否適合既有應用時，Standard Tier 讓工程師能在 POC 階段測試平台、而不必先承諾 Premium 計價。確認契合度後，正式切換可以在 Premium Tier 重新佈建 LB 與 IP。
已經在其他地方付過 transit 費用的工作負載
若你的 egress 註定要走付費的電信業者線路（例如透過網際網路交換點回到企業資料中心的 MPLS 連接），Premium 的骨幹效益會被浪費，因為對端網路本來就決定了路徑。改用 Standard，走網際網路交換點到同一個 MPLS 邊緣即可。
為了乾淨的成本稽核，在每一台 VM 與每一個 forwarding rule 上加上標籤如 network_tier_intent=cost_sensitive 或 network_tier_intent=latency_sensitive。然後在 BigQuery 中把 gcp_billing_export_v1_* 與 gce_instance 標籤 join 起來，就能立刻找出「意圖是省成本卻跑在 Premium」的 VM——那些就是立即可以遷移到 Standard 的候選名單。
不停機切換階層
把既有應用從 Premium 遷到 Standard（或反向）需要謹慎控管，因為 IP 無法原地切換。
IP 位址限制
預留好的外部 IP 在預留當下就被階層鎖定。要切階層，必須在目標階層 重新 預留一個 IP、把它附加到資源上，然後釋放舊的。這代表任何被外部引用的 IP 都要做 DNS 層級切換。
重建 forwarding rule
Forwarding rule 同樣把階層嵌在裡面。遷移模式：建立一條 新 的 forwarding rule，使用目標階層、指向同一個後端服務；事先把 DNS A/AAAA 記錄改到新 IP 並設低 TTL（300 秒）；觀察舊規則上流量自然排空；然後刪除舊 forwarding rule。
切換前驗證清單
- 確認 LB 類型支援目標階層（例如全球 LB 不能切到 Standard）。
- 切到 Standard 之前確認後端服務未啟用 Cloud CDN。
- 切到 Standard 之前確認沒有涉及 IPv6 全球 forwarding rule。
- 把新 IP 通知所有外部白名單方更新。
回退計畫
切換完成後至少保留舊（Premium）forwarding rule 與 IP 7 天，讓全球 DNS 快取完全收斂。確認監控顯示沒有殘餘流量後才釋放舊 IP。
常見誤解與考試陷阱
PCNE 情境題裡有幾個重複出現的模式。
誤解：「Standard Tier 會讓內部流量變慢」
Network Service Tier 僅適用於外部 IP 流量。內部 VPC 流量（同 VPC 內 VM 對 VM，即使跨區域）永遠走 Google 骨幹，與階層設定無關。Cloud Interconnect 與 Cloud VPN 同理——它們有自己的計價與 SLA，不受階層管制。
誤解：「把所有 VM 都設成 Standard 就能省錢」
沒有外部 IP 的 VM 不會產生階層計費的 egress。它們透過 Cloud NAT（自己的 SKU）或負載平衡器送出。在沒有外部 IP 的 VM 上指定 --network-tier=STANDARD 無害，但也沒意義。省錢發生在持有外部 IP 的資源上。
誤解：「公開 IP 卻只給內部人員用的應用適合用 Standard Tier」
能從網際網路連到、但僅供內部員工使用的應用，仍然會受惠於 Premium 的可靠性——那些員工是世界各地的遠端使用者，Premium 可預測的延遲能讓他們的 session 保持穩定。只有當延遲真的無關緊要時才選 Standard。
陷阱：「Premium Tier 對 egress 有 99.99% SLA」
99.99% 是 VPC SLA，涵蓋 Premium Tier 外部流量 與 內部 VPC 管線。Standard Tier 流量在公開網際網路路徑上沒有 Google 提供的可用性 SLA，但 Standard Tier 服務本身（egress 機制）在 Google 網路邊緣之前繼承 VPC SLA。閱讀 SLA 相關題目時要把這兩件事分清楚。
陷阱：「階層選擇會影響 Cloud Interconnect 計費」
Cloud Interconnect 與 Cloud VPN 流量不會以 Network Service Tier SKU 計費。它們有自己的 egress 計價（Interconnect attachment 每小時成本加上每 GB 費率）。階層旋鈕不會出現在 Interconnect 佈建中。
PCNE 經典陷阱題會把「為帶有全球 anycast IP 的多區域 Web 應用最小化 egress 成本」與 Standard Tier 配對成迷人的選項。正確答案是 Premium Tier 加上最佳化戰術（Cloud CDN、利用分量級門檻、各區域 GCS 副本）。Standard Tier 不能提供全球 anycast，所以選它就會逼迫重新架構，工程成本反而高於省下的 egress。
白話文解釋
比喻一：從舊金山開車到紐約
想像你載著貴重貨物從舊金山開車到紐約。Premium Tier 像是把 Google 從西岸到東岸的私人快速公路鑰匙交給你。離開舊金山家門那一刻就上 Google 平整、警力充足的道路，一路到紐約裝卸碼頭，無車流、無繞路、無收費突襲，爆胎時還有 Google 拖吊車隨時待命（99.99% SLA）。Standard Tier 像是同一段路改走公共道路。前段在城市街道上沒問題，但幾英里後你就在縣道、州道、聯邦公路之間跳來跳去，由不同單位管理。某些路段順暢、某些路段塞車、某些路段在施工，還可能繞道進入鄉村小鎮。雖然沒付過路費，但你付出輪胎（延遲尖峰）、油錢（吞吐變慢）、與時間（抵達時間飄移）的代價。
比喻二：國際運送——DHL 對地方郵政接力
Premium Tier 像是用 DHL 一條龍 從台北寄包裹到柏林。DHL 掌控每一段——台北收件、香港分揀中心、法蘭克福清關、柏林末端配送，包裹始終在 DHL 追蹤系統內。每公斤單價較高，但送達日期可靠、追蹤資訊細緻。Standard Tier 則像用 最便宜的國際選項，最後一段交給當地郵政。第一家業者在台北收件，把包裹送到法蘭克福，然後交給德國郵政完成最後一程。從丟給德國郵政那一刻起，寄件人就看不到狀態了；包裹可能週二到、也可能因德國郵政遇到下雪而拖到下週一才到。對於朋友的生日禮物可以接受。對於要趕時間給全球企業客戶的合約寄送就完全不行。
比喻三：機場 VIP 通關 vs 公共航廈轉機
Premium Tier 等於在 hub 機場享受 常客頂級會員 待遇。在舊金山走 VIP 通道、走 Google 私人轉乘走廊連接所有登機門、在紐約走 VIP 通道出關。人潮、安檢隊、航廈切換——這些都碰不到你。Standard Tier 則像在中轉 hub 走 公共航廈 轉機。走一般走廊、跟所有人擠電梯、在同一個 TSA 站排隊、仰賴機場一般作業流程。比較便宜（沒有航空公司服務費），但你可能因為第 4 航廈比預期多花十分鐘而錯過下一班。考試比喻：Cloud CDN 是只有頂級會員（Premium）旅客能進的航空公司 VIP 貴賓室；Standard Tier 旅客連那扇門都看不到。
常見問題
問：可以更改既有靜態 IP 位址的網路階層嗎？
答：不行。靜態外部 IP 在預留當下就與階層綁定、無法翻轉。要遷移，請用 gcloud compute addresses create --network-tier=STANDARD --region=...（或 --global 給 Premium）在目標階層 重新 預留一個 IP，把它附加到 forwarding rule 或 VM，然後釋放舊 IP。請預留 DNS 切換時段，因為對外可見的 IP 會改變。
問：Network Service Tier 會影響同 VPC 內 VM 對 VM 的流量嗎？
答：不會。內部 VPC 流量永遠走 Google 骨幹，即使跨區域。階層設定只管 離開 Google 網路、經由外部 IP 進入公開網際網路（或反向進入）的流量。透過私有 IP 走的 VM 對 VM 流量、Cloud Interconnect 流量、Cloud VPN 流量都不在 Network Service Tiers 的範疇內。
問：Cloud CDN 可以跑在 Standard Tier 上嗎？
答：不行。Cloud CDN 附加在 Global External Application Load Balancer（或傳統 classic global HTTP(S) LB）的後端服務上，而這些 LB 在全球 forwarding rule 上需要 Premium Tier。對 Standard Tier 前綴的後端執行 gcloud compute backend-services update --enable-cdn 會以錯誤 Cloud CDN can only be enabled on Premium Tier backends 失敗。若想用 Standard 計價同時擁有類 CDN 行為，請在 Standard Tier 區域 LB 前面放第三方 CDN（Cloudflare、Akamai）。
問：如何查詢既有資源使用哪個階層？
答：對 forwarding rule：gcloud compute forwarding-rules describe NAME --region=REGION --format="value(networkTier)"。對 IP 位址：gcloud compute addresses describe NAME --region=REGION --format="value(networkTier)"。對專案預設：gcloud compute project-info describe --format="value(defaultNetworkTier)"。在主控台中，外部 IP 位址與 forwarding rule 頁面都有階層欄；計費 SKU 描述裡也看得到。
問：Cloud NAT egress 有階層選擇嗎？
答：Cloud NAT 透過 受階層約束 的外部 IP 送出。手動指派 NAT IP 時，你在預留階段選擇階層。Cloud NAT 自動指派 IP 時，會繼承專案預設階層。對許多 GCP 專案而言，繁重的 NAT egress 是最大的隱形 Premium-Tier 費用項目之一——稽核 Cloud NAT IP 對於那些不需要 Premium 來服務 NAT 出站流量的專案，是高槓桿的成本最佳化動作。
問：若我設定 --default-network-tier=STANDARD 之後嘗試建立全球 LB 會怎樣？
答：建立指令會以驗證錯誤失敗，明確指出全球 forwarding rule 需要 Premium Tier。你必須在全球 forwarding rule 建立指令上明確帶 --network-tier=PREMIUM，或把專案預設改回來。許多團隊特別把預設保留為 Premium，就是為了避免 ops 工程師架新全球 LB 時碰到這個困惑。
問：同一個區域內的 egress 在兩個階層上同價嗎？
答：區域 內 的 egress（us-central1 VM 透過內部 IP 到另一台 us-central1 VM）完全免階層費——那屬於區域內 VPC 流量。從 us-central1 VM 到北美 公開網際網路 的 egress 才會啟動階層計費：Premium 約 $0.12/GB（1 TB 以下）對 Standard 約 $0.085/GB。價差在跨洲 egress 上會擴大，Standard Tier 可以便宜 40-50%。
問：可以在單一負載平衡器內混用階層嗎？
答：在同一條 forwarding rule 內不行，但同一個 LB 可以有多條 forwarding rule、分別使用不同階層。常見做法：在正式 hostname 上放一條 Premium 全球 forwarding rule 服務全球使用者，再加一條 Standard 區域 forwarding rule 在「快線」hostname 上，給一個希望擁有自己專屬 IP 的高用量單一區域客戶。兩條規則可以指向同一個後端服務。