Azure virtual network traffic routingは、Azure Virtual Networkのサブネットから出る通信を「どの経路に流すか」を決める仕組みです。結論から言うと、今回押さえるべきポイントは、ルーティングの考え方そのものが全面的に変わることではありません。重要なのは、ルート テーブルやNSGの上限引き上げ、プライベート サブネット化、UDR、BGP、NVA、NAT Gatewayを組み合わせた設計を見直す必要がある点です。Azureは各サブネットにシステム ルートを自動作成し、必要に応じてUDRやBGPルートで上書きできますが、0.0.0.0/0やサービス エンドポイントの扱いを誤ると、インターネット接続、オンプレミス接続、Azureサービス宛て通信に影響が出ます。(Microsoft Learn)
この記事では、Azure Networkingの「Azure virtual network traffic routing」について、管理者・開発者が確認すべき変更点、影響範囲、設定の見直しポイント、移行・展開時の注意点を実務目線で整理します。
Azure virtual network traffic routingで最初に理解すべきこと
Azure virtual network traffic routingでは、サブネットから送信される通信に対して、Azureがルート テーブル内のルートを評価し、宛先IPアドレスに合う経路を選びます。
Azure Virtual Networkでは、サブネットを作成した時点で、Azureが既定のシステム ルートを用意します。管理者が何も設定しなくても、同じVNet内のサブネット間通信や、既定のインターネット向け通信は成立します。一方で、セキュリティ検査、オンプレミス経由の通信、ハブ＆スポーク構成、Azure FirewallやNVA経由の強制トンネリングを行う場合は、UDRやBGPを正しく設計する必要があります。
実務では、次のように考えると整理しやすくなります。
| 観点 | 既定の動き | 管理者が設計する場面 |
|---|---|---|
| VNet内通信 | VNetアドレス空間宛てはVirtual networkへルーティング | サブネット間通信をNVA経由にしたい場合 |
| インターネット宛て | 0.0.0.0/0がInternetへ向く | NAT Gateway、Azure Firewall、VPN Gateway、NVA経由にしたい場合 |
| オンプレミス宛て | VPN GatewayやExpressRoute、BGPで追加ルートが入る | 経路集約、ルート伝播、検査経路を制御したい場合 |
| Azureサービス宛て | 既定ではAzureバックボーン上を通る場合がある | サービス エンドポイント、Private Endpoint、UDR例外を設計する場合 |
| 遮断したい通信 | 既定では到達可能な経路が選ばれる | Next hop typeをNoneにしたUDRでドロップする場合 |
「通信できない」「想定外の経路を通る」といったトラブルの多くは、NSGだけでなく、ルート テーブル、BGP、サービス エンドポイント、NAT Gateway、NVAの優先関係を見落としていることが原因です。
2026年5月時点で注目すべき変更点
2026年5月のAzure Virtual Network関連の更新では、NSGとルート テーブルの既定プラットフォーム上限引き上げが案内されています。Azure Resource Manager管理のネットワーク制限では、NSGルール数、NSGルール内のアドレス・範囲数、UDRテーブル数、ルート数などの上限が大規模構成を前提に拡張されています。(マイクロソフトAzure)
特にルーティング設計に関係するポイントは次のとおりです。
| 変更・確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| ルート テーブルの上限拡大 | Azure Resource Managerのネットワーク制限では、User-defined routes per route tableが1,000、User-defined route tablesが600と示されています。 | 大規模なハブ＆スポーク、複数リージョン、細かい経路制御を設計しやすくなります。 |
| NSG上限の拡大 | NSG rules per NSGが2,000、送信元・宛先に指定できるIPアドレスや範囲が6,000と示されています。 | 経路制御だけでなく、通信許可・拒否のポリシーも細かく管理しやすくなります。 |
| UDRのサービス タグ利用 | UDRのアドレス プレフィックスにサービス タグを指定できます。ただし、サービス タグを使うルートはルート テーブルごとに25個以下です。 | Azure StorageやApp Serviceなど、サービス単位の例外ルートを作りやすくなります。 |
| プライベート サブネット既定化 | 2026年3月31日以降のAPIでは、新しいVNetがプライベート サブネットを既定とし、明示的なアウトバウンド方式が必要になります。 | VMやアプリが暗黙のインターネット接続に依存していると、更新、認証、外部API接続で失敗する可能性があります。 |
| 0.0.0.0/0の影響拡大 | 既定のInternetルートをUDRで上書きすると、AzureサービスのパブリックIP宛て通信もNVAやGatewayへ流れる場合があります。 | 強制トンネリング設計では、サービス エンドポイント、Private Endpoint、NAT Gatewayとの関係を確認する必要があります。 |
ここで重要なのは、「上限が増えたから細かく分割すればよい」と考えないことです。ルート数を増やせるようになっても、設計が複雑になれば、障害時の切り分けは難しくなります。まずは経路を集約し、必要な例外だけをUDRで定義する方が運用しやすくなります。
ルートはどの順番で選ばれるのか
Azureのルート選択では、まず宛先IPアドレスに対して最も具体的なアドレス プレフィックスが選ばれます。たとえば、10.0.0.0/16と10.0.0.0/24の両方に一致する宛先であれば、より長いプレフィックスである10.0.0.0/24が優先されます。複数ルートが同じプレフィックスを持つ場合は、UDR、BGPルート、システム ルートの順に評価されます。(Microsoft Learn)
ただし、すべてをUDRで上書きできるわけではありません。仮想ネットワーク、VNetピアリング、Virtual network service endpointに関するシステム ルートは優先ルートとして扱われ、特にVirtualNetworkServiceEndpointを次ホップとするルートは、ルート テーブルを使っても上書きできません。(Microsoft Learn)
実務でよくある誤解は、「UDRを作れば必ずその経路になる」という考え方です。実際には、プレフィックスの長さ、ルートの種類、サービス エンドポイントの有無、BGP伝播、サブネットに関連付けたルート テーブルの状態をまとめて見る必要があります。
管理者・開発者への影響範囲
今回の確認対象は、ネットワーク管理者だけではありません。アプリケーション開発者、インフラ運用担当、セキュリティ担当、IaCテンプレートを管理するDevOps担当にも影響します。
影響を受けやすい環境
次のような環境では、特に確認が必要です。
- Azure Firewall、NVA、Proxyを経由する強制トンネリング構成
- VPN GatewayやExpressRouteでオンプレミスと接続している環境
- BGPでオンプレミス側の経路を広告している環境
- 複数のスポークVNetを持つハブ＆スポーク構成
- Azure Kubernetes Service、Azure Virtual Desktop、VM Scale Setsなど、アウトバウンド通信が重要なワークロード
- Azure Storage、Key Vault、App ServiceなどのAzureサービスにパブリック エンドポイント経由で接続しているアプリ
- Terraform、Bicep、ARMテンプレート、Azure CLIでVNetやサブネットを自動展開している環境
開発者が特に注意すべきなのは、「VMやコンテナーからインターネットに出られること」を前提にした実装です。OS更新、パッケージ取得、外部API呼び出し、ライセンス認証、証明書失効確認などは、明示的なアウトバウンド経路がないと失敗する場合があります。
0.0.0.0/0を安易に上書きしない
Azure virtual network traffic routingで最もトラブルになりやすいのが、0.0.0.0/0です。
サブネット作成時、Azureは0.0.0.0/0をInternetへ向ける既定ルートを作成します。このルートにより、他のルートに一致しない宛先への通信はインターネット方向へ流れます。ただし、UDRやBGPで0.0.0.0/0をVirtual applianceやVirtual network gatewayへ向けると、該当サブネットからの多くの通信がその次ホップへ流れます。AzureサービスのパブリックIP宛て通信も、サービス エンドポイントなどで別経路が作られていない限り、NVAやGateway側へ送られる可能性があります。(Microsoft Learn)
たとえば、次のような構成はよく使われます。
| 目的 | UDR例 | 注意点 |
|---|---|---|
| すべての外向き通信をAzure Firewallで検査 | 0.0.0.0/0 → Virtual appliance | Azureサービス宛て通信もFirewall経由になる可能性があります。 |
| オンプレミス経由でインターネットへ出す | 0.0.0.0/0 → Virtual network gateway | VPN Gatewayかどうか、BGP設計、帯域、戻り経路を確認します。 |
| 特定VNetへの通信を遮断 | 宛先VNetのCIDR → None | ピアリングのシステム ルートよりUDRが優先される場合があります。 |
| サブネット内通信だけはNVAを経由させない | 対象サブネットCIDR → Virtual network | より長いプレフィックスで例外ルートを作ります。 |
特にVPN Gatewayを使っている場合、GatewaySubnetに0.0.0.0/0宛てのルートを含むルート テーブルを関連付けると、ゲートウェイが正常に動作しなくなる可能性があります。GatewaySubnetは一般のワークロード用サブネットと同じ感覚でUDRを適用しないでください。(Microsoft Learn)
NVAやAzure Firewallを使う場合の確認ポイント
NVAを次ホップにするUDRでは、単にルートを作るだけでは不十分です。Azure側のNIC設定、NVAのOSやアプライアンス側の転送設定、戻り経路、NSG、可用性を合わせて確認する必要があります。
公式情報では、Virtual applianceを次ホップにする場合、トラフィックを転送するNICでAzureのIP forwardingを有効にする必要があると説明されています。また、NVA側のOSやアプリケーションでもIP転送が必要になる場合があります。さらに、NVAを同じサブネットに置いて、そのサブネットからNVAへ戻すようなルート テーブルを適用すると、ルーティング ループが発生する可能性があります。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 具体的に見る場所 | 失敗しやすいパターン |
|---|---|---|
| IP forwarding | NVAのNIC設定、OS設定 | Azure側だけ有効で、OS側の転送が無効 |
| NVA配置サブネット | NVA用サブネットとワークロード用サブネット | 同一サブネットに置いてループが発生 |
| 次ホップIP | UDRのNext hop IP address | ExpressRoute GatewayやVirtual WAN経由でしか到達できないIPを指定 |
| 戻り経路 | NVA、Firewall、オンプレミス側ルート | 片道だけNVA経由になり非対称ルーティングが発生 |
| 可用性 | Internal Load Balancer、複数NVA | 単一NVA障害で全通信が停止 |
| NSG | NVAサブネット、ワークロードサブネット | ルートは正しいがNSGで拒否 |
NVAを使った経路制御は強力ですが、運用負荷も上がります。障害時に「NVAを通るべき通信」と「直接通すべき通信」をすぐ判定できるように、ルート名、宛先プレフィックス、次ホップ、用途を命名規則で明確にしておくことが重要です。
NAT GatewayとUDRの優先関係を確認する
2026年以降のAzureネットワーク設計では、明示的なアウトバウンド接続がより重要になります。Azure NAT Gatewayは、サブネット単位でアウトバウンド接続を提供する推奨方式の一つです。NAT Gatewayをサブネットに関連付けると、プライベート リソースはNAT GatewayのパブリックIPを使って外部へ接続できます。(Microsoft Learn)
ただし、NAT Gatewayを付ければすべて解決するわけではありません。0.0.0.0/0をVirtual applianceやVirtual network gatewayへ向けるUDRがある場合、そのUDRはNAT Gatewayによるインターネット接続よりも優先されます。つまり、NAT Gatewayを追加したのに通信がNAT Gatewayを通らない、という状況が起こり得ます。(Microsoft Learn)
実務では、次のように整理してください。
- インターネット向け通信をNAT Gatewayから出したい場合は、
0.0.0.0/0のUDRがないか確認する - FirewallやNVAで検査したい場合は、NAT GatewayではなくUDRでNVAに向ける設計を明確にする
- Azure FirewallとNAT Gatewayを併用する場合は、どのサブネットのどの通信がどちらを通るかを明文化する
- サービス タグ宛ての例外ルートを使う場合は、プライベート サブネットで
Internet次ホップが成立するか確認する
特にプライベート サブネットでは、UDRでサービス タグ宛てにNext hop type Internetを設定してNVAをバイパスする構成が、明示的なアウトバウンド方式なしでは失敗する可能性があります。サービス エンドポイントは別の次ホップ種別を使うため、この制約とは切り分けて考える必要があります。(Microsoft Learn)
BGPとオンプレミス接続で確認すべきこと
VPN GatewayやExpressRouteを利用している環境では、BGPによってオンプレミス側の経路がAzureのサブネットに伝播されます。BGPで学習したルートは、サブネットの有効ルートに追加され、Virtual network gatewayを次ホップとして扱われます。(Microsoft Learn)
ここで注意すべきなのは、オンプレミス側から細かすぎる経路を大量に広告すると、Azure側のルート管理が複雑になることです。公式情報でも、オンプレミス ルートは可能な限り大きなアドレス範囲に集約し、Azure仮想ネットワーク ゲートウェイへ伝播するルート数を減らすことが推奨されています。また、Azureからオンプレミスへ広告するプレフィックスについては、summarizedGatewayPrefixesプロパティを使って集約プレフィックスを広告する方法も説明されています。(Microsoft Learn)
BGP設計では、次の3点を必ず確認してください。
| 確認項目 | 理由 |
|---|---|
| GatewaySubnetでルート伝播を無効化していないか | GatewaySubnetで無効にするとゲートウェイが機能しなくなる可能性があります。 |
| オンプレミスから細かすぎる経路を広告していないか | ルート数増加により管理が複雑になり、上限や障害調査に影響します。 |
| UDRとBGPルートの重複がないか | 同じプレフィックスではUDRがBGPより優先されるため、想定外の経路になる場合があります。 |
ExpressRoute、VPN Gateway、Route Server、Virtual WANを併用する構成では、「Virtual network gateway」という次ホップの意味が環境によって変わります。特にUDRのNext hop type VirtualNetworkGatewayは、VPN Gatewayの場合にのみサポートされる前提があるため、ExpressRouteやRoute Server、Virtual WANを含む構成では、公式仕様に沿って確認する必要があります。(Microsoft Learn)
Azure Virtual Network Managerを使うべきケース
スポークVNetが多い環境では、ルート テーブルを手作業で管理するとミスが増えます。スポーク追加時にUDRを入れ忘れる、削除済みVNetのルートが残る、リージョンごとに命名や次ホップがずれる、といった問題が起こりやすくなります。
Azure Virtual Network ManagerのUDR管理では、ネットワーク グループに対してルーティング構成を展開し、必要なUDRを一元的に作成・維持できます。公式情報では、UDR管理によりルート テーブルごとに最大1,000個のUDRを作成できること、競合ルールがある場合はサポートされないこと、既存ルート テーブルを使う場合とAVNM管理ルート テーブルを使う場合で挙動が異なることが説明されています。(Microsoft Learn)
次の条件に当てはまるなら、Azure Virtual Network Managerの利用を検討する価値があります。
- スポークVNetが数十以上ある
- リージョンごとにハブ＆スポークを展開している
- すべてのスポークからFirewallやNVAを経由させたい
- 新しいVNet追加時にルート設定を自動反映したい
- 手作業のルート テーブル更新を減らしたい
- セキュリティ管理ルールや接続構成もまとめて管理したい
ただし、AVNMを使っても、設計の矛盾は解決されません。宛先が同じで次ホップが異なるルール、既存UDRと競合するルール、ネットワーク グループの重複などは、展開前に整理しておく必要があります。
管理者が今すぐ確認すべき設定
まず確認すべきなのは、ルート テーブルそのものではなく「有効ルート」です。ルート テーブルにはUDRしか表示されない場合がありますが、実際の通信では、システム ルート、BGPルート、UDRが組み合わさって評価されます。
Azure CLIでは、NICに適用されている有効ルートを次のコマンドで確認できます。(Microsoft Learn)
az network nic show-effective-route-table -g <resource-group-name> -n <nic-name>確認結果では、次の項目に注目してください。
| 見るべき項目 | 確認内容 |
|---|---|
| Source | Default、User、Virtual network gatewayのどれか |
| Address prefix | 宛先プレフィックスが想定どおりか |
| Next hop type | Internet、Virtual appliance、Virtual network gateway、Noneなど |
| State | UDR追加により既定ルートがInvalidになっていないか |
| Next hop IP | NVAやInternal Load BalancerのIPが正しいか |
| サブネット関連付け | ルート テーブルが正しいサブネットにだけ関連付けられているか |
点検は、次の順番で進めると効率的です。
- 本番VNet、検証VNet、ハブVNet、スポークVNetを一覧化する
- 各サブネットに関連付くルート テーブルを確認する
- 代表VMのNICで有効ルートを出力する
0.0.0.0/0の次ホップを確認する- BGP由来のオンプレミス ルートを確認する
- サービス エンドポイントやPrivate Endpointの有無を確認する
- NAT Gateway、Azure Firewall、NVAの優先関係を確認する
- プライベート サブネットで明示的なアウトバウンド方式があるか確認する
- 変更前後でNetwork WatcherやFirewallログを比較する
移行・展開時の注意点
ルーティング変更は、アプリケーションの停止よりも分かりにくい障害を引き起こします。通信が完全に切れるだけでなく、「特定の宛先だけ遅い」「戻り通信だけ失敗する」「Azureサービスだけ接続できない」「OS更新だけ失敗する」といった症状になることがあります。
安全に展開するには、次の手順をおすすめします。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 事前調査 | 有効ルート、NSG、Firewallポリシー、BGPルートを取得 | 変更前の通信経路を説明できる状態にする |
| 設計 | 0.0.0.0/0、オンプレミス宛て、Azureサービス宛ての経路を分ける | どの通信を検査し、どの通信を直接出すか明確にする |
| 検証 | 検証サブネットでUDR、NAT Gateway、NVAを適用 | 名前解決、OS更新、外部API、Azureサービス接続を確認 |
| 段階展開 | 影響の小さいサブネットから適用 | ルート変更後の有効ルートとログが想定どおり |
| 監視 | Network Watcher、Firewallログ、アプリログを確認 | 接続失敗、タイムアウト、非対称ルーティングを検出 |
| ロールバック | 変更前のルート テーブル関連付けに戻す | 復旧手順を事前に手順化しておく |
特にIaCで展開している環境では、APIバージョンやサブネットのdefaultOutboundAccessの扱いを確認してください。2026年3月31日以降のAPIでは、新しいVNetのサブネットが既定でプライベートになるため、暗黙のアウトバウンド接続を前提にしたテンプレートは見直しが必要です。一方で、古いAPIバージョンを明示するテンプレートやツールでは、従来の挙動が残る場合があるため、環境ごとの差分にも注意が必要です。(Microsoft Learn)
よくある失敗パターン
ルート テーブルだけを見て判断する
ルート テーブルにはUDRは表示されますが、システム ルートやBGPルートを含めた最終的な経路は、有効ルートで確認する必要があります。障害調査では、ルート テーブルではなくNICの有効ルートを見ることを基本にしてください。
NVAのIP forwardingを忘れる
UDRで次ホップをNVAにしても、NVAのNICやOS側でIP転送が有効でなければ、通信は期待どおりに転送されません。NVAを経由する構成では、Azure側のNIC設定とアプライアンス側の設定をセットで確認します。
サービス タグを使いすぎる
UDRのサービス タグは便利ですが、ルート テーブルごとの上限があります。Azureサービスごとに細かく例外を作りすぎると、管理しづらくなります。Private Endpointやサービス エンドポイントで設計した方がよい通信もあるため、用途ごとに分けて判断してください。
GatewaySubnetに一般サブネットと同じルートを適用する
GatewaySubnetはVPN GatewayやExpressRoute Gatewayのための特殊なサブネットです。一般のワークロード用サブネットと同じルート テーブルを使い回すと、ゲートウェイの動作に影響する可能性があります。
NAT Gatewayを追加しただけで経路が変わると思い込む
NAT Gatewayは強力なアウトバウンド方式ですが、0.0.0.0/0をNVAやGatewayへ向けるUDRがある場合、そのUDRが優先されます。NAT Gateway導入時は、必ず有効ルートで実際の次ホップを確認してください。
まず実施すべきアクション
Azure virtual network traffic routingを見直す際は、いきなりルートを変更するのではなく、現在の通信経路を棚卸ししてください。
最初に実施すべきことは、次の3つです。
- 代表VMのNICで有効ルートを取得し、
0.0.0.0/0、オンプレミス宛て、Azureサービス宛ての次ホップを確認する - すべてのサブネットについて、ルート テーブル、NAT Gateway、NVA、GatewaySubnet、プライベート サブネット設定を一覧化する
- 今後新規作成するVNetやサブネットでは、明示的なアウトバウンド接続を設計に含める
上限引き上げにより、大規模なAzureネットワークは設計しやすくなりました。一方で、ルート数を増やせることと、運用しやすいことは別問題です。UDR、BGP、NAT Gateway、Azure Firewall、サービス エンドポイント、Private Endpointを用途ごとに整理し、変更前後の有効ルートを確認しながら展開することが、安定したAzure Networking運用の近道です。
コメント