Azure Virtual Network Routing Appliance 預覽

Microsoft 最近悄悄將 Azure Virtual Network Routing Appliance（VNRA）推出為公開預覽版，但幾乎沒有大張旗鼓宣傳。作為全新的 Azure 網路服務，許多人第一時間都在問：

「這到底是做什麼用的？」
「什麼情況下會部署它？」

我們目前知道的是，它不只是另一種虛擬機器型的網路設備，即使底層基礎架構已被抽象化並以 PaaS 形式提供。Microsoft Learn 將其描述為運行於專用網路硬體之上，專為高吞吐量、低延遲的 east-west（東西向）流量設計。

在目前的預覽版中，你可以選擇 50、100 或 200Gbps 的規格，每個訂閱最多可部署兩個實例。速度確實很快，但實際上仍會受到端點頻寬限制，例如許多 Azure 虛擬機器根本無法達到這麼高的吞吐量。

那麼，它真正的用途是什麼？

解決 VNet Peering 不具傳遞性（Non-Transitive）問題？

最先浮現的主要使用情境，或者說我過去實際遇到過的挑戰（通常來自不佳的網路架構），就是它可能可以解決 Azure 虛擬網路之間的「傳遞式路由（transitive routing）」問題。

簡單來說，就是彼此沒有直接連線的 Azure VNet 無法互相路由。

在以下範例中：

🔵VNet B 作為 Hub（中樞）網路

🔵與所有 Spoke（分支）網路建立 VNet Peering

🔵VNet B 可以與所有 Spoke 通訊

🔵但各 Spoke 彼此無法直接通訊

這是因為 VNet Peering 天生就是「不具傳遞性（non-transitive）」的設計。

因此，Spoke 之間的流量必須經過 Hub VNet，再透過某種路由器轉送到其他網路。

目前標準做法通常是建置 Hub-and-Spoke 架構，而 Hub VNet 中的路由器通常會是：

🔵Azure Firewall

🔵或某種 NVA（Network Virtual Appliance）

現行架構有什麼問題嗎？

其實完全沒有。

這是標準的 Zero Trust（零信任）安全架構，也是我幾乎一定會採用的設計。

防火牆不只是路由器，同時也負責：

🔵流量檢查

🔵過濾

🔵East-West 流量安全控管

前提是你的路由設計已將所有流量導向防火牆。

Azure VNRA 能取代防火牆嗎？

作為「路由器」也許可以。

但若如此，你將完全失去：

🔵安全檢測

🔵流量過濾

🔵記錄與稽核能力

將所有流量送往防火牆仍是最佳實務，因為這有助於：

🔵實現 Zero Trust

🔵集中式記錄

🔵政策控管

現有架構的瓶頸

缺點在於：

大量網路流量可能會穿越這些設備。

若你使用 Azure Firewall：

🔵它可依需求自動擴充

🔵但擴充並非即時

🔵在擴充期間仍可能出現吞吐瓶頸

雖然現在可以預先擴充（pre-scale），但成本相當高。

若是 NVA，情況更困難：

🔵必須事先預估需求

🔵提前建置 VM 規模

🔵提升 VM SKU 來支撐吞吐量

現實中，我仍看到很多客戶只對 north-south（南北向）流量做防火牆檢查，而讓 east-west 流量直接通往目的地，以減少防火牆負載。

可能的混合式架構？

理論上，你可以在同一個 VNet 同時部署：

🔵VNRA

🔵防火牆

路由控制仍與 Azure 現有機制相同：

🔵System Routes

🔵BGP Routes

🔵User Defined Routes（UDR）

因此，你可以選擇：

選項一

將：

🟢East-West 流量導向 VNRA

🟢North-South 流量導向 Firewall / Gateway

選項二

先將所有流量送至 VNRA，再由 VNRA：

🟢將 North-South 流量轉送至 Firewall / Gateway

🟢將 East-West 流量直接送至目標 VNet

部署方式

目前部署非常簡單。

你需要：

🔵部署到目前支援的 Preview 區域

🔵選擇目標 VNet

🔵建立專用子網：

VirtualNetworkApplianceSubnet

你也必須選擇容量：

🔵50Gbps

🔵100Gbps

🔵200Gbps

未來價格應該會依頻寬而異。

目前公開預覽期間完全免費。

目前的限制

部署完成後，VNRA 本身幾乎沒有可設定項目。

你可以：

🔵套用 NSG

🔵套用 Route Table

但服務本身沒有額外設定介面。

此外，目前仍缺少許多功能：

🔵不支援 Private Link

🔵不支援 IPv6

🔵不支援 Global VNet Peering

🔵沒有 Metrics 或 Logging 資料

路由運作方式

VNRA 的路由運作方式與 Azure 一樣：

你仍需：

🔵手動新增路由

🔵或用 UDR 覆蓋學習到的路由

以便將流量導向 VNRA IP。

例如：

Spoke VNet A 無法知道 Spoke VNet B 的路由（因為沒有直接 Peering），因此可新增：

🔵VNet B 的 Address Prefix

🔵Next Hop 指向 VNRA（10.0.0.4）

VNRA 會因為已學習到 Peering 路由，而將流量轉送至 VNet B。

同時也別忘了：

VNet B 必須設定回程路由返回 VNRA。

與 Azure Firewall 搭配

你也可以：

🔵將未知路由透過 0.0.0.0/0

🔵導向 Azure Firewall（10.0.2.4）

如此一來：

🔵已知 East-West 流量走 VNRA

🔵未知或外部流量走 Firewall

確保其他流量仍可被檢查。

若所有流量都經過 VNRA？

那麼你必須確保：

VNRA 自己知道 North-South 流量該送去哪裡。

因此需要在 VNRA 的 Route Table 中加入適當 UDR。

例如：

🔵On-premises 流量 → VNet Gateway

🔵其他流量 → Azure Firewall

如何使用它？

它可能適合某些特殊情境，例如：

🔵舊有架構

🔵難以處理的 Transitive Routing 問題

🔵作為「快速修補（Quick Fix）」方案

但這仍取決於正式 GA 後的價格。

未來若支援：

🔵Private Link

🔵更大流量場景

或許會出現更多使用案例。

但截至目前，即使在大型客戶環境中，我也還沒遇到真正需要它的情境。

Microsoft 的真正目的？

Microsoft 目前主要將其定位為：

🔵高吞吐量

🔵低延遲

🔵硬體型網路服務