MENU

Azure Routing VMは置き換えられる？VNet Routing Applianceの200Gbps性能と制限

Azure

AzureでLinux VMなどをルーターとして動かしている場合、「OS更新や冗長化をやめて、マネージドサービスへ置き換えられないか」と考える管理者は多いでしょう。

結論から言うと、Routing VMをVNet間のL3転送だけに使っているなら、Azure Virtual Network routing applianceは有力な置き換え候補です。一方、ファイアウォール、NAT、VPN終端、BGP、パケット検査、独自スクリプトなども担わせている場合、単純な置き換えはできません。

Azure Virtual Network routing applianceは2026年8月4日に一般提供され、1インスタンスあたり最大200Gbpsの帯域幅、IPv4／IPv6デュアルスタック、クロスリージョンPrivate Endpoint対応、組み込みの高可用性、Azure Monitorメトリックなどを提供します。重要なのは、Routing VMが現在担っている機能を分解し、「転送機能」と「セキュリティ・動的ルーティング・NAT機能」を分けて比較することです。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure Virtual Network routing applianceとは

Azure Virtual Network routing applianceは、VNet内のトラフィックを高速に転送するためのAzureマネージド型ルーティングリソースです。VM上でLinuxやネットワークOSを動かすのではなく、専用のネットワークハードウェア上で処理されます。

主な用途は、ハブアンドスポーク構成におけるスポーク間通信など、Azure内部のEast-Westトラフィックを高速に中継することです。

作成したルーティングアプライアンスは、VNet内に用意した次の専用サブネットへ配置します。

VirtualNetworkApplianceSubnet

その後、スポーク側などのルートテーブルにユーザー定義ルートを追加し、次ホップの種類を「仮想アプライアンス」、次ホップアドレスをルーティングアプライアンスのプライベートIPアドレスに設定します。(Microsoft Learn)

構成イメージは次のとおりです。

Spoke VNet A
    │
    ├─ UDR
    │    次ホップ：Virtual appliance
    │
Hub VNet
    │
    ├─ VirtualNetworkApplianceSubnet
    │    └─ VNet Routing Appliance
    │
    └─ VNet Peering
         │
Spoke VNet B

Routing VMとの違い

従来のRouting VMは、Azure VMのNICとゲストOSの両方でIPフォワーディングを有効化し、OSやルーティングソフトウェアでパケットを転送する構成です。

Azure Virtual Network routing applianceは、このうち「パケットを次のネットワークへ転送するデータパス部分」をマネージドサービスへ置き換えます。(Microsoft Learn)

比較項目VNet Routing ApplianceRouting VM
主な役割VNetトラフィックの高速転送転送に加え、任意のネットワーク機能を実装可能
処理基盤Azure管理の専用ネットワークハードウェアAzure VMとゲストOS
帯域幅10、50、100、200Gbpsから選択VMサイズ、NIC数、ネットワーク性能に依存
高可用性組み込みで提供複数VM、ロードバランサー、経路切り替えなどを設計
ゾーン障害対策既定で可用性ゾーンに対する回復性を提供ゾーン分散とフェイルオーバーを利用者が設計
OS管理不要更新、再起動、脆弱性対応、監視が必要
独自ソフトウェアインストール不可FRRouting、iptables、プロキシなどを導入可能
監視Azure Monitorメトリックを標準出力VM、OS、エージェント、アプリの監視を個別設定
帯域幅変更インプレース変更不可。再作成が必要VMサイズ変更やスケール構成を検討可能
内部ロードバランサー前段への配置は非対応NVAの冗長化構成などで使われる場合がある

つまり、VNet Routing Applianceは「自由に設定できる仮想ルーター」ではありません。高速なマネージド転送層として使うサービスと考えるのが適切です。

最大200GbpsのEast-West Routing

VNet Routing Applianceは、作成時に10、50、100、200Gbpsのいずれかの帯域幅階層を選択します。

帯域幅だけでなく、1秒あたりの最大接続数と最大同時フロー数も階層ごとに異なります。(Microsoft Learn)

帯域幅階層1秒あたりの最大接続数最大同時フロー数
10Gbps100,0001,000,000
50Gbps250,0002,000,000
100Gbps600,0004,000,000
200Gbps1,500,0008,000,000

200Gbpsだけを見て選ばない

容量を選ぶ際は、通信量だけでなく、次の3項目を確認する必要があります。

  • ピーク時のスループット
  • 1秒あたりの新規接続数
  • 最大同時フロー数

例えば、既存環境のピークが38Gbpsでも、新規接続数が毎秒220,000、同時フロー数が180万に達している場合、50Gbps階層では上限に近づきます。

