Public IP Addressを理解するための前提
Basic SKU Public IPは2025-09-30にretire済み。新規/継続設計はStandardを前提にする。 Standard public IPv4/IPv6はstatic allocation。Standard v2は対応regionで常にzone-redundant。
public IPの存在はinbound許可を意味しない。NSG、LB/AppGW/Firewall等のlistener/ruleを別に確認する。 inbound frontend IPとoutbound SNAT identityは別概念。NAT GatewayやFirewall egressを混同しない。
zone propertyは作成後に変更できないため、migrationは新resource作成とcutoverが基本。 DNS/allowlistでIP固定が必要な場合はresource lifecycle、prefix、failover手順まで設計する。
Control plane と data plane
仕組みと設計上の意味
public IP単体は「Internetからresourceへ通す」ruleではなく、frontend identityを提供するresource。
Standardではsecure-by-defaultの設計を取り、NSGやfrontend ruleがない限り到達性を別途作る。
zone-redundant/zonalの選択は関連serviceのzone設計と合わせる。
outboundをpublic IP attached NICへ依存させず、NAT Gateway/Load Balancer outbound/Azure Firewall等のexplicit egressを選ぶ。
Packet / decision path
source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。
- Public IPのSKU/zone/関連resourceをinventoryする。
- 関連frontend/listener/NAT ruleを確認する。
- source→public IPのsecurity/routing pathを確認する。
- DNS TTL/allowlist依存を確認する。
- migration時は新Standard IPで並行検証後にDNS/frontendを切替える。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| SKU | Standard(v1/v2)を使用 | Basicはretire済み |
| Zone | service topologyと一致するzone-redundant/zonal | 障害domainを明示 |
| Inbound | managed frontend + WAF/NSG等と組合せる | IPだけではsecurityにならない |
| Outbound | explicit egress serviceへ分離 | SNAT identityとscaleを管理しやすい |
確認手順
Azure Portal
- Public IP addresses → SKU / IP / Availability zone / Associated to を確認。
- 関連するLB/AppGW/Firewall側でfrontend configを照合。
- DNS recordと外部allowlistがどのIPを参照しているか確認。
Evidence contract
az network public-ip show -g <rg> -n <pip> -o jsonc
az network public-ip list -g <rg> -o tableGet-AzPublicIpAddress -ResourceGroupName <rg> -Name <pip> | Format-List
Get-AzPublicIpAddress -ResourceGroupName <rg> | Select Name,IpAddress,PublicIpAllocationMethod,Sku,Zones障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| IPはあるが接続不可 | frontend/listener/NSG不足 | 関連resource + NSG | public IPとservice ruleを分離確認 |
| migration後に一部clientだけ旧IP | DNS/recursive cache | dig/nslookup複数resolver | TTL経過とauthoritative answer確認 |
| zone設計が合わない | 既存PIPのzone immutable | PIP zone + service zone | 新PIPで再作成 |
| outbound IPが想定外 | inbound PIPをSNAT identityと誤認 | effective egress IP | NAT/LB/Firewall outboundを確認 |
変更・rollback
- Basic→Standardは関連resource compatibilityを確認して正式手順で移行。
- DNS切替前にTTLを計画し、旧frontendを即時削除しない。
- allowlist更新は新旧IPのoverlap windowを設ける。
- rollback条件を「health probe失敗」「5xx増加」などobservableに定義。