簡介
Cloud CDN 是 Google 全球分散的邊緣快取服務，部署在 Global External Application Load Balancer (gXLB) 或傳統 Global HTTP(S) LB 的前端。它透過全球超過 200 個邊緣節點 (POP) 提供快取回應，讓請求幾乎不需要回到位於 us-central1、asia-east1 或其他區域的來源站。Cloud CDN 是在 backend service 或 backend bucket 層級啟用，只要一個 --enable-cdn 旗標即可開啟，並依快取填入 (cache fill)、快取輸出 (cache egress) 與快取查詢 (cache lookup) 三個維度計費。對 PCNE 考生而言，這個服務常出現在三類情境：降低國際使用者的 p95 延遲、減少來源站輸出成本，以及與 Cloud Armor 堆疊在邊緣提供 L7 防護。
Cloud CDN 在 Google 邊緣節點快取 HTTP(S) 回應，並在 Global External Application Load Balancer（或傳統 Global HTTP(S) LB）的 backend service 或 backend bucket 上設定。它不能附加到 Regional、Internal 或 Network (L4) 負載平衡器。
快取模式：USE_ORIGIN_HEADERS、CACHE_ALL_STATIC、FORCE_CACHE_ALL
快取模式控制 Cloud CDN 在看 TTL 欄位之前，會把哪些回應視為可快取。模式透過 gcloud compute backend-services update BACKEND --cache-mode=MODE 設定。
USE_ORIGIN_HEADERS
最嚴格的模式。Cloud CDN 只會快取符合下列條件的回應：來源站回傳 Cache-Control: public 指令且帶有 max-age 或 s-maxage，或者帶有 Expires 標頭。任何 Cache-Control: private、no-store、no-cache 的回應會直接穿透。當來源站已經自行掌控快取策略（例如 Next.js 或 Hugo 構建會針對每個資產輸出明確標頭），這是最適合的預設值。
CACHE_ALL_STATIC
Cloud CDN 會自動快取 Content-Type 屬於靜態檔案模式（CSS、JS、圖片、字型、影片、壓縮檔）的回應，前提是沒有 private 或 no-store 指令。動態內容（text/html、未帶快取標頭的 JSON 回應）會繞過快取。當來源站沒有快取標頭時，預設 TTL 是 3600 秒。這是行銷網站與 SPA 最容易「開啟後就忘記」的選項。
FORCE_CACHE_ALL
Cloud CDN 忽略所有來源站快取指令，快取每一個成功回應，包括標記為 private 的回應。絕對不要把 FORCE_CACHE_ALL 放在個人化或需登入的端點之前——你會把一位使用者的 session HTML 洩漏給下一位訪客。這個模式適合用在 backend bucket 提供完全公開的靜態網站、或所有 URL 本來就刻意公開的影片清單。
PCNE 常見的混淆選項，會把 FORCE_CACHE_ALL 跟提供登入儀表板的 backend 配對。即使在 URL 路徑中加上簽署網址，被快取的 HTML 內容仍會被送給任何持有相同簽署網址的人，包括未授權但重放連結的對手。個人化回應應該改用 USE_ORIGIN_HEADERS 搭配 Cache-Control: private, no-store。
TTL 設定與 stale-while-revalidate
Cloud CDN 提供三個 TTL 旋鈕，會覆蓋或補強來源站標頭，透過 gcloud compute backend-services update 設定。
default-ttl、max-ttl、client-ttl
--default-ttl（預設 3600 秒）在 CACHE_ALL_STATIC 或 FORCE_CACHE_ALL 模式下、來源站未回傳快取標頭時生效。--max-ttl（預設 86400 秒，最大 31622400 秒 = 1 年）限制來源站送來的 TTL 上限，避免一個設定錯誤的max-age=99999999把內容釘住十年。--client-ttl控制 Cloud CDN 送給 瀏覽器 的Cache-Control: max-age值。把它設得比default-ttl低，可以讓瀏覽器持續重新整理、但仍命中邊緣快取。
負向快取 (Negative caching)
負向快取讓 Cloud CDN 把常見錯誤回應（404、410、451、500、502、503、504）快取一小段時間，避免來源站不穩時被打爆。使用 --negative-caching 啟用，並用 --negative-caching-policy=404=120,500=10 針對不同狀態碼調整 TTL。沒設定的話，每一個從不健康後端傳回的 500 都會穿越 LB 並以 cache miss 計費。
Stale-while-revalidate
當被快取的物件過期時，Cloud CDN 仍可繼續服務（最多到 serve-while-stale，預設 86400 秒），同時在背景對來源站做重新驗證。這可以保護使用者免於快取填入時的延遲尖峰，以及短暫的來源站故障。
PCNE 經常測試優先順序規則：max-ttl 永遠勝出。若來源站送 Cache-Control: max-age=2592000（30 天）但你設了 --max-ttl=3600，邊緣物件會在一小時後過期。若來源站沒送標頭，Cloud CDN 會採用 --default-ttl。瀏覽器快取則由 --client-ttl 管制，Cloud CDN 會把這個值改寫進回應。
自訂快取鍵 (Custom Cache Keys)
Cloud CDN 預設的快取鍵是 (protocol, host, path, query string) 這個元組。兩個只有無關緊要的查詢字串差異的請求（?utm_source=fb 對 ?utm_source=tw）會被視為不同物件，每一個都會強制觸發一次來源站填入。自訂快取鍵能大幅提高命中率。
包含/排除查詢字串
--cache-key-include-query-string搭配--cache-key-query-string-whitelist=v,locale只把?v=與?locale=保留在鍵中；UTM 標籤合併成同一個快取項目。--cache-key-query-string-blacklist=utm_source,utm_medium,utm_campaign,fbclid,gclid是反向做法。
將標頭與 Cookie 納入鍵
Cloud CDN 可以把特定請求標頭（--cache-key-include-http-header=X-User-Country）或具名 Cookie（--cache-key-include-named-cookie=theme）摺入鍵內。這就是 A/B 變體或不同國家版本能分別被快取、又不需要拆 URL 的方法。
主機與通訊協定
--cache-key-include-protocol=false 讓 HTTP 與 HTTPS 共享同一個快取項目，在邊緣做 HTTP→HTTPS 轉址時很實用。--cache-key-include-host=false 可以把多個主機名合併到同一個 bucket 後面。
透過 Cloud Monitoring 的 Cache Hit Ratio 指標（loadbalancing.googleapis.com/https/backend_request_count 用 cache_result 篩選）稽核你的快取鍵。命中率低於 60% 通常代表 UTM 類查詢字串雜訊——把實際需要區分的鍵加入白名單，命中率幾分鐘內就會跳上去。
簽署網址與簽署 Cookie
簽署網址 (Signed URLs) 與簽署 Cookie (Signed Cookies) 讓你從公開的 CDN 邊緣供應私有內容，而不必強迫請求走回來源站。Cloud CDN 在邊緣驗證附在請求上的 HMAC-SHA1 簽章，並在簽章有效且未過期時供應已快取物件。
簽署網址
透過 gcloud compute backend-services add-signed-url-key BACKEND --key-name=key1 --key-file=key.bin 在 backend 上建立請求簽署金鑰。應用程式接著組裝形如 https://cdn.example.com/video.mp4?Expires=1714521600&KeyName=key1&Signature=... 的網址。Cloud CDN 在邊緣驗證簽章；過期或被竄改的網址會回傳 403。
簽署 Cookie
簽署網址一次只簽一個 URL。對於有數百個分段的 HLS 串流，你可以改用單一個 Cloud-CDN-Cookie cookie 透過 Set-Cookie 下發，Cloud CDN 會針對符合 URL 前綴的每個請求驗證它。Cookie 名稱、金鑰與前綴都裝在 cookie 值本身。
金鑰輪替
每個 backend service 可同時有最多 3 把 啟用中的簽署金鑰，這就是零停機輪替的機制：先新增新金鑰、部署新簽署器、再移除舊金鑰。Cloud CDN 會逐一嘗試啟用中的金鑰，直到其中一把驗證成功。
- 簽署網址金鑰為 HMAC-SHA1、base64url、16 bytes。
- 每個 backend service 最多 3 把啟用中金鑰。
- 簽署網址快取的是回應而非 URL——所以
?Expires=…&Signature=…查詢字串會自動排除在快取鍵之外。 - Cookie 以 URL 前綴（例如
/media/）為範圍。
簽署請求認證（來源站身分驗證）
與簽署網址（保護快取存取）不同，Cloud CDN 簽署請求 讓 來源站 信任一個請求確實來自 Cloud CDN。在 backend 上啟用簽署請求後，Cloud CDN 會附加 X-Cdn-Signature 標頭，來源站在供應前先驗證它。這可以防止「攻擊者找到來源站 IP 後直接繞過 LB/CDN」的攻擊。
設定方式
簽署請求透過 --signed-url-cache-max-age-sec 與安裝在來源站上的一組獨立簽署金鑰啟用。來源站（通常是 NGINX、App Engine 應用或 Cloud Run 服務）計算相同的 HMAC，不符就回 403。可以再搭配只允許 Google 的負載平衡器 IP 範圍（130.211.0.0/22、35.191.0.0/16）的來源站防火牆規則，達到縱深防禦。
簽署請求 vs VPC SC vs IAP 該選哪個
- 簽署請求——最適合外部 HTTPS 來源站（例如設了
--ingress=internal-and-cloud-load-balancing的 Cloud Run），這類情境你無法在前面放一個私有 VPC。 - VPC Service Controls——保護當作來源站的 GCS bucket 免於資料外洩。
- IAP——互動式的內部應用程式；不相容於需快取的公開 CDN 內容。
Cloud Storage 當作 CDN 來源站 (Backend Buckets)
Backend bucket 是 Cloud CDN 直接從 Cloud Storage bucket 供應靜態內容、完全不需要佈建運算資源的方式。透過 gcloud compute backend-buckets create static-assets --gcs-bucket-name=my-bucket --enable-cdn 把 bucket 附加到 URL map。
權限與存取
負載平衡器以專案的負載平衡器服務身分讀取物件；若 bucket 是私有的，需要把 roles/storage.objectViewer 授予 [email protected]。對於完全公開的 bucket，授予 allUsers 為 viewer 是可接受的，但建議搭配 Cloud Armor 邊緣政策來節流惡意爬蟲。
URL 重寫
像 /static/* → backend-bucket: static-assets 這樣的 pathMatcher 規則讓單一主機可以混搭動態 backend（Cloud Run 處理 /api/*）與 bucket 來源站（/static/*），統一掛在同一個 CDN 設定下。
成本行為
Backend bucket 的快取填入算作 Google Cloud 內部 輸出，這比從 Compute Engine VM 來源站經過網際網路輸出便宜許多。這是圖片密集網站經典的「搬遷上雲」成本最佳化做法。
要讓 backend bucket 命中率最大化，請設定 --cache-mode=CACHE_ALL_STATIC、--default-ttl=86400、--max-ttl=31536000，並對檔名加版號（logo.7f3a.svg）。這樣部署新版時就完全不需要呼叫失效 API——新建構會引用新檔名，舊物件自然老化淘汰。
GKE 與 Cloud Run 當作 CDN 後端
對於動態工作負載，Cloud CDN 會坐在指向 GKE pod 或 Cloud Run 服務的 NEG (Network Endpoint Group) 前面。
GKE 容器原生負載平衡
帶有 cloud.google.com/neg: '{"ingress": true}' 註解的 GKE Ingress 會建立 zonal NEG，內含 pod IP（不經過 kube-proxy）。在 Ingress 產生的 backend service 上啟用 CDN：gcloud compute backend-services update BACKEND --enable-cdn --cache-mode=CACHE_ALL_STATIC。這是用 GKE 提供 React SPA、由 CDN 快取 build artifact 的標準做法。
Cloud Run serverless NEG
Cloud Run 服務透過 serverless NEG 連到 LB：gcloud compute network-endpoint-groups create cr-neg --region=asia-east1 --network-endpoint-type=serverless --cloud-run-service=my-app。Cloud CDN 接著依相同的快取模式快取回應。Cloud Run 自身的 per-revision 回應快取是獨立的——CDN 坐在前面可以吸收原本會把 Cloud Run 擴展到多個執行個體的流量。
健康檢查與 CDN
Cloud CDN 本身不會繞過健康檢查。若 LB 把某個 backend 標記為不健康，所有流量會切換到其他健康 backend，但已快取的回應仍由邊緣繼續供應。這就是 Cloud CDN 在部分來源站故障時能顯著提升可用性的原因。
動態壓縮 (Dynamic Compression)
Cloud CDN 可以在邊緣即時用 Brotli（首選）或 gzip 壓縮回應，即使來源站送出未壓縮的 bytes 也行。使用 gcloud compute backend-services update BACKEND --compression-mode=AUTOMATIC 啟用。
自動壓縮的判斷邏輯
Cloud CDN 檢查請求的 Accept-Encoding 標頭與回應的 Content-Type。文字類型（HTML、CSS、JS、JSON、SVG、XML）最多到 10 MB 會被壓縮；已壓縮的類型（JPEG、MP4、WOFF2）會跳過。Vary: Accept-Encoding 標頭會被自動加上，這樣 gzip 與 br 變體會分別快取。
何時要停用
若來源站已經回傳 Brotli（Content-Encoding: br），設 --compression-mode=DISABLED 避免重複處理。對於回應很小（<1 KB）的延遲敏感 API，壓縮的 CPU 成本可能會抵掉頻寬節省；上線前先做基準測試。
壓縮與快取是分開的。回應可以未壓縮地快取在邊緣，再依每次請求做壓縮後送出。這代表開啟自動壓縮不會讓既有快取項目失效。
快取失效 (Cache Invalidation)
版本化 URL 是建議的失效策略，但若遇到緊急內容下架（法律下架命令、外洩憑證頁），Cloud CDN 提供同步的失效 API。
gcloud 與 API
gcloud compute url-maps invalidate-cdn-cache URL_MAP --path="/news/2026/article.html" 可清掉單一路徑。Path 支援尾端單一 * 萬用字元（/blog/*），但不支援巢狀模式。失效是全球性的，一般幾分鐘內完成。
配額與最佳實踐
每個專案預設配額為每分鐘 1,500 次失效，但 Google 強烈不建議在正常發佈流程中倚賴失效。原因是：即使下達失效，仍在傳輸中的請求可能仍會收到舊物件。版本化檔名（app.5fa1.js）可以完全避開這個競態狀況。
依標頭或 Cookie 選擇性失效
失效只依 URL 路徑 匹配。若你用 X-User-Country 快取不同變體，所有國家變體會一起被失效。你沒辦法只失效「/home 的 JP 變體」。
Bring Your Own IP (BYOIP) 用於 Cloud CDN
BYOIP 讓企業從 Google 全球邊緣播報自家的公開可路由 IP 範圍（依 RFC 7039 驗證所有權），這樣即使遷移到 Cloud CDN，客戶仍會打到舊有的 IP 區段。
BYOIP 如何運作
你聯絡 Google Cloud、用授權書 (Letter of Authorization) 證明前綴所有權，Google 把該前綴加入它的公開對等播報。前綴接著變成一般 IP 位址池，可以用 gcloud compute addresses create my-byoip --addresses=203.0.113.10 --global 附加到 Global External LB 的 forwarding rule。
使用情境
- 第三方白名單裡寫死 IP 的企業。
- 併購情境下，被併購公司的網域因 SEO 與信譽考量必須留在舊 IP 上。
- 把 IP 空間當作 SLA 一部分發布給客戶的電信業者與 SaaS 廠商。
限制
- IPv4 的最小前綴為
/24，IPv6 為/48。 - Cloud CDN 的 BYOIP 僅支援 Premium 等級；該前綴會從每個 Google POP 播報。
- 因為要協調路由，佈建需要 1-4 週。
Cloud CDN 與 Cloud Armor 堆疊
Cloud Armor 安全政策附加在跟 Cloud CDN 相同的 backend service 上，但執行順序很重要，這是 PCNE 經常出現的情境。
標準 backend 安全政策
一般 Cloud Armor 政策在 LB 選好 backend 之後才評估。一旦開啟 CDN，快取命中永遠到不了政策——它們在邊緣就短路了。這對效能有利，但代表對被快取端點的速率限制規則會被繞過。
邊緣安全政策 (Edge security policy)
Edge security policy 是 Cloud Armor 為了在 Cloud CDN 快取查詢之前執行而設計的功能。用 gcloud compute security-policies create edge-policy --type=CLOUD_ARMOR_EDGE 建立，再用 gcloud compute backend-services update BACKEND --edge-security-policy=edge-policy 附加。邊緣政策被限制在規則類型的子集（IP/CIDR、地理、基本 preconfigured WAF），但它在快取查詢之前就在邊緣執行，因此可以對快取命中做速率限制或地理封鎖。
分層防禦樣式
建議的堆疊是：
- 邊緣安全政策——在快取之前封鎖被制裁國家與已知惡意 ASN。
- Cloud CDN——為合法的 99% 流量供應快取內容。
- 標準安全政策——對 cache miss 走向來源站的請求做完整 WAF（OWASP CRS、CEL 表達式、reCAPTCHA Enterprise）。
PCNE 要注意的陷阱：「如何地理封鎖使用者存取被快取的行銷頁面？」→ 答案是 邊緣安全政策，而非標準安全政策。標準政策只會抓到 cache miss 的請求；被快取的頁面仍會供應給被封鎖的地區。
白話文解釋（Plain English Explanation）
比喻 1：連鎖便利商店
想像你的來源站伺服器是位於 愛荷華州的中央倉庫。沒有 Cloud CDN 時，全世界每個客戶都要等倉庫從愛荷華出貨——東京的客戶每次載入網頁都要等 200 毫秒。Cloud CDN 就是 Google 在全球 200 多個城市開設的便利商店連鎖。第一個要求 cat.jpg 的東京客戶仍然得從愛荷華調貨，但東京分店會留一份副本，後續一萬個東京客戶就能從東京貨架上立即拿到。快取模式 決定便利商店可以擺什麼商品上架：USE_ORIGIN_HEADERS 代表只有倉庫明確貼了「零售用」標籤的商品才會上架；CACHE_ALL_STATIC 代表只要看起來像是「零售包裝」的東西都會上架；FORCE_CACHE_ALL 則是把所有東西都擺上去——包括倉庫經理的私人信件（這也是 FORCE_CACHE_ALL 會洩漏私人資料的原因）。
比喻 2：演唱會手環系統
簽署網址與簽署 Cookie 就像音樂節的手環系統。節慶入口（Cloud CDN 邊緣）不會為了每位來賓打電話回票務總部，而是用現場掃描器檢查每位來賓的手環（簽章）。簽署網址 是一次性手環，只能進入單一場演出；簽署 Cookie 是多日手環，可以進入 /main-festival/* 區域裡的每一個舞台。手環顏色每季更換——這就是三金鑰輪替。手環撕掉（簽章過期）後，你必須回票務總部（你的認證後端）買新的（重新簽署），才能再次進入。
比喻 3：餐廳的「點單收據歸檔系統」
自訂快取鍵 就像繁忙餐廳整理點單收據的規則。預設歸檔是依桌號（URL 路徑）加上人數（查詢字串）。如果工作人員把「5 號桌、4 人、週二、下雨」每一個組合都歸成不同的資料夾，櫃子很快就會爆滿。聰明的餐廳只依桌號歸檔，忽略天氣（utm_source=fb）。負向快取 是用來阻止廚房被同一份烤焦的料理連退十次後再做一次——他們會記住「烤箱壞了，接下來 10 位客人都跟他們說披薩賣完了」30 秒，同時派人去修。快取失效 則是衛生稽查員衝進來下令立即把所有收據絞碎，但聰明的餐廳早就把菜單印上版號（menu_v2.pdf），所以舊菜單會在週末結束時自然退休。
監控與可觀測性
Cloud CDN 在 Cloud Monitoring 的 loadbalancing.googleapis.com/https/ 命名空間下提供 per-backend 指標。
關鍵指標
backend_request_count{cache_result="HIT|MISS|DISABLED|UNCACHEABLE"}——驅動命中率儀表板。frontend_tcp_rtt——邊緣到客戶端 RTT，可以看出 CDN 的延遲收益。total_latencies——含 cache miss 時的快取填入在內的端對端延遲。
日誌
切換時把 HTTP(S) LB 日誌設成 --logging-sample-rate=1.0。日誌條目包含 cacheId（供應請求的 POP）以及 cacheLookup、cacheHit、cacheFillBytes。這讓你能把單一使用者抱怨對應到確切的邊緣 POP，並判斷問題是全球性還是 POP-specific。
命中率目標
健康的靜態資產工作負載命中率落在 90-99%。需登入的 API 回應命中率為 0-20%（這也沒問題——它們本來就不該被快取）。靜態內容的命中率卡在 30-50% 通常代表快取鍵裡有 UTM 雜訊、來源站缺少 Cache-Control 標頭，或者來源站送了 Vary: User-Agent（會依每種瀏覽器變體切割快取）。
成本模型與最佳化
Cloud CDN 依三個獨立維度計費，多數的成本意外都來自於誤解哪個維度主導。
快取輸出 (Cache egress)
從邊緣傳輸給客戶端的 bytes，依區域計費。北美與歐洲最便宜；大洋洲與南美洲大約是 2-3 倍。這通常是最大的支出項目。
快取填入 (Cache fill)
Cache miss 時從來源站拉到邊緣的 bytes。跨區域填入（來源站在 us-central1、填到雪梨的 POP）依跨區輸出費率計算，在低命中率的 backend 上會快速累積。
快取查詢 (Cache lookup)
每個請求收取的小額費用，hit 與 miss 都會收。對人類流量微不足道，對每秒 10 萬+次請求的 API 表面會很痛。
最佳化做法
- 先提升命中率——每個 cache hit 都把一筆
cache_fill費用換成（較便宜的）cache_egress費用。 - 靜態內容用 backend bucket；bucket-to-CDN 填入算內部流量。
- 設合理的
--max-ttl，避免設定錯誤的來源站標頭把物件永遠釘住（並膨脹快取儲存成本）。 - 只在業務需要時才用 BYOIP；標準 CDN IP 免費。
FAQs
Q: Cloud CDN 可以搭配內部負載平衡器使用嗎？
A: 不行。Cloud CDN 只能附加到 Global External Application Load Balancer（及傳統的 Global HTTPS LB）。Regional External Application LB、Internal Application LB、Network LB、TCP/SSL Proxy LB 都無法啟用 CDN。若要在 VPC 內傳遞私有內容，可以在外部 LB 終結流量後搭配 Cloud Armor + 簽署網址；影片場景則用 Media CDN。
Q: Cloud CDN 與 Media CDN 有什麼差別？
A: Cloud CDN 是搭配全球 HTTPS LB 的通用 CDN，每個物件最大 5 GB。Media CDN 是另一個獨立產品，建構在 YouTube 邊緣基礎設施上，專為超大影片檔（最大可達 TB 級）、含 manifest 操作的直播、以及 per-request DRM token 交換而最佳化。大多數網站用 Cloud CDN 即可；只有在 YouTube 等級的長影片場景才選 Media CDN。
Q: 快取失效要多久才會傳播完成？
A: Cloud CDN 失效通常在 幾分鐘 內全球完成，但 Google 並不提供硬性 SLA。失效當下仍在傳輸中的請求可能仍會收到舊物件。要做確定性的快取破除，請用版本化 URL（app.5fa1.js），不要靠失效。
Q: Cloud CDN 會尊重 Vary 標頭嗎？
A: 會，但有限制。Cloud CDN 會自動尊重 Vary 對 Accept-Encoding 與 Origin 的指定。它不支援 Vary: User-Agent 或任意 Vary 值——那些回應會直接穿透、不快取。要快取變體回應，請改用自訂快取鍵（例如 --cache-key-include-http-header=X-Device-Type）。
Q: Cloud CDN 可以搭配另一個雲的私有來源站嗎？
A: 可以。設定一個指向外部來源站主機名的 Internet NEG（gcloud compute network-endpoint-groups create my-aws-origin --network-endpoint-type=internet-fqdn-port --default-port=443），並附到啟用 --enable-cdn 的 backend service。再搭配簽署請求，讓 AWS 來源站可以驗證流量確實來自 Google CDN，而不是直接攻擊者。回流到 AWS 的 hairpin 輸出會同時產生 Google 輸出費與 AWS 輸入費，所以高命中率非常關鍵。
Q: 怎麼把已認證請求排除在快取之外？
A: 三個分層選項：(1) 在來源站對該回應設定 Cache-Control: private, no-store——除了 FORCE_CACHE_ALL 之外的所有快取模式都會生效。(2) 在 backend 上設定 --bypass-cache-on-request-headers=Authorization,Cookie，任何帶認證標頭的請求都會完全繞過快取。(3) 用 USE_ORIGIN_HEADERS 模式搭配正確的來源站標頭，讓個人化內容根本不會進入快取。
Q: 啟用 Cloud CDN 會改變我的 LB IP 位址嗎？
A: 不會。Cloud CDN 設定在 backend service 上，不在前端。你的 global forwarding rule 與它的 anycast IP 不變。這就是「為既有 LB 開啟 CDN」很安全的原因——不需要改 DNS，只要 gcloud compute backend-services update BACKEND --enable-cdn 即可。