帯域幅だけなら50Gbpsで収まりそうですが、接続数とフロー数の余裕が小さいため、将来の増加や突発的な負荷を考えると100Gbps階層を検討すべきです。

また、「200Gbps」は選択したインスタンスの帯域幅階層です。1本のTCP接続や1台のVMが常に200Gbpsを出せることを意味するものではありません。送受信元VMのNIC性能、パケットサイズ、フロー分散、VNet Peeringなどを含めて実測する必要があります。

ハブアンドスポークで使える3つのルーティングパターン

Microsoftは、VNet Routing Applianceの代表的な構成として、3つのパターンを示しています。(Microsoft Learn)

Azureのプライベートアドレスだけを転送する

スポークサブネットのUDRで、RFC1918などのプライベートアドレス空間だけをルーティングアプライアンスへ送ります。

10.0.0.0/8       → VNet Routing Appliance
172.16.0.0/12    → VNet Routing Appliance
192.168.0.0/16   → VNet Routing Appliance
0.0.0.0/0        → 既存のインターネット経路

スポーク間のEast-West通信だけを高速化し、インターネット向け通信やオンプレミス向け通信は既存経路のまま維持したい場合に適しています。

Azure FirewallやNAT Gatewayを使ったエグレス構成を変更したくない場合にも扱いやすい設計です。

デフォルトルートをアプライアンスへ送る

スポークサブネットに次のUDRを設定します。

0.0.0.0/0 → VNet Routing Appliance

各スポークに多数のプレフィックスを登録せず、共通化されたシンプルなルートテーブルを使える点がメリットです。

ただし、すべての宛先がアプライアンスへ送られるため、ハブ側でオンプレミス、インターネット、Private Endpointなどへの経路を正しく分岐させる必要があります。

特に、デフォルトルートを使用する場合は、Azure Private LinkとPrivate Endpointの経路を事前に検証しなければなりません。(Microsoft Learn)

プライベート通信とインターネット通信を分離する

プライベートアドレスはVNet Routing Applianceへ送り、デフォルトルートはAzure Firewallなどのエグレスサービスへ送る構成です。

10.0.0.0/8    → VNet Routing Appliance
0.0.0.0/0     → Azure Firewallなど

East-West通信とNorth-South通信の役割を分離しやすく、インターネット通信が意図せずルーティングアプライアンスへ流れることを防げます。

Routing VMを置き換える際は、この分離構成が最も判断しやすいケースです。

IPv4／IPv6デュアルスタックに対応

VNet Routing Applianceは、次のネットワーク構成をサポートします。

  • IPv4
  • IPv6
  • IPv4／IPv6デュアルスタック
  • IPv6アクセス制御リストの適用

IPv6をRouting VMで転送している環境でも、単純なIPv6ルーティングであれば移行候補になります。IPv4とIPv6で別々のRouting VMを維持する必要もありません。

ただし、IPv6のAzure Private Link通信をルーティングアプライアンスへ通すには、Private Endpointのプレフィックスを明示的にアプライアンスへ送るUDRが必要です。UDRがない場合、IPv6のPrivate Endpointトラフィックはアプライアンスを通過しません。(Microsoft Learn)

クロスリージョンPrivate Endpointに対応

VNet Routing Applianceは、グローバルおよびクロスリージョンのPrivate Endpointをサポートします。複数リージョンのPrivate Endpointへアクセスする環境で、単一のアプライアンスを転送層として利用できます。

ただし、この機能はリージョン間のVNet接続を自動作成するものではありません。実際の構成では、次の要素を別途確認します。

  • Global VNet Peeringなどのリージョン間接続
  • 送信元と戻り方向のUDR
  • Private EndpointのDNS名前解決
  • NSGと管理ルール
  • リージョン間データ転送の料金
  • 通信遅延とデータ所在地の要件

「クロスリージョン対応」という表現だけで、既存のネットワーク設計を省略できるわけではありません。

高可用性とゾーン回復性を標準搭載

Routing VMで高可用性を確保する場合、一般的には複数台のVMを配置し、障害検知、経路切り替え、ロードバランサー、可用性ゾーンなどを組み合わせます。

VNet Routing Applianceでは、組み込みの高可用性と可用性ゾーンに対する回復性が既定で提供されます。利用者がOSのクラスタリングやルータープロセスの監視を構築する必要はありません。(Microsoft Learn)

なお、ルーティングアプライアンスの前段に内部ロードバランサーを配置する構成はサポートされません。ロードバランサーを配置しても、アプライアンスへトラフィックは転送されません。

