Routing & TransitReviewed 2026-09-10

Service Tags in UDR

UDR address prefixにservice tagを使い、Azure service IP変更への追従負荷を減らす。

Scope: 設計・運用で誤りやすい点を優先して整理。SKU/region/limitsは変更されるため、実装時はリンク先のcurrent Microsoft Learnを再確認してください。

Overview

UDR address prefixにservice tagを使い、Azure service IP変更への追従負荷を減らす。

Key technical points

  • explicit IP prefixとのexact matchでは明示prefixが優先される。
  • route tableあたりservice tag route数など制限があるため大量設計時はlimitsを確認する。
  • security policyとrouting policyで同じtagを使っても意味は異なる。

Design guidance

  • routeは「設定値」ではなくNICから見たeffective stateで検証する。
  • longest prefix、route source、propagation、peering、BGPを順に確認する。
  • stateful NVAを通す場合は往路だけでなくreturn pathとSNAT有無を必ず設計する。

Operations checklist

  1. 対象NICのeffective route tableを取得する。
  2. destinationごとにNext Hopを確認する。
  3. NVA/BGP peerのlearned/advertised routesと往復経路を確認する。

Common pitfalls

  • UDRだけ見てBGP/system/peering routeを無視する。
  • return pathを設計せずstateful NVAでdropする。

Verification pattern

Control plane
resource state、association、policy、route/BGP configが期待通りかを確認。
Data plane
同一5-tupleまたは実application journeyで到達性・latency・security判定を実証。
Observability
diagnostic logs / flow logs / Network Watcherで実際の判定とpathを残す。
Rollback
設定を戻した後のroute convergence、DNS cache、existing sessionまで確認。

Official sources