AWS–Azure 多雲專線進入預覽：代理出口團隊需要重新驗證什麼
Amazon Web Services 於 2026 年 8 月 31 日宣布，AWS Interconnect – multicloud 與 Microsoft Azure 的連線進入公開預覽。這項受管服務旨在按需提供兩個雲端環境之間的專用私有頻寬，讓客戶不必自行安排實體線路。
對於使用代理執行合規資料蒐集、市場研究、廣告驗證或區域測試的團隊，這項變化主要發生在網路路徑中段，並不會減少出口端所需的證據。私有雲間連線可簡化傳輸並提高韌性，但不會自動證明公共出口由哪個雲承載、工作是否經過指定代理、TLS 在何處終止，或故障時是否發生直接網際網路回退。
AWS 公布了什麼
AWS 將此次預覽描述為 AWS 與 Azure 之間的按需私有連線模式。Azure 預覽首批涵蓋美國東部（北維吉尼亞）、美國西部（北加州）、亞太（雪梨）與歐洲（法蘭克福）。
服務會在實體分離的設施與路由器上配置四條獨立邏輯路徑。AWS 表示，這種四重備援設計旨在路由器維護與多個獨立中斷時繼續承載流量，包括整個站點失效的情境。
AWS 也說明，兩家雲端服務商邊緣路由器之間使用 MACsec 保護傳輸，並包含 Network Synthetic Monitor，協助發現封包遺失並判斷問題是否來自 AWS 一側。
這些是有價值的基礎設施能力，但不能取代應用層控制與面向特定代理工作的驗證。
重畫完整出口路徑
多雲代理路由可能包含：
- 來源雲中的工作負載程序；
- 來源子網路、虛擬網路與內部安全控制；
- 私有多雲互聯；
- 目的雲虛擬網路或檢查層；
- NAT、防火牆或明確代理設定；
- 商業代理閘道；
- 實際代理出口；
- 已授權公共目標。
為每一跳記錄路由擁有者、加密機制、DNS 解析器、來源位址轉換、監控訊號與故障行為。明確標出私有互聯保護結束、公共代理區段開始的位置。
不能因為存在私有雲間鏈路，就宣稱完整代理交易都是私有的。
明確公共出口由哪個雲負責
架構必須為每個工作負載回答：
- AWS 工作負載是否先到 Azure，再連線代理閘道？
- Azure 工作負載是否先到 AWS，接受集中檢查與出口控制？
- 兩個雲是否都允許獨立出口？
- 正常狀態下哪條路徑優先？
- 私有鏈路受損時會發生什麼？
- 預設路由能否繞過檢查層或代理？
路由表、動態路由、防火牆規則、私有 DNS 與代理環境變數可能互相衝突。必須從應用程式實際驗證有效路徑，不能只查看架構圖。
MACsec 有明確邊界
AWS 描述的是兩家服務商邊緣路由器之間的 MACsec。它保護互聯區段，但不等同於應用程式到代理、或應用程式到目標的 TLS。
使用 HTTPS 代理閘道時，仍需驗證：
- 應用程式連線至預期代理主機名稱；
- 憑證鏈與主機名稱驗證已啟用；
- 協商的是核准 TLS 政策；
- 代理驗證失敗時關閉連線；
- CONNECT 行為符合產品設計；
- 離開互聯區段後的流量仍按要求受到保護；
- 憑證不會進入流量日誌、終端輸出或支援資料。
對 SOCKS5 而言，路由與加密是兩件事。SOCKS5 本身不會加密應用負載。
重新驗證 DNS
工作負載經過私有多雲互聯後，代理閘道名稱所使用的解析器與回傳位址都可能改變。需要測試：
- 兩個雲各自使用哪個解析器；
- 分割視圖或私有區域行為；
- A 與 AAAA 結果；
- 路由變更期間的快取生命週期；
- 受支援 SOCKS 設定的遠端 DNS 行為；
- 舊快取是否指向不可達或非預期閘道。
記錄解析器與結果類別時，不要保存無關客戶資料或完整敏感目標資訊。
測試四類故障
四條邏輯互聯路徑提升基礎設施韌性，但代理工作還有其他故障層。
互聯受損
觀察單一路徑、路由器或站點無法使用時的路由收斂、工作中斷、封包遺失、連線重設與復原時間。
檢查或出口故障
關閉受控的防火牆、NAT 或代理金絲雀，證明流量不會悄悄改走直連。
商業代理故障
模擬閘道逾時、驗證拒絕與 TLS 驗證失敗。重試必須有上限，也不能切換到未核准的直接連線。
目標回應變化
區分網路故障與目標限流、存取規則和內容變化。快速返回的封鎖頁不是成功路由。
關聯基礎設施與應用證據
Network Synthetic Monitor 可協助定位 AWS 一側的封包遺失，但代理事件記錄還應包含：
operation_id
source_cloud
source_region
intended_egress_cloud
interconnect_path_state
proxy_gateway_alias
proxy_route_verified
direct_fallback_blocked
tls_validation_result
observed_exit_market
first_attempt_result
retry_count
total_latency_ms使用別名與去識別化標記。日常遙測不得包含密碼、權杖、Cookie、個人資料或完整敏感 URL。
建立預覽驗收門檻
將預覽用於正式代理路徑之前，應完成受控評估：
- 所需來源與目的區域均受支援；
- 每個工作負載都有明確正常出口路徑；
- 從應用程式實際驗證路由優先順序；
- 已記錄互聯加密邊界；
- 代理 TLS 與目標 TLS 分開測試；
- 兩個雲的 DNS 結果均已驗證；
- 同時使用 IPv4 與 IPv6 時分開測試；
- 已觀察單一路徑、路由器與站點受損情境；
- 代理、NAT 與檢查層故障不會產生直連回退；
- 監控能把基礎設施遺失與應用結果關聯；
- 延遲、首試成功率與成本達到門檻；
- 團隊擁有核准的回復路徑。
由於 Azure 連線仍處於公開預覽，關鍵流量使用前必須確認最新區域、容量、支援與可用性條件。
營運檢查清單
- [ ] 已繪製從來源到目標的完整代理路徑。
- [ ] 每個工作負載的公共出口歸屬明確。
- [ ] 私有互聯與公共網際網路區段沒有混為一談。
- [ ] MACsec 與 TLS 邊界分別記錄。
- [ ] 從應用程式驗證實際路由。
- [ ] 在兩個雲檢查 DNS 行為。
- [ ] 代理憑證不會進入診斷資料。
- [ ] 已阻擋並測試直接回退。
- [ ] 故障切換期間重試上限仍有效。
- [ ] 路由變更後重新驗證出口市場與內容。
- [ ] 基礎設施與應用遙測共享關聯標記。
- [ ] 已記錄預覽限制與回復方案。
可繼續閱讀 98IP 的代理故障切換復原演練、代理服務 SLA 驗證手冊與代理位置準確性檢查指南。
常見問題
AWS–Azure 多雲互聯會取代代理服務嗎？
不會。它提供雲端環境之間的私有連線。網際網路出口、過濾、商業代理選擇與目標存取仍是獨立架構決策。
MACsec 是否讓公共代理連線端到端加密？
不會。AWS 描述的是服務商邊緣路由器之間的 MACsec。應用 TLS 與代理到目標區段仍需獨立驗證。
四條互聯路徑能避免所有代理故障嗎？
不能。它們主要提高互聯韌性。DNS、路由、防火牆、NAT、代理閘道、驗證、TLS 與目標故障仍可能發生。
故障時應該直接切換到公共網際網路嗎？
除非此行為經過明確授權與設計，否則不應該。對強制代理工作，通常應阻擋並測試直連回退。
合規說明
僅將多雲與代理基礎設施用於合法、已授權的工作。遵守目標條款、robots 指示、隱私義務、同意要求與限流。私有連線與加密不會賦予存取受限系統的權限。不得利用故障切換、替代雲或代理輪換規避存取決定。
來源說明：Amazon Web Services，《AWS and Microsoft Azure collaborate to expand multicloud networking》，發布於 2026 年 8 月 31 日。