Routing VMから移行する場合は、既存構成をそのまま再現するのではなく、内部ロードバランサーを取り除き、UDRの次ホップをルーティングアプライアンスのプライベートIPアドレスへ変更します。

Azure Monitorで標準監視できる

VNet Routing Applianceは、診断設定を作成しなくてもAzure Monitorへプラットフォームメトリックを送信します。

確認できる主な項目は次のとおりです。(Microsoft Learn)

メトリック確認できる内容
Bytes sentアプライアンスから送信されたデータ量
Bytes receivedアプライアンスが受信したデータ量
Packets sent送信パケット数
Packets received受信パケット数
Inbound flowsアクティブな受信フロー数
Outbound flowsアクティブな送信フロー数
Inbound flow creation rate受信方向の新規フロー生成数
Outbound flow creation rate送信方向の新規フロー生成数

Azureポータルのメトリック画面に加え、ダッシュボードへの表示、Azure Monitor REST APIからの取得、アラート設定にも利用できます。

運用時は、帯域幅だけでなく、次の状態を監視すると異常を早く見つけられます。

  • スループットが選択階層の上限へ継続的に近づいている
  • 同時フロー数が通常時より急増している
  • 新規フロー生成率だけが突出している
  • UDR変更後に受信バイト数が増えていない
  • 通常発生しているトラフィックが突然ゼロになった

詳細なフローログは利用できない

Azure Monitorで確認できるのは集計メトリックです。現時点では、通信ごとの5タプルや、どのルールに一致したかといった詳細なフローログは提供されません。(Microsoft Learn)

送信元IP、宛先IP、ポート、プロトコル単位の監査が必要な場合は、ワークロードサブネット側のフローログや、別のセキュリティ製品を組み合わせる必要があります。

Routing VMを置き換えやすいケース

次の条件に当てはまるほど、VNet Routing Applianceへ移行しやすくなります。

  • Routing VMの主な役割がIPフォワーディングである
  • 静的なUDRで経路を制御している
  • ハブアンドスポークのスポーク間通信に使っている
  • NAT、VPN、プロキシ、ファイアウォール処理を行っていない
  • OSへ独自パッケージやスクリプトを導入していない
  • 既存VMの更新や冗長化が運用負荷になっている
  • Azure Monitorの集計メトリックで監視要件を満たせる
  • 利用したいリージョンでサービスが提供されている

例えば、Linux VMで次のような設定だけを行っているケースです。

IP forwarding：有効
静的ルート：設定済み
iptablesによるNAT：なし
FRRouting：なし
VPN：なし
プロキシ：なし
パケット検査：なし

このようなRouting VMは、VNet Routing Applianceの役割と近く、置き換えによる効果を得やすい構成です。

単純に置き換えられないケース

Routing VMが次の機能を持っている場合、VNet Routing Appliance単体を同等品として扱うべきではありません。

Routing VMの現在の役割判断主な代替候補
単純なIP転送置き換えやすいVNet Routing Appliance
SNAT／DNAT単体置換しないNAT Gateway、Azure Firewall、NVA
L3～L7ファイアウォール単体置換しないAzure Firewall、セキュリティNVA
IDS／IPS、TLS検査単体置換しないAzure Firewall Premium、対応NVA
IPsec／VPN終端単体置換しないAzure VPN Gateway、NVA
BGPによる動的ルート交換現行設計を分解して検討Azure Route ServerとBGP対応NVA
SD-WAN単体置換しないSD-WAN対応NVA、Virtual WAN
HTTP／SOCKSプロキシ単体置換しないプロキシ製品、NVA
独自Linuxスクリプト再設計が必要AzureネイティブサービスまたはVM
詳細な通信ログ取得単体では不足する可能性Firewall、NVA、フローログ

Azure Firewallは、L3～L7フィルタリングや脅威インテリジェンス、上位SKUでのIDPSなどを提供するステートフルなセキュリティサービスです。VNet Routing Applianceの高速転送とは役割が異なります。(Microsoft Learn)

Azure Route ServerやAzure Firewallとの違い

名前が似ていますが、VNet Routing Appliance、Azure Route Server、Azure Firewallはそれぞれ役割が異なります。

サービス主な役割トラフィックのデータパス
VNet Routing Appliance高速なL3転送通過する
Azure Route ServerBGPによるルート交換と経路配布Route Server自体を転送装置として使うものではない
Azure Firewallステートフルな通信検査とセキュリティ制御通過する

Azure Route Serverは、BGP対応NVAとAzure SDNの間でルートを自動交換するサービスです。UDRを手作業で更新する代わりに、BGPで動的に経路を配布したい場合に使用します。(Microsoft Learn)

