Service Tags in UDR

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。

Service Tags in UDRを理解するための前提

UDRはaddress prefixにservice tagを指定でき、Microsoft管理のservice IP変更へ自動追従できる。 route tableごとにservice tagを使うroute数には上限があるため、大量tag設計はlimitsを確認する。

explicit IP prefixとservice-tag routeが同一prefixで一致する場合、explicit prefix routeが優先される。複数service tagがmatchingする場合はregional tag等の評価順序がある。

Service Tag UDRはrouting controlであり、NSG/Firewallのallow/denyを置き換えない。 container等のrouting scenarioでもservice tag routeが利用可能だが、actual destination IPとeffective routeで検証する。

通信や判断の流れを追う

SourceEffective routeNext hopDestinationReturn path

Control plane と data plane

Control planeRoute tableへservice tag prefixとnext hopを設定しsubnetへassociateする。

Data planepacket destination IPがtag current prefixに一致した時、UDR route selectionへ参加しnext hopが決まる。

仕組みと設計上の意味

tag名だけ見てrouteを判断せず、effective routeのactual prefix/source/next hopを確認する。

Azure platform serviceへFirewall/NVA経由を強制する場合、そのservice dependencyがapplianceで正しく処理されるか確認する。

regional/global tagの選択でtraffic pathとcost/blast radiusが変わる。

Private Endpoint trafficはprivate IP宛なのでpublic service tag UDRとは別pathになる。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

対象service/destination IPを確認。
tag routeとexplicit prefix routeをinventory。
source NIC effective routeでwinning routeを確認。
NVA/Firewall next hop healthとallow ruleを確認。
service endpoint/Private Endpoint併用時はDNS/destination IPを再確認。

設計判断

判断点	推奨	理由
Tag scope	regional tagを優先検討	routing範囲を狭める
Next hop	Internet/NVA等を目的で明示	security intentと一致させる
Explicit overlap	明示prefixの存在をreview	unexpected preferenceを防ぐ
Private Endpoint	private routeとして別設計	service tagに依存しない

確認手順

Azure Portal

Route table → RoutesでAddress prefix type/tagとnext hopを確認。
Subnet associationを確認。
NIC Effective routesで実際のresolved routeを確認。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。

Before / After同じsource・destination・protocol・portで比較。

Effective state設定値だけでなくeffective route/security/health/logを取得。

Runtimecontrol-plane Succeededとapplication successを分けて判定。

Azure CLI — read-only first

az network route-table route list -g <rg> --route-table-name <rt> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o table
az network list-service-tags --location <region> -o jsonc

PowerShell — read-only first

Get-AzRouteTable -ResourceGroupName <rg> -Name <rt>
Get-AzEffectiveRouteTable -NetworkInterfaceName <nic> -ResourceGroupName <rg>

障害切り分け

症状	疑う点	証拠	次の確認
tag routeが選ばれない	explicit prefix/longer prefixが優先	effective routes	matching prefixを比較
service通信がapplianceで落ちる	NVA/Firewall未許可	appliance logs	service tag/rule確認
Private Endpointへ影響しない	destinationがprivate IP	DNS + effective route	期待pathを再定義
route数上限	tag route過多	route table count/limits	設計集約

変更・rollback

変更前にroute tableとeffective routeをexport。
service tag→explicit prefixへ戻すrollback pathを用意。
NVAへsteerする変更はhealth/scaleを先に検証。
rollback後にdestination IPを再resolveしてnew flowを確認。