Private Subnet / Explicit Outboundを理解するための前提
2026-03-31以降にリリースされたAPI versionでは、新規VNetのsubnetはdefaultOutboundAccess=falseが既定。 private subnetではVMのdefault outbound IP生成を抑止し、Internet/public Microsoft endpointへはexplicit outbound methodが必要。
explicit outboundの代表はNAT Gateway、Standard Load Balancer outbound rules、public IP、Azure Firewall/NVAへ向けるUDRなど。 nonprivate subnetではexplicit outboundが存在してもdefault outbound IPが割り当てられている場合があるが、explicit methodが優先されている間はそれがegressに使われるとは限らない。
default outbound IPを完全に除去するにはprivate subnet化に加え、対象VMのstop/deallocateが必要になるケースがある。 outbound designでは「到達できるか」だけでなくsource public IP、SNAT capacity、logging、failover、deny policyを契約化する。
Control plane と data plane
仕組み
implicit default outboundはMicrosoft-owned public IPに依存し、addressが予告なく変わり得るためdeterministic allowlistに不向き。
private subnet + NAT Gatewayならsubnet-levelでexplicit SNATを提供し、unsolicited inboundを開かずにegress identityを固定できる。
central Firewall/NVA egressならUDRでnext hopをinspection pointへ向ける。routeだけでなくSNAT、DNS、return path、platform dependencyを確認する。
migrationではexisting connectionが旧SNAT stateを保持する場合があるため、新規TCP connectionでsource IP/routeを確認する。
Packet path
routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。
- source workloadがpublic destinationへ接続開始。
- subnetのroute selectionで0.0.0.0/0等のnext hopを決定。
- NAT Gateway/Firewall/NVA/LBなどexplicit outbound componentでSNAT/inspection。
- public destinationへ送信。
- responseが同じtranslation/stateへ戻りprivate sourceへ復元。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Preferred default | NAT Gatewayを一般的なdirect Internet egressの第一候補にする。 | managed SNAT、stable public IP、subnet-level運用。 |
| Central inspection | policy/loggingが要件ならFirewall/NVA経由を設計。 | routingとsecurityをcentralizeできるがsymmetry/DNS/HAを追加検証。 |
| Migration | default outboundから一気に切らずdependency listとtest vectorを作る。 | Windows Update等、見えにくいpublic dependencyを漏らさない。 |
| Acceptance | public source IP、next hop、allowed/denied destination、failoverを実測。 | portalのassociationだけではegress behaviorを証明しない。 |
確認手順
Azure Portal
- VNet → Subnets → 対象subnetのPrivate subnet設定を確認。
- subnetのNAT gateway / Route table / Load Balancer/public IP依存を確認。
- Network Watcher + external echo endpoint/approved test destinationでsource IPとreachabilityを確認。
Verification discipline
- subscription / resource group / resource IDを記録する。
- 同じsource・destinationでbefore/afterを比較する。
- read-only evidenceを保存してから変更する。
- control-plane successとapplication successを別々に判定する。
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query "{defaultOutboundAccess:defaultOutboundAccess,natGateway:natGateway,routeTable:routeTable}" -o jsonc
az network nat gateway list -g <rg> -o table$vnet = Get-AzVirtualNetwork -ResourceGroupName <rg> -Name <vnet>
$vnet.Subnets | Select-Object Name,DefaultOutboundAccess,NatGateway,RouteTable障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 新規VNetだけInternet不可 | private subnet default | defaultOutboundAccess=false + explicit egressなし | NAT/Firewall等を設計 |
| allowlistでsource IPが想定外 | implicit/default SNATや別egress path | effective route + observed source public IP | explicit outboundへ統一 |
| private化したのにalert/default IPが残る | VMがdeallocateされていない/legacy state | subnet propertyとVM lifecycle | maintenance windowでstop/deallocate後再確認 |
| Firewall経由で一部serviceだけ失敗 | FQDN/DNS/platform dependency漏れ | Firewall logs/DNS/route | dependency allowlistを根拠付きで補完 |
変更時の確認と rollback
- migration前に外向きdependency、source IP allowlist、SNAT volume、critical job時刻を記録。
- new egress pathを先に作成してからsubnet association/UDRを切替。
- new connectionsでsource IPとdeny/allowを確認。
- rollbackは元associationだけでなくexisting state/NAT tableとVM lifecycleも考慮。
What changed recently
2026-03-31以降のAPIでは新規VNetのsubnetがprivate既定。既存VNetは自動変更されないため、「新旧環境で同じIaCに見えるのにoutbound behaviorが違う」状況に注意する。