そのため、BGPルーターとして動作しているRouting VMを廃止したい場合、VNet Routing Applianceだけを見るのではなく、次のように機能を分けて検討します。

高速なデータ転送
    └─ VNet Routing Appliance

BGPによる動的経路交換
    └─ Azure Route Server＋BGP対応NVA

通信検査・ファイアウォール
    └─ Azure FirewallまたはセキュリティNVA

移行前に確認すべき制限事項

VNet Routing Applianceには、Routing VMとは異なる制限があります。設計後に発覚すると移行をやり直す可能性があるため、先に確認しておきましょう。(Microsoft Learn)

制限事項実務への影響対応
1サブスクリプション、1リージョンあたり最大2台多数のハブへ個別配置できない場合があるサブスクリプション設計と配置数を確認
最大帯域幅は1インスタンス200Gbpsそれ以上の要件では構成検討が必要実トラフィックとフロー数を測定
帯域幅階層を変更できない容量不足時にインプレース拡張できない再作成と経路切り替え手順を準備
内部ロードバランサーの後段に配置できない既存のRouting VM冗長化構成を流用できないUDRの次ホップを直接変更
Terraform AzureRMプロバイダーが未対応既存Terraformコードだけでは管理できないAzAPIプロバイダーを使用
詳細なフローログを取得できない通信単位の監査や調査が難しいワークロード側ログやFirewallを併用
VNet暗号化の対象にならない通過トラフィックの暗号化要件に影響TLSやIPsecなど別レイヤーで暗号化
同一リージョン内のアプライアンスチェーン非対応複数アプライアンスを直列に通す設計が困難経路とセキュリティ構成を再設計
IPv6 Private Linkに明示的なUDRが必要IPv4だけ成功し、IPv6だけ迂回する可能性があるIPv6プレフィックスのUDRを追加
サービスエンドポイント利用時にNSG要件があるNSG不足でサービスアクセスが失敗する必要なサービスタグ通信を許可

VNet暗号化を利用している環境は要注意

公式ドキュメントでは、ルーティングアプライアンスを通過するトラフィックは、Virtual Network encryptionによって暗号化されないとされています。(Microsoft Learn)

規制対応や社内基準でVNet内通信の暗号化が必須の場合は、移行前に次の点を確認します。

  • アプリケーション通信がTLSで暗号化されているか
  • データベース接続の暗号化が強制されているか
  • IPsecなど別の暗号化経路が必要か
  • セキュリティ基準上、VNet暗号化が必須指定されていないか

性能や運用負荷だけで移行を決定しないことが重要です。

日本リージョンで利用できるか確認する

2026年9月2日時点の公式リージョン一覧には、東アジア、東南アジア、米国、欧州などが掲載されています。一方、日本東部と日本西部は掲載されていません。(Microsoft Learn)

日本国内リージョンでの稼働が必須の場合、現時点ではこれが導入判断を左右する大きな条件になります。

東アジアなど別リージョンへハブを置く方法も考えられますが、次の影響を考慮しなければなりません。

  • リージョン間通信の遅延
  • データ転送料金
  • 障害範囲の拡大
  • データ所在地や社内ポリシー
  • Private EndpointのDNS設計
  • Global VNet Peeringの構成

利用可能リージョンは今後追加される可能性があるため、導入時点の公式一覧とAzureポータルの作成画面を確認してください。

Routing VMから移行する手順

現在のRouting VMの機能を棚卸しする

最初に、VMへログインして次の項目を確認します。

  • IPフォワーディング設定
  • OSのルートテーブル
  • iptables、nftables、Windows Firewallのルール
  • SNAT、DNAT、IPマスカレード
  • FRRoutingなどのルーティングデーモン
  • BGP、OSPFなどの動的ルーティング
  • VPNやトンネル
  • プロキシ、WAN最適化
  • パケットキャプチャやログ転送
  • 起動スクリプトと定期処理

単にAzure側のUDRだけを見ても、Routing VMが実際に何をしているかは判断できません。

実際のトラフィックを測定する

最低でも通常日と繁忙日の両方について、次のピーク値を収集します。

  • 送受信スループット
  • パケット数
  • 新規接続数
  • 同時フロー数
  • IPv4とIPv6の比率
  • Private Endpoint向け通信量
  • リージョン間通信量

帯域幅階層は後から変更できないため、直近のピーク値だけでなく、将来の増加分を含めて選びます。

専用サブネットを作成する

ルーティングアプライアンスを配置するVNetに、次の名前の専用サブネットを作成します。

VirtualNetworkApplianceSubnet

必要に応じて、作成時に専用サブネットへNSGとルートテーブルを関連付けられます。(Microsoft Learn)

