簡介
在 Google Cloud 中，沒有外部 IP 的 Compute Engine VM、私有 GKE 節點、Cloud SQL 用戶端與 Dataflow 工作節點預設無法連到公共網際網路。然而，多數工作負載仍需要呼叫 Google 託管的 API，例如 storage.googleapis.com、bigquery.googleapis.com、pubsub.googleapis.com、dataflow.googleapis.com 或 logging.googleapis.com 才能完成工作。私有 Google 存取 (Private Google Access，PGA) 就是一整套功能集，讓這些原本與外網隔絕的資源能透過 Google 內部骨幹網路、只使用內部 IP 抵達 Google API，既不經過公共網際網路，也不需要外部 NAT，更不會損失私有子網路的安全姿態。
PGA 並非單一功能，而是分層系統，含四種類型：給 VM 執行個體使用的 PGA（子網路旗標）、給地端主機使用的 PGA（透過 Cloud VPN 或 Interconnect 的混合架構）、用於強制執行 VPC Service Controls（VPC-SC）的 199.36.153.4/30 Restricted VIP，以及較新的 Private Service Connect (PSC) Google API 端點，可指派您自己的內部 IP 給 API 介面。每種類型使用不同的 VIP 區段、不同的 DNS 設定、不同的路由技巧。本研讀筆記會走過每一種類型、Google 公告的 199.36.153.0/24 子網路前綴、必須建立的 Cloud DNS 管理區、0.0.0.0/0 全拒絕加上精準 /30 放行的路由模式、混合情境中 Cloud Router 的 BGP 廣告，以及 PSC for Google APIs 與傳統 PGA 的差異，內容足以應付 PCNE 考綱中任何關於 Google 服務私有連線的題目。
VM 的 PGA：子網路啟用旗標
子網路旗標的實際作用
給 VM 執行個體使用的私有 Google 存取，只需在每個子網路上設定一個布林值就能啟用：透過 gcloud compute networks subnets update SUBNET --region=REGION --enable-private-ip-google-access，或在主控台勾選 私有 Google 存取：開啟。當旗標開啟後，該子網路內只擁有內部主要 IP 或別名 IP 的 VM，可以把封包送向任何 Google API 的公共 IP 區段（例如 storage.googleapis.com），主機上的 Andromeda 資料平面會把這些封包視為網內流量。即使來源是 RFC1918 私有位址，Google 的邊緣仍會接受，因為 Google 能驗證封包來自真實 Google Cloud 專案中已啟用 PGA 的子網路。
適用條件
PGA 只在 VM 該網路介面沒有外部 IPv4 位址時生效。一台同時掛有暫時性外部 IP 的雙堆疊 VM 會優先從外部 IP 出去，忽略 PGA 旗標，因為核心路由表偏好擁有預設網際網路閘道路由的介面。別名 IP 區段會繼承子網路的 PGA 設定，因此私有節點上的 GKE Pod 只要節點子網路啟用 PGA，就能自動取得 PGA。PGA 範圍是 per-region、per-VPC，作用於子網路主要 CIDR 與其別名範圍。
費用與限制
啟用 PGA 不收費，您只需支付標準的 Google API 流量費用與服務端的資料處理費。PGA 沒有獨立於 VM 出向頻寬以外的吞吐量上限，也不會佔用 Cloud NAT 連接埠或 NAT IP 配額。所有 Google Cloud 區域與所有 VPC 類型都支援這項功能，包括傳統網路、自訂模式 VPC，以及 Shared VPC 服務專案。
給 VM 執行個體的私有 Google 存取是子網路層級的布林，以 --enable-private-ip-google-access 啟用。只有當 VM 該介面沒有外部 IPv4 時才生效；需要 VPC 中存在 0.0.0.0/0 預設路由（next-hop 為 default-internet-gateway，自訂模式 VPC 預設就有）；除標準 Google API 流量費以外不收任何額外費用。以 gcloud compute networks subnets describe SUBNET --region=REGION --format="value(privateIpGoogleAccess)" 確認狀態。
兩個 Google API VIP 區段
private.googleapis.com 對應 199.36.153.8/30
Google 公告了一個 199.36.153.8/30（四個位址）的公共 VIP 區段，DNS 名稱為 private.googleapis.com，可服務所有受支援的 Google API。這個區段只在 Google 內部骨幹中宣告，即使位址屬於 IANA 配給的公共範圍，在公共網際網路上仍然不可達。已啟用 PGA 的子網路內，VM 可以透過這四個 IP 抵達任何 Google API；同一個區段也用在混合 PGA：當您把地端流量透過 Cloud VPN 或 Interconnect 路由進 Google。請把 199.36.153.8/30 視為「私有路徑直達所有 Google API」的標準目的地。
restricted.googleapis.com 對應 199.36.153.4/30
第二個相鄰前綴 199.36.153.4/30 對應 DNS 名稱 restricted.googleapis.com，只服務那些與 VPC Service Controls 整合、列為受支援服務的 Google API。當組織政策或服務範圍周界禁止資料外洩時，必須使用 Restricted VIP：任何打到一般 *.googleapis.com 公共 IP 的呼叫都會被拒絕，只有打到 199.36.153.4/30 的流量才會被接受，後續由 VPC-SC 強制執行周界規則。可經由 Restricted VIP 呼叫的服務名單是公告過的子集（特別是 Cloud Storage、BigQuery、Pub/Sub、Spanner、Dataflow、AI Platform、KMS、Logging、Monitoring），不包含部分無法納入周界的服務，例如 compute.googleapis.com 的管理端點。
挑選正確的 VIP
對於不受 VPC-SC 周界拘束的工作負載，使用 private.googleapis.com（199.36.153.8/30）。對於周界內的工作負載或任何追求嚴格資料外洩防護的架構，使用 restricted.googleapis.com（199.36.153.4/30）並搭配列出範圍內專案與服務的周界。如果不同子網路或不同地端區段需要不同政策，您可以在同一個 VPC 中同時設定兩個區段，因為它們是兩個獨立的 /30，DNS 解析會依查詢的主機名挑選對應的 VIP。
Restricted VIP 是 199.36.153.4/30 這組 IP 範圍，背後對應 DNS 名稱 restricted.googleapis.com。它只暴露受 VPC Service Controls 支援的 Google API，並強迫用戶端進入 VPC-SC 周界，可封鎖受監管資料外洩到消費級專案、公共儲存桶或周界外的專案。
用 Cloud DNS 管理區進行 DNS 設定
為何 DNS 是關鍵
PGA VIP 只有在您的用戶端把 *.googleapis.com 主機名解析到 199.36.153.8/30 或 199.36.153.4/30 時才會生效。公共 DNS 會把 storage.googleapis.com 解析成一般的全球 anycast 公共 IP，沒有任何 PGA 特殊語意。要強制走私有路徑，您必須建立一個 Cloud DNS 私有管理區，覆寫 googleapis.com 與其關鍵子網域的解析，回傳 VIP 位址。
private.googleapis.com 的區設定
標準模式是建立一個 Cloud DNS 私有區，網域為 googleapis.com.，內含：頂點 googleapis.com. 的 A 記錄指向 199.36.153.8、199.36.153.9、199.36.153.10、199.36.153.11 四個 IP；以及 *.googleapis.com. 的 CNAME 指向 private.googleapis.com.。如此一來，每個 Google API 主機名（storage、bigquery、pubsub 等）都會先進到頂點，再解析到 VIP /30。指令為 gcloud dns managed-zones create googleapis --visibility=private --networks=prod-vpc --dns-name=googleapis.com.，後續再以記錄集交易加上 A 與 CNAME 條目。
restricted.googleapis.com 的區設定
若使用 VPC-SC，則頂點 googleapis.com. 的 A 記錄改指向 199.36.153.4、199.36.153.5、199.36.153.6、199.36.153.7，而萬用 CNAME *.googleapis.com. 指向 restricted.googleapis.com.。結構完全相同，只是目標 VIP 不同。在承載周界化工作負載的 VPC 中，請偏好使用 restricted 設定，讓 VM 的每一次 Google API 呼叫都被導入 VPC-SC。
額外主機名
除了頂點區，部分服務還需要額外條目。Container Registry 與 Artifact Registry 需要把 gcr.io、pkg.dev、*.gcr.io、*.pkg.dev 用 CNAME 指向同一個 VIP。部分舊服務還需要 *.appspot.com。在假設只設 googleapis.com 頂點區就足夠之前，請務必對照當前 Google 文件的支援網域清單。
建立 Cloud DNS 私有區時，請把它附掛到每一個需要覆寫的 VPC（使用 --networks=vpc1,vpc2,...）。Shared VPC 主機專案中的私有區，附掛的服務專案會自動可見；但獨立 VPC 各自要附掛一次。漏掉這步，服務專案中的 VM 仍會把 storage.googleapis.com 解析到公共 IP，從而繞過 PGA。
路由：0.0.0.0/0 全拒絕加上 /30 放行模式
預設路由的重要性
給 VM 的 PGA 需要 VPC 中存在一條 0.0.0.0/0、next-hop 為 default-internet-gateway 的路由；這條路由不必是可用的（可以在上層疊一條 deny 防火牆），但必須存在，因為主機核心才會嘗試轉送。自訂模式 VPC 預設帶這條路由；自動模式 VPC 也是。這條路由的存在是前置條件，不是實際的資料路徑，因為真正的 PGA 轉送發生在 Andromeda 內部，封包根本還沒到任何網際網路閘道。
用 deny-all-egress 防火牆強化
在高安全性設計中，會建立一條低優先序（例如 65000）的 egress deny 防火牆規則 0.0.0.0/0，再疊一條較高優先序的 egress allow 規則，僅允許指定的 VIP /30（199.36.153.4/30 或 199.36.153.8/30）加上您的 RFC1918 私有區段。如此一來，即使 DNS 設定錯誤把名稱解到公共 IP，防火牆仍會擋掉任何往公共網際網路的逃逸，只允許文件化的 PGA VIP。
混合 PGA 的自訂靜態路由
對地端 PGA 而言，無法仰賴 default-internet-gateway，因為地端用戶端是透過 Cloud VPN 或 Interconnect 抵達 Google，而非經由網際網路出向。標準做法是在 VPC 中建立一條 自訂靜態路由，目的地為 199.36.153.4/30（或 .8/30），next-hop 為 default-internet-gateway，讓由地端進入、目的為 VIP 的流量交給 Google 邊緣處理。指令為 gcloud compute routes create private-googleapis --network=hub-vpc --destination-range=199.36.153.8/30 --next-hop-gateway=default-internet-gateway。
VPC 內必須存在一條目的地為 199.36.153.4/30 或 199.36.153.8/30、next-hop 為 default-internet-gateway 的路由。少了這條路由，即使用戶端 DNS 設定正確也到不了 VIP，因為封包在 Google 邊緣沒有回 Andromeda 的回程路徑。再疊上「deny-all-egress + 精準放行」防火牆模式，即可確保其他公共目的地都不可達，達成預設私有的姿態。
地端主機的私有 Google 存取
混合架構使用情境
透過 Cloud VPN 或 Cloud Interconnect 連到 Google Cloud 的資料中心或分公司，經常需要從地端伺服器直接呼叫 Google API，而不是透過 Google Cloud VM 代理轉送。地端 PGA 讓這變得可行：地端用戶端透過地端 DNS（轉送到 Cloud DNS 或有自己的覆寫區）把 *.googleapis.com 解析到 199.36.153.8/30，封包透過 VPN 或 Interconnect 隧道送入 Google Cloud，VPC 依自訂靜態路由把封包交給 default-internet-gateway，Google 邊緣把這條流量視為符合 PGA 資格，因為來源 IP 屬於 VPC 已宣告可達的地端範圍。
從地端 DNS 轉送到 Cloud DNS
地端 DNS 必須把 googleapis.com 與相關網域解析到 VIP /30。最乾淨的模式是讓地端 DNS 轉送器指向掛在 hub VPC 上的 Cloud DNS inbound forwarding 政策：以 gcloud dns policies create dns-policy --networks=hub-vpc --enable-inbound-forwarding 建立政策，記下 Cloud DNS 配給的區域內向轉送器 IP，然後設定地端解析器把 googleapis.com 查詢轉發到這些 IP。Cloud DNS 接著評估先前建立的私有管理區，回傳 199.36.153.8/30（或 .4/30）給地端用戶端。
跨混合鏈路的路由
地端網路必須有一條目的地為 199.36.153.8/30（或 .4/30）的路由，next-hop 為連往 Google Cloud VPC 的 Cloud VPN 隧道或 VLAN attachment。在 GCP 端，hub VPC 內前述的靜態路由把流量交給 default-internet-gateway。若使用 HA VPN + BGP，只要設定好自訂路由廣告（下一節說明），Cloud Router 會自動把 VIP 區段廣告給地端對端。若使用靜態路由，則需在地端與 GCP 兩側各手動建立靜態路由。
來源 IP 的考量
地端來源 IP 必須屬於 VPC 知道如何回程的範圍。使用 HA VPN + BGP 時，Cloud Router 透過 BGP 學到地端前綴，自動安裝回程路由。使用 Cloud Interconnect 加 Partner Interconnect 時，VLAN attachment 上同一個 BGP 工作階段提供回程路徑。若缺少回程路徑，Google 邊緣會接受進入的 API 呼叫，但回應封包回不到地端用戶端，連線會逾時，是一種極度令人困惑的故障模式。
常見錯誤是啟用了 Cloud DNS 內向轉送，卻忘記把地端前綴經由 BGP 廣告回 Google Cloud。DNS 查詢成功（因為轉送有運作），但實際 API 呼叫卡住，因為 Cloud Router 沒有回到地端 IP 的路徑。配置地端 PGA 時，務必同時用 gcloud compute routers get-status 確認 BGP 雙向交換正常。
混合 PGA 在 Cloud Router 上的 BGP 廣告
自訂路由廣告
Cloud Router 可被指示廣告 VPC 已附掛子網路以外的額外前綴給 BGP 對端。要讓混合 PGA 乾淨運作，您廣告 199.36.153.8/30（或 .4/30），讓地端路由器動態學到該路由並把 next-hop 安裝為 VPN 或 Interconnect 隧道。指令為 gcloud compute routers update-bgp-peer PEER --router=ROUTER --region=REGION --advertised-route-priority=100 --custom-learned-route-priority=100 --advertisement-mode=custom --set-advertisement-ranges=199.36.153.8/30。
預設與自訂廣告模式
Cloud Router 預設使用 default 廣告模式，會宣告 VPC 中所有子網路，但不會宣告 VIP 自訂靜態路由。切換到 custom 模式後，您必須明確列出所有想廣告的內容，包括先前免費獲得的 VPC 子網路。代價是明確控制換取營運簡潔。對於有 PGA 的生產級 hub-and-spoke 拓撲，建議使用 custom 模式，因為您通常想廣告 VIP 區段加上部分子網路，把內部專用範圍隱藏起來不讓地端看到。
驗證 BGP 健康狀態
執行 gcloud compute routers get-status ROUTER --region=REGION，在 bgpPeerStatus 區段中確認 BGP 工作階段為 Established、廣告的路由包含 199.36.153.8/30、學到的路由包含您的地端範圍。如果工作階段震盪或廣告遺漏，地端 PGA 路徑會以連線逾時的形式靜默失敗，若不直接檢查 BGP，會非常難診斷。
每對端的廣告精細度
Cloud Router 支援每對端各自覆寫廣告，所以一台 Cloud Router 連到兩個 BGP 對端時，可以對其中一個（生產資料中心）廣告 PGA VIP，對另一個（DMZ 分公司）保留不廣告。每個對端各自設定 --peer-advertisement-mode=custom。當企業版圖中只有一部分被允許私下抵達 Google API 時，請使用這個方式。
混合 PGA 從頭到尾需要五件事：(1) 回傳 VIP /30 的 Cloud DNS 私有區、(2) 有配發轉送器 IP 的 Cloud DNS 內向轉送政策、(3) 指向那些 IP 的地端 DNS 轉送器、(4) VPC 中目的為 199.36.153.8/30、next-hop 為 default-internet-gateway 的自訂靜態路由、(5) Cloud Router 對地端 BGP 對端的同一 /30 自訂廣告。少了任何一項，路徑就斷。
Private Service Connect for Google APIs（PGA 的替代方案）
PSC for Google APIs 的作用
Private Service Connect for Google APIs 是傳統 PGA 的現代後繼者。它不再透過私有路徑廣告一個固定的、長得像公共的 VIP /30，而是讓您在自己的 VPC 內配發一個自己的內部 IP，並把它當作 Google API 的端點。用戶端呼叫 storage.googleapis.com（或您自訂的主機名），DNS 解析到您指派的內部 IP，例如 10.10.0.100。從用戶端視角看，流量根本沒離開 VPC 子網路。
何時選 PSC 而非傳統 PGA
當您希望整段都是 RFC1918 編址（日誌中不要出現 199.36.153.x 半公共範圍）、當您有多個 VPC、每個都需要專屬端點 IP、或需要把更精細的防火牆或 VPC-SC 規則綁到特定內部 IP 時，請選 PSC。當您想要最簡單的設定、不想多管理一組端點資源、或希望地端混合用戶端共用同一條路徑時，請選傳統 PGA。
為 Google API 建立 PSC 端點
先保留一個區域性內部位址，再建立轉送規則指向 all-apis 或 vpc-sc 套件：gcloud compute addresses create psc-googleapis --region=REGION --subnet=SUBNET --addresses=10.10.0.100，接著 gcloud compute forwarding-rules create psc-googleapis --region=REGION --network=VPC --address=10.10.0.100 --target-google-apis-bundle=all-apis。all-apis 套件相當於 private.googleapis.com；vpc-sc 套件相當於 restricted.googleapis.com 並強制執行 VPC-SC。
PSC 的 DNS
您仍需要一個私有 DNS 區，只是它指向您的內部 IP 而非 VIP /30。典型區設定為：A 記錄 googleapis.com. 10.10.0.100，加上 CNAME *.googleapis.com. googleapis.com.。把 10.10.0.100 換成您保留的位址。同樣的地端 DNS 轉送模式仍然有效，地端用戶端可透過 VPN 或 Interconnect 抵達端點，因為 10.10.0.100 就只是您 VPC 中的內部 IP。
Private Service Connect for Google APIs 使用套件：--target-google-apis-bundle=all-apis 是 private.googleapis.com 的 PSC 對應，--target-google-apis-bundle=vpc-sc 是 restricted.googleapis.com 的 PSC 對應。請依您的工作負載是否在 VPC Service Controls 周界內挑選套件；單一端點不支援把兩種套件混用。
常見故障模式與排查
症狀：VM 沒有外部 IP 仍連不上 Google API
先用 gcloud compute networks subnets describe SUBNET --region=REGION --format="value(privateIpGoogleAccess)" 檢查。若為 false，旗標未開，即使 DNS 指向公共 IP，呼叫仍會在 Google 邊緣被丟棄。開啟旗標重試。若為 true 但仍失敗，檢查 VM 是否帶有外部 IP（會覆寫 PGA），以及 VPC 中 0.0.0.0/0 預設路由是否仍存在。
症狀：API 可達但 VPC-SC 拒絕存取
這通常代表用戶端打到了 storage.googleapis.com 的公共 IP，而非 Restricted VIP。VPC-SC 周界必須使用 restricted.googleapis.com（199.36.153.4/30）才會強制執行；走 199.36.153.8/30 的一般 PGA 路徑會繞過周界。修正 Cloud DNS 私有區改指向 restricted /30，並在 VM 上以 dig +short storage.googleapis.com @169.254.169.254 確認。
症狀：地端用戶端逾時
依序檢查三件事：(1) 地端主機上 dig storage.googleapis.com 回傳 199.36.153.x、(2) 從地端 traceroute 停在 Cloud VPN 隧道而非公共網際網路節點、(3) Cloud Router BGP 狀態顯示 VIP /30 已廣告且地端前綴已學到。任一環節失敗都會讓路徑中斷。
症狀：DNS 正常但防火牆封鎖
deny-all-egress 防火牆必須明確允許往 199.36.153.4/30 或 199.36.153.8/30 的 TCP 443 流量。用 gcloud compute firewall-rules list --filter="network=VPC" --format="table(name,direction,destinationRanges,sourceRanges,allowed)" 確認，缺少時請補上較高優先序的 allow 規則。
使用 連線測試 (Connectivity Tests) (gcloud network-management connectivity-tests create)，把來源設為 VM 內部 IP、目的地設為 199.36.153.10 TCP 443，可端對端驗證整條轉送路徑。測試會針對真實 VPC 設定（路由、防火牆、PGA 旗標）模擬封包，不會送出真實流量，是定位 PGA 失靈位置最快的方法。
白話文解釋
比喻一：大使館地下通道
想像您的 VM 是住在私人封閉社區（VPC）裡的居民，社區沒有對外大門（沒有外部 IP）。居民需要到外國大使館（Google API，例如 Cloud Storage）拿文件。沒有私有 Google 存取時，唯一路徑是從社區大門（Cloud NAT）走出去到公共街道，會曝光居民身分。有了 PGA，社區管理員蓋了一條直通大使館後門 199.36.153.8/30 的私人地下通道。居民只靠內部通行證（內部 IP）穿過通道，從不出現在公共街道；大使館因為通道從一個被認可的外交大院（已啟用 PGA 的子網路）冒出來，所以接受訪問。
比喻二：VIP 會員入口 vs 公眾櫃台
Cloud Storage 有兩道門。公眾櫃台（storage.googleapis.com 的公共 IP）是任何人從網際網路帶著護照（API 金鑰或 OAuth 權杖）排隊的地方。199.36.153.8/30 的 VIP 入口（private.googleapis.com）需要一張寫著「我從 Google Cloud 內部或經認可的隧道而來」的特別卡。第三道更尊榮的 VIP 入口 199.36.153.4/30（restricted.googleapis.com）只接待 VPC Service Controls 會員：只放行名單上預先核可的會員，並禁止他們把資料攜出到非會員俱樂部。選錯門的後果，要麼被公眾看到（PGA 沒開），要麼被擋在門外（VPC-SC 周界要 restricted 您卻用了 regular）。
比喻三：長途電話轉接卡
地端混合 PGA 可想像為公司舊時的電話總機。分公司辦公室（地端）想撥電話給 Google API 服務。公司電話簿（地端 DNS）已更新為：每當有人撥「storage.googleapis.com」時，其實撥的是內線分機 199.36.153.10。總機（Cloud VPN 隧道）把這通電話接到 Google Cloud 總部（hub VPC）。總部接線生有一張自訂路由卡（指向 default-internet-gateway 的靜態路由），知道「目的為 199.36.153.8/30 的電話走外交線而非公共街道」。回程電話沿同一條總機回去，因為 Cloud Router 已透過 BGP 廣告了路由，分公司知道往哪裡發送回覆。少了 BGP 這一步，回覆就消失在虛空中。
PCNE 專屬考試陷阱
把 PGA 和 Cloud NAT 搞混
PCNE 題目特別愛測「考生是否知道 PGA 與 Cloud NAT 解決不同問題」。PGA 讓只有內部 IP 的 VM 連到 Google API。Cloud NAT 讓只有內部 IP 的 VM 連到 一般網際網路。兩者獨立：一台 VM 可以同時啟用 PGA（子網路旗標）並用 Cloud NAT 處理非 Google 流量。若題目是「VM 沒有外部 IP，要從 apt.example.com 下載 Linux 套件」，答案是 Cloud NAT，不是 PGA；若題目是「VM 沒有外部 IP，要寫資料到 GCS bucket」，答案是 PGA。
把兩個 VIP /30 搞混
199.36.153.4/30 是 restricted（四個 IP：.4、.5、.6、.7）；199.36.153.8/30 是 private（四個 IP：.8、.9、.10、.11）。相鄰是刻意設計，但語意不同：restricted 強制 VPC-SC，private 不會。請把較低範圍記為 restricted、較高範圍記為 private。部分 PCNE 題目只給其中一個範圍，要求您判斷它對應哪個功能。
忘了混合情境的 Cloud DNS 內向轉送
許多考生正確指出地端 PGA 需要 DNS 覆寫，卻忘了覆寫是經由 Cloud DNS 內向轉送政策 配發的轉送器 IP 提供，而非直接手動改地端區檔。流程是：地端解析器 -> Cloud DNS 內向轉送器 IP（由 gcloud dns policies create --enable-inbound-forwarding 配發）-> googleapis.com. 私有管理區。漏掉政策這一步是常見的錯誤答案。
PSC for Google APIs 與已發佈服務 PSC
PSC 有兩種：PSC for Google APIs（本研讀筆記主題），與 PSC for published services（用於暴露內部服務）。PCNE 考綱問的是前者；後者是消費者 VPC 與生產者 VPC 之間的點對點模式。請勿混淆。--target-google-apis-bundle 旗標用來區分 API 那一種。
常見問題
在子網路上啟用 PGA 要付費嗎？
不用。子網路旗標本身免費。您只需支付正常的資料輸出費用以及呼叫 Google API 的服務費用。PGA 不會佔用 Cloud NAT 連接埠、不需要保留 IP、也沒有每小時閘道費用，這是它優於把 API 流量導入 Cloud NAT 的原因之一。
PGA 可以搭配 Shared VPC 嗎？
可以。PGA 在 Shared VPC 主機專案的子網路上設定。透過 Shared VPC 消費該子網路的服務專案會自動繼承 PGA 設定。Cloud DNS 私有區應在主機專案建立並附掛到主機專案 VPC；服務專案的 VM 會透明地看到該區。這是集中式連線團隊的標準模式。
PGA 可以搭配 GKE 私有叢集嗎？
可以，而且是建議的模式。私有 GKE 節點預設只有內部 IP；在節點子網路啟用 PGA 後，節點即可從 gcr.io 與 pkg.dev 拉取映像、把日誌推送到 logging.googleapis.com、呼叫任何其他 Google API，全程不需 Cloud NAT。請確保 Cloud DNS 私有區除了 googleapis.com 之外，也涵蓋 gcr.io、*.gcr.io、pkg.dev、*.pkg.dev。
若我的 VM 有公開 IP，PGA 還會生效嗎？
不會。網路介面上有任何外部 IPv4 都會繞過 PGA：主機核心會走外部 IP 路由，因為該介面有直接的網際網路出口，Google 邊緣看到的就是普通的公共網際網路呼叫。要強制使用 PGA，必須移除外部 IP，並確保 DNS 把 *.googleapis.com 解析到 VIP /30，並確認出向防火牆允許 TCP 443 到該 /30。
地端主機可以不用 Cloud DNS 內向轉送器就使用 PGA 嗎？
技術上可以，只要您在地端 DNS 伺服器的本地區檔中硬寫 VIP /30 的解析。但這做法脆弱：必須在每一台地端解析器都維護覆寫，並失去 Cloud DNS 提供的集中視野。建議路徑永遠是 Cloud DNS 私有區搭配內向轉送政策，地端解析器把 googleapis.com（以及其他）轉送到配發的 Cloud DNS 轉送器 IP。
PGA 與 Private Service Connect for Google APIs 有何不同？
傳統 PGA 使用半公共的 VIP /30（199.36.153.4/30 與 199.36.153.8/30），靠子網路旗標加上 DNS 覆寫啟用。PSC for Google APIs 則使用您挑選的內部 IP（例如 10.10.0.100），透過區域性轉送規則綁定 --target-google-apis-bundle=all-apis 或 vpc-sc。PSC 是較新的模式；它給您整段 RFC1918 編址，每個 VPC 一個端點，對於多 VPC 拓撲更乾淨。兩者皆為 PCNE 的有效答案，視題目要求而定。
PGA 流量會經過公共網際網路嗎？
不會。PGA 流量從離開主機 Andromeda 虛擬交換器到抵達 Google API 前端，都待在 Google 私有骨幹內。199.36.153.0/24 中的公共 IP 只是管理性使用：Google 全球公告這些位址，是為了讓具備 PGA 認知的用戶端（包括透過 VPN 或 Interconnect 的地端用戶端）有一個無歧義的 DNS 目標，但封包實際上從未走過公共網際網路路徑。