本指南為連接 Azure 與 Amazon Web Services（AWS）、Google Cloud 或從其他雲端供應商遷移工作負載的客戶，提供 Azure 網路設計指南的順序閱讀路徑。 遵循這些編號步驟，設計 Azure 與現有雲端基礎設施之間安全且受監控的連接。
為什麼發現優先
跨雲網路將 Azure 連接到一個或多個外部雲端環境。 你可能會在 AWS 或 Google Cloud 執行需要私有連接 Azure 服務的工作負載，或者你可能會將應用程式從其他雲端遷移到 Azure，同時保留與留在後方的應用程式的連接。 無論如何，你的 Azure 網路必須與你無法完全控制的基礎設施整合。
這條閱讀路徑從發現開始，而非 Azure 基礎架構設計。 你先繪製現有的多雲拓撲（了解哪些拓撲在哪裡運行、如何連接，以及雲端間流量流動），再設計 Azure 端。 這種以發現為先的方法避免了重做：如果你在不了解 AWS 或 Google Cloud 拓撲的情況下設計 Azure 網路，就有可能出現 IP 位址衝突、連線缺口和安全盲點。
你的目標架構使用 Azure 虛擬廣域網（WAN）作為中轉樞紐（Azure 上的 AWS Transit Gateway），並透過 IPSec VPN 隧道連接 AWS 虛擬私人閘道和 Google Cloud VPN。 Azure 防火牆 在安全的虛擬中樞中會檢查所有跨雲及分支流量。 DNS 需要審慎規劃切換作業，以確保在遷移期間，名稱解析在跨雲端邊界時仍能正常運作。
先決條件
- 閱讀 Azure 網路計畫與設計概述，了解可用的 Azure 網路服務。
- 完整的 AWS 與 Google Cloud 環境拓撲發現：
- AWS：在 AWS 上執行 AWS Migration Hub 或 AWS 上的 Workload Discovery，以盤點虛擬私有雲（VPC）、Transit Gateway，以及 VPC 之間的連線。
- Google Cloud：使用 Network Intelligence Center 來映射 VPC 網路、雲端互連附件及防火牆規則。
- 記錄跨雲流量流：哪些應用程式在雲端間通訊、所需頻寬、延遲敏感度及加密需求。
- 建立三個雲端的 IP 位址範圍清單，以識別重疊區域。
你的閱讀路徑
以下階段將依序引導您完成跨雲網路設計。
第一階段：發現
先從探索開始。 在設計 Azure 基礎設施前，先了解你的多雲環境。
1. 跨區域與多雲連接
這篇文章是你設計決策的核心點。 繪製你的多雲拓撲圖：哪些 AWS VPC 和 Google Cloud VPC 需要連接 Azure、哪些流量在雲端之間流動，以及哪種架構模式適合你的規模。 利用雲端供應商之間的服務對應（Transit Gateway 對應 Virtual WAN、Security Groups 對應 Network Security Groups、VPC Peering 對應 VNet peering），將您現有的設計轉譯為 Azure 的術語。
當你有多個 VPC、分支、區域或雲端邊緣時，Virtual WAN 是推薦的中轉模式。 Virtual WAN 提供 Azure 版的 AWS Transit Gateway 功能：自動化路由、集中式安全，以及多分支/多區域規模。 評估您的跨雲環境是否有充分理由採用 Virtual WAN，或是搭配 VPN 閘道 的較簡單中樞輪輻架構就已足夠。
第二階段：基礎建設
3. 虛擬網路與子網
設計你的 Azure VNet 作為遷移或已連接工作負載的著陸區。 AWS VPC 與 Google Cloud VPC 概念的映射：VPC 子網會變成 Azure 子網，可用性區域會映射到 Azure 的可用性區域，路由表則遵循類似模式。 專注於部署於 Azure 的工作負載子網路調整大小。
4. IP 位址規劃
規劃三個雲間不重疊的位址空間。 這步對於跨雲端連線至關重要：如果你的 Azure VNet 範圍與 AWS VPC 或 Google Cloud VPC 範圍重疊，你就無法在它們之間建立 VPN 隧道。 在分配 Azure 位址空間前，記錄所有環境中所有使用的 CIDR 區塊。
將你的 AWS 安全群組和 Google Cloud 防火牆規則鏡像成 Azure 網路安全群組（NSG）。 將你現有的允許與拒絕規則轉換成 NSG 格式。 使用應用程式安全群組（ASG）來複製 AWS 安全群組所提供的標籤式群組。
第三階段：連接性
6. 混合連接
在 Azure 與 AWS 或 Google Cloud 之間建立 IPSec VPN 隧道，進行加密的跨雲傳輸。 將 Azure VPN 閘道（或 Virtual WAN VPN 連線）連接到 AWS 虛擬私人閘道和 Google Cloud VPN。 根據您的跨雲流量需求選擇隧道頻寬。 規劃冗餘隧道以避免單點故障。
第四階段：安全
在遷移工作負載前，先規劃好你的 DNS 切換策略。 AWS 或 Google Cloud 中的應用程式會解析在移轉後可能需要指向 Azure 的主機名稱。 配置 Azure DNS Private Resolver 與外發端點進行跨雲端名稱解析。 請參閱本文後面的 DNS 切換檢查清單 ，了解逐步遷移指引。
8. Azure 防火牆
在安全的虛擬中樞部署 Azure 防火牆，以檢查所有跨雲及分支流量。 每一個在 Azure 與 AWS 或 Google Cloud 之間傳輸的封包都會經過防火牆進行日誌記錄和政策強制執行。 使用網路規則進行跨雲流量模式及威脅情報過濾，以阻擋已知的惡意目的地。
第五階段：營運
9. 網路監控與可觀察性
跨雲環境更難進行疑難排解，因為你無法控制每一條連線的兩端。 啟用 Azure 網路監看員 以進行連線測試、VPN 隧道診斷及封包擷取。 監控隧道正常運行時間、雲端之間的延遲，以及吞吐量是否符合容量需求。 針對會影響跨雲應用程式可用性的隧道中斷設定警示。
條件條款
根據您的具體需求，請納入以下文章：
| 狀況 | 文章 | 何時納入 |
|---|---|---|
| 面向公眾的應用 | 網路入侵 | 你遷移的應用程式是面向網路的（需要直接公開存取） |
| HTTP/HTTPS 應用 | Web 應用程式防火牆 | 面向公開的網頁應用需要第 7 層 WAF |
| 需要第 7 層分流 | 應用程式交付與效能 | 遷移後你需要全球或區域流量分配 |
| 公用端點 | DDoS 防護 | 你對對外服務有可用性要求 |
| 偏好中樞與輪輻 | 中樞與輪輻拓撲 | 你的跨雲端環境規模很小，沒有充分理由採用 Virtual WAN |
| 多區域 Azure | 多區域網路 | 你的 Azure 目標跨越多個區域，超越跨雲端連接 |
| VM 管理員存取權 | 開發者與管理員存取權 | 你需要對 Azure 託管虛擬機提供安全的 RDP/SSH 存取 |
| 集中式出口 | 對外網際網路存取 | 集中式網路撤離政策是你目標設計的一部分 |
| 大規模 VNet 環境 | 集中式網路管理 | Azure 端會逐步擴展為受治理的多訂用帳戶環境 |
| PaaS 私有端點 | PaaS 私人存取 | 你的目標架構包含帶有私有端點的 Azure PaaS 服務 |
跨雲探索檢查清單
在設計 Azure 網路之前，先將現有的雲端服務對應到 Azure 的對應服務。 這種映射加速設計決策，避免期待不匹配。
AWS 至 Azure 服務對應
| AWS 服務 | Azure 等效 | Notes |
|---|---|---|
| 交通閘道 | Azure Virtual WAN | 適用於多 VPC、跨區域與多雲端的集中式路由樞紐 |
| VPC | Azure 虛擬網路 | 具有子網路與路由表的隔離網路邊界 |
| VPC 對等互連 | VNet 對等互連 | 兩個虛擬網路之間的直接連接 |
| 安全團體 | 網路安全性群組 (NSG) | 子網或網路介面層級的有狀態流量過濾 |
| 網路存取控制清單 | NSG（子網層級） | Azure NSG 結合了安全群組與 NACL 功能 |
| 虛擬私人閘道 | VPN 閘道 | IPSec VPN 終止點 |
| 直接連線 | Azure ExpressRoute | 專用私人連線（非透過公共網路） |
| 53號公路私人託管區域 | Azure 私人 DNS 區域 | 虛擬網路中的私人 DNS 名稱解析 |
| 路由表 | 使用者定義路由 (UDR) | 自訂路由以覆蓋 Azure 系統路由或 AWS 隱含路由 |
| 彈性負載平衡器 (ALB/NLB) | Azure 負載平衡器 / 應用程式閘道 | L4 與 L7 負載平衡；應用程式閘道提供類似 AWS ALB 與 AWS WAF 的 WAF 能力 |
| AWS WAF | Azure Web 應用程式防火牆 | 第七層 HTTP/HTTPS 保護 |
| 網路防火牆 | Azure 防火牆 | 具備威脅情報的有狀態網路防火牆 |
Google Cloud 至 Azure 服務對應
| Google Cloud 服務 | Azure 等效 | Notes |
|---|---|---|
| VPC 網路 | Azure 虛擬網路 | Google Cloud 中為全域資源；在 Azure 中為區域性資源（跨區域請使用 VNet peering） |
| 雲端互聯 | Azure ExpressRoute | 專屬私人連線 |
| 雲端VPN | VPN 閘道 | IPSec VPN 隧道 |
| 雲端 NAT | Azure NAT 閘道 | 私有資源的對外網際網路存取 |
| 雲端路由器 | Azure 路由伺服器 | 與網路虛擬設備的動態 BGP 路由交換 |
| 雲裝甲 | Azure Web 應用程式防火牆 | 第7層DDoS與應用程式保護 |
| 防火牆規則 | 網路安全性群組 | 流量篩選 (Google Cloud 規則屬於全域；Azure NSG 依每子網路或每 NIC 設定) |
| 雲端DNS私有區 | Azure 私人 DNS 區域 | 網路內部的私有名稱解析 |
| 網路情報中心 | Azure 網路監看員 | 網路監控、診斷與拓撲視覺化 |
DNS 切換檢查清單
DNS 切換是跨雲遷移中風險最高的步驟。 請遵循此檢查清單，以減少過渡期間的決議失敗。
移轉前
- 所有變動的 DNS 紀錄都會降低存活時間（TTL）值。 TTL 設定為 60–300 秒，至少在切換前 48 小時。 這個步驟確保快取會在更新記錄時快速到期。
- 記錄所有指向你遷移基礎設施的 DNS 紀錄：A 記錄代表伺服器、CNAME 記錄代表服務、MX 記錄代表郵件，以及 SRV 記錄代表服務發現。
- 使用 Azure VNet 中的輸出端點設定 Azure DNS 私人解析器。 此解析器會在共存期間將 AWS/Google Cloud 託管區域的查詢轉發給相應的上游 DNS 伺服器。
- 在遷移任何工作負載前，先測試從 Azure VNet 轉為 AWS/Google Cloud 主機名稱的前向與反向解析。
在移轉期間
- 更新遷移到 Azure 服務的 CNAME 紀錄。 當每個服務遷移時，將 CNAME 指向 Azure Front Door、Azure 流量管理員 或 Azure 應用程式閘道 端點。
- 更新各個已移轉伺服器的主機 A 記錄。 在你的 DNS 區域裡，將 AWS 或 Google Cloud 的 IP 位址替換成 Azure 私有 IP 位址。
- 保持條件轉發啟用 ，讓尚未遷移的區域名稱能透過原本雲端的 DNS 伺服器繼續解析。
在移轉之後
- 從所有地點驗證解析度：本地用戶端、Azure VNet 以及所有剩餘的 AWS 或 Google Cloud 工作負載都必須正確解析遷移的名稱。
- 確認穩定解析度後，將 TTL 值調回生產水準（3,600 秒或更長）。
- 移除已完全遷移到 Azure DNS 的區域的條件轉發器。 僅為仍位於 AWS 或 Google Cloud 的區域保留轉送器。
你所建造的
透過這條閱讀路徑，你將 Azure 連接到現有的 AWS 或 Google Cloud 環境，採用加密傳輸、集中防火牆檢查及監控連線。 你的設計包括：
- 多雲拓撲發現與服務映射
- Virtual WAN 或樞紐輻射式傳輸架構
- IPSec VPN 隧道連接 AWS 和 Google Cloud
- 用於跨雲端流量檢查的 Azure 防火牆
- 使用 Private Resolver 進行跨雲端名稱解析的 DNS 切換作業
- 網路監看員 隧道健康與效能監控
下一步
- 隨即轉移網路路徑：如果您也將內部部署工作負載直接移轉到 Azure IaaS
- 遷移與現代化網路路徑：如果您的 Azure 部署採用 PaaS 服務與容器
- 設計階段一覽：Azure 網路設計的通用階段式摘要
- Azure 網路計畫與設計概述：針對所有可用服務進行基於能力的探索