ルーティングアプライアンスを作成する

Azureポータルで「Azure Virtual Network routing appliances」を検索し、次の項目を指定します。

  • サブスクリプション
  • リソースグループ
  • リソース名
  • リージョン
  • 10、50、100、200Gbpsの容量
  • 配置先VNet

リージョン内の容量が不足している場合、特定の帯域幅階層で割り当てエラーになることがあります。その場合は、下位階層、別リージョン、再試行を検討します。(Microsoft Learn)

検証用UDRで通信を切り替える

最初からすべてのスポークを切り替えず、検証用サブネットまたは影響の小さいスポークから移行します。

ルートの例は次のとおりです。

宛先プレフィックス：10.20.0.0/16
次ホップの種類：Virtual appliance
次ホップアドレス：VNet Routing ApplianceのプライベートIP

VNet Peeringを使用している場合は、該当するピアリングで転送されたトラフィックを許可する設定も確認します。(Microsoft Learn)

往復経路を検証する

片方向だけでなく、戻り方向の経路も確認します。

主なテスト項目は次のとおりです。

  • スポークAからスポークB
  • スポークBからスポークA
  • ハブから各スポーク
  • オンプレミスからスポーク
  • 同一リージョンのPrivate Endpoint
  • クロスリージョンのPrivate Endpoint
  • IPv4通信
  • IPv6通信
  • サービスエンドポイント
  • インターネット向け通信

片方向だけUDRを変更すると、意図しない非対称ルーティングが発生する場合があります。特に経路上にAzure Firewallなどのステートフルな装置がある場合は、行きと戻りのパスを明確にします。

Azure Monitorで切り替え結果を確認する

UDRを変更した後、ルーティングアプライアンスの次のメトリックを確認します。

  • Bytes receivedが増加しているか
  • Bytes sentが受信量と不自然に乖離していないか
  • Inbound／Outbound flowsが発生しているか
  • Flow creation rateが想定範囲内か
  • 選択した階層の上限へ近づいていないか

トラフィックが確認できない場合は、UDRの次ホップ、NSG、VNet Peering、送信元と戻り経路を順番に確認します。

既存構成からの置き換え例

移行前

Spoke A ─┐
         ├─ UDR ─ Internal Load Balancer
Spoke B ─┘              │
                   ┌────┴────┐
                   │         │
              Routing VM1  Routing VM2
                   │         │
                   └────┬────┘
                        │
                 Azure Firewall

この構成では、次の運用が必要になります。

  • 2台のRouting VMのOS更新
  • VM障害の監視
  • ルーティングプロセスの監視
  • ロードバランサーの設定
  • ゾーン配置
  • フェイルオーバーテスト
  • VMサイズとNIC性能の管理

移行後

Spoke A ─┐
         ├─ UDR ─ VNet Routing Appliance
Spoke B ─┘                 │
                           ├─ Private address → 他のSpoke
                           └─ 0.0.0.0/0 → Azure Firewall

Routing VMが純粋な転送だけを行っていた場合、VMと内部ロードバランサーを削減しながら、East-West通信をマネージド化できます。

一方、既存VMがNATやファイアウォールも行っている場合は、機能をVNet Routing ApplianceとAzure Firewallなどへ分離してから移行します。

置き換え判断の最終チェック

次のすべてに「はい」と答えられるなら、Routing VMの置き換えを具体的に検討できます。

  • Routing VMは主にVNet間のIP転送を行っている
  • ファイアウォール、NAT、VPN、プロキシ機能を持っていない
  • BGPなどの動的ルーティングに依存していない
  • 詳細なフローログが必須ではない
  • VNet暗号化に関する制約を許容できる
  • 対象リージョンでサービスを利用できる
  • 必要な帯域幅、接続数、同時フロー数が上限内に収まる
  • 帯域幅変更時の再作成を許容できる
  • 同一リージョン内でアプライアンスを直列接続しない
  • UDR、NSG、Private Endpointの経路を事前検証できる

Azure Virtual Network routing applianceは、Routing VMの万能な後継ではありません。しかし、Routing VMを単純な転送装置として運用している環境では、最大200Gbpsの処理性能、IPv6対応、組み込み高可用性、Azure Monitor連携によって、性能と運用負荷の両方を改善できる可能性があります。

まずは既存Routing VMで動いているプロセスとルールを棚卸しし、直近のピークトラフィック、接続生成数、同時フロー数を測定してください。そのうえで、対応リージョンに検証環境を作成し、一部のスポークからUDRを切り替える方法が安全です。

Azure
IPv6 UDR Azure Virtual Network Azureネットワーク Routing Appliance

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次