Service Tagsを理解するための前提
Service TagはAzure serviceのIP prefix群を論理名で表し、Microsoftがprefix変更を管理する。 NSG、Azure Firewall、UDRなど対応resourceでexplicit IP listの代替として利用できる。
tagはservice identity/authenticationではなくIP prefix abstraction。アプリ認証やPrivate Linkを置き換えない。 regional tagとglobal tagがあり、必要以上に広いtagはblast radiusを増やす。
UDRではservice tagをaddress prefixにでき、route tableあたりservice-tag route数に上限がある。 on-prem firewallでservice tag相当を使う場合はService Tag Discovery API/公開JSONの更新運用が必要。
Control plane と data plane
仕組みと設計上の意味
tag名は「Microsoft serviceへの信頼」を意味せず、IP範囲の管理をAzureへ委ねる仕組み。
NSGのservice tagとUDRのservice tagは目的が違う。前者はallow/deny、後者はnext-hop選択。
Storageなどregional variantがある場合は必要regionへ狭める。
private endpoint使用時はprivate IP data pathが主となるため、public service tag ruleの必要性を再評価する。
Packet / decision path
source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。
- 対象flowのsource/destination serviceを特定。
- 利用可能なtagとregional scopeを確認。
- NSG/Firewall/UDRのどこでtagを使うか分離。
- effective route/securityで実packetに適用されるruleを確認。
- 定期reviewではtag名の妥当性と不要なbroad allowを確認。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Global vs regional | 利用可能ならregionalへ限定 | 不要regionへの到達を抑える |
| NSG vs UDR | securityとroutingを別ruleとして設計 | tagの意味を混同しない |
| Private access | Private Link要件ならtag allowだけに依存しない | public endpoint exposureを残さない |
| On-prem | 自動更新pipelineを用意 | 手作業IP listはdriftしやすい |
確認手順
Azure Portal
- NSG/Route table/Firewall policyでtag名とpriorityを確認。
- Microsoft LearnのAvailable service tagsでscopeを確認。
- 代表NICのeffective rule/routeで実際のdecisionを検証。
Evidence contract
az network list-service-tags --location <region> -o jsonc
az network nsg rule list -g <rg> --nsg-name <nsg> -o table
az network route-table route list -g <rg> --route-table-name <rt> -o tableGet-AzNetworkServiceTag -Location <region>
Get-AzNetworkSecurityGroup -ResourceGroupName <rg> -Name <nsg>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 想定serviceへ通らない | regional tag/priority不一致 | effective NSG + destination IP | tag scopeとrule order確認 |
| 意図外serviceへ通る | global tagが広すぎる | rule scope | regional tag/Private Linkへ絞る |
| UDRでunexpected next hop | explicit prefixとtag route競合 | effective route | longest prefix/route preference確認 |
| on-premで古いprefix | JSON/API更新停止 | download timestamp/version | 自動更新とvalidationを復旧 |
変更・rollback
- rule変更前にcurrent effective rules/routesを保存。
- broad tagからnarrow tagへ変更する場合はdependency inventoryを取る。
- rollbackはpriorityも含めて元ruleを復元。
- on-prem prefix更新はstaged deployとdiff reviewを行う。