先定義邊界，不要先拉線
開始配置 VPN 或專線以前，先把工作負載、資料與責任畫在同一張圖上。每一條跨雲資料流都應標示來源、目的地、協定、連線頻率、預估流量、敏感等級與可接受的中斷時間。AWS 與 GCP 不應被視為同一個大型區域網路；它們是兩個具有獨立身分、路由、安全控制、維運工具與計費模型的故障域。
我們通常會先定義三種邊界：信任邊界決定哪一端負責驗證、授權與加密；故障邊界說明 DNS、路由或連線中斷時由誰告警與復原；帳務邊界則指定固定線路費、流量費及共用設備如何歸屬。私有 IP 並不代表可信任，跨雲服務仍應使用 TLS，敏感的服務對服務流量可再採用雙向 TLS，並在兩端分別限制路由與防火牆規則。
工作負載的放置原則也要明確。若應用程式每個請求都要跨雲查詢資料庫，即使連線穩定，延遲、流量費與故障相依性仍會隨使用量增加。較好的做法通常是讓互動頻繁的運算與資料位於同一雲端，跨雲交換事件、批次檔案、快取結果或非同步任務，而不是把遠端資料庫當作本地服務。
依流量特性選擇連線，不只比較頻寬
連線方式應由可用性、延遲穩定度、吞吐量、加密要求與營運能力共同決定。不要因為專線看起來較正式就直接採用，也不要因 VPN 建置快速就把它當成永久解法。常見選項各自適合不同情境：
- 公開 HTTPS API：適合低至中等流量、邊界清楚的應用整合。使用服務身分、短效憑證、入口防護與明確的逾時策略，往往比維護過度複雜的私有網路更容易治理。
- 跨網際網路的高可用 IPsec VPN：適合初期上線、備援路徑或流量尚未穩定的系統。應配置不同端點與路徑的冗餘通道，並實際測試單一通道失效、BGP 收斂與封包大小。
- 電信商或合作夥伴提供的跨雲私有連線：適合持續、高流量或需要較穩定延遲的資料交換，但會增加連接埠、附件、電信商電路及維運成本。私有線路也不必然提供端到端加密。
- 資料層複寫或訊息傳遞：當需求重點是資料同步，而非任意網路互通時，可使用物件儲存複寫、事件匯流排、佇列或受控資料管線，縮小可路由範圍與故障面。
無論採用哪種方式，都要先保留不重疊的 CIDR，定義 BGP 廣告範圍與路由優先順序，避免把整個雲端網段互相公布。跨雲高可用必須同時涵蓋兩端閘道、不同可用區域或區域、電信商路徑與實體位置；只有建立兩條終止於相同設備或相同電路的通道，仍可能保留單點故障。
最常被忽略的是 DNS、回程路由與可觀測性
跨雲連線建立後，第一批問題常不是完全不通，而是偶發逾時。典型原因包括 DNS 回傳無法到達的位址、回程選到另一條路徑、MTU 不一致造成特定大小的封包失敗，或 NAT 將來源改寫後使防火牆與稽核紀錄失去辨識能力。AWS 與 GCP 的私有 DNS 區域不會因為網路接通就自動互相解析，安全群組、網路標籤與服務帳戶規則也不能直接跨供應商引用。
- 建立專用的跨雲 DNS 網域與條件式轉送規則，明確指定記錄的權威端與快取時間。
- 逐跳檢查正向與回程路由，並記錄哪一端允許公布預設路由；不要依賴未驗證的轉送或傳遞式路由。
- 測試最大封包、路徑 MTU 探索及 MSS 調整，尤其是 VPN、容器與額外安全設備並存時。
- 在兩端啟用流量記錄、VPN 或互連指標、DNS 查詢記錄及應用層追蹤，並使用共同的請求識別碼。
- 為延遲、封包遺失、隧道狀態、路由變更與跨雲流量建立告警，而不只是監看虛擬機是否存活。
上線演練應包含停用單一通道、撤回路由、停止 DNS 轉送端點及封鎖一側防火牆。觀察既有連線、重試、佇列堆積和告警是否符合預期。若只能證明正常路徑可用，還不能算完成高可用設計。
帳單邊界必須對應資源所有權與流量方向
AWS 通常以帳號與 Organizations 彙整付款，GCP 則以專案連結 Cloud Billing 帳戶；兩者並非完全對等的層級。共用網路資源可集中在專用的連線帳號或網路專案，但固定費用、附件費與資料傳出費未必都落在同一處。實際歸屬可能由連接埠、VLAN 附件、來源服務、來源區域或資源擁有者決定，因此不能只看中央網路帳號的總額。
估算跨雲成本時，至少要納入來源端資料傳出、回應方向的資料傳出、跨區域傳輸、VPN 或互連固定費、電信商電路、NAT、轉送閘道、防火牆、負載平衡、日誌儲存與監控。資料傳入經常不收取網路傳輸費，不代表整個請求只有單向成本；回應、複寫確認、重試與跨區域繞行都可能產生其他 SKU。承諾用量、Savings Plans 或折扣也不會自動跨 AWS 與 GCP 共用。
- 統一成本中心、產品、環境與擁有團隊的標籤規則，並在建立資源時強制套用。
- 啟用 AWS 詳細成本與用量資料，以及 GCP 匯出至 BigQuery 的帳務資料，再映射到同一套內部分類。
- 事先決定共用線路採固定分攤、依流量分攤，或由平台團隊吸收；不要等帳單出現才協商。
- 分別對兩個雲端設定預算、異常偵測與通知。一般預算告警不是通用的硬性支出上限。
- 每月檢查跨雲流量排名、未標記費用、跨區域路徑及閒置連線，並由網路與財務治理人員共同審閱。
成熟的混合雲設計不是讓兩個平台看起來毫無差異，而是讓每一條連線都有清楚用途、每一次故障都有負責人、每一筆費用都能追溯。若這三件事無法在架構圖與帳務報表上說清楚，就應先縮小互通範圍，再擴大部署。