Service Endpoint vs Private Endpointを理解するための前提
Microsoft Learnはsecure/private PaaS accessの一般推奨としてPrivate Link/Private Endpointを案内している。要件が合う限り新規設計の基準点にする。 Service Endpointはsubnet identityをAzure serviceへ拡張し、serviceのpublic endpoint/DNS modelを維持する。DNSは引き続きpublic IPを返す。
Private Endpointはconsumer VNet内にservice instance/subresource用private IPを持ち、DNSをそのprivate IPへ解決させる。 classic Service Endpointはon-premisesからVNet service endpointとして直接利用するmodelではない。Private EndpointはVPN/ExpressRoute等でprivate IPへ到達できればon-premisesから利用できる。
Service Endpoint有効化後、Azure serviceから見えるsourceはVNet private address/identityへ切り替わり、effective routeにはVirtualNetworkServiceEndpointが現れる。 Service Endpointは追加料金がなくDNS変更も小さい一方、Private Endpointはendpoint/DNS運用とコストが増える。security、on-prem、instance-level isolation要件で比較する。
Control plane / DNS plane / Data plane
subnet → Azure service public endpoint。service firewallでVNet/subnet identityを許可。DNS answerはpublic IPのまま。
client → VNet内PE private IP → Private Link → specific service instance/subresource。Private DNSが重要。
どちらもAzure backbone上のoptimized pathを使えるが、addressing/identity/authority/on-prem reachabilityのmodelが異なる。
Query / packet path
- 要件を「private IPが必要か」「on-premから必要か」「public endpointを残せるか」「instance単位exfiltration controlが必要か」で分類する。
- Service Endpointならsource subnetでservice endpointを有効化し、PaaS側VNet ruleを設定する。client FQDNはpublic IPを解決し続ける。
- Private Endpointならtarget subresourceにPEを作成し、Private DNS zone/zone groupでFQDNをprivate IPへ解決する。
- どちらもactual source/destination、effective route、service firewall/authorizationを確認する。
- migration時はexisting TCP session、source IP semantics、DNS cache/public accessを含めて切替検証する。
仕組みを分解する
Service Endpointの「private」はprivate IP destinationを作る意味ではありません。public service endpointへ向かうrouteをAzure backboneへ最適化し、service側にVNet identityを伝える仕組みです。一方Private EndpointはVNet内private IPがdestinationになります。この差がDNS、on-premises access、UDR inspection、service instance granularity、troubleshooting手順を大きく変えます。比較時は「Internetを通らない」だけで同じ技術として扱わないことが重要です。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Private IP/on-prem required | 必要ならPrivate Endpointを優先。on-prem clientはPE private IPへroute + DNS forwardingを構成できる。 |
| Simple subnet restriction | 対応serviceでAzure VNet内subnetからだけ許可し、public endpoint modelを維持できるならService Endpointも候補。 |
| Data exfiltration | resource instance単位のprivate destinationとbuilt-in exfiltration protection要件ではPrivate Endpointが有利。Service Endpoint policy等を使う別設計と比較する。 |
| Operations/cost | Service Endpointは追加endpoint/DNS管理が少ない。Private EndpointはIP capacity、DNS zone group、PE resource lifecycle、料金を運用へ組み込む。 |
確認手順
Read-only verification
- Service EndpointではFQDNがpublic IPのままでも正常。effective routeのVirtualNetworkServiceEndpointとservice firewallのsource/VNet ruleを確認する。
- Private EndpointではFQDN最終answerがPE private IPであること、Approved connectionとservice authを確認する。
- on-prem requirementがある場合は同一FQDNをon-premからquery/接続し、Private Endpoint pathを実証する。
- migration比較は同じapplication transactionでbefore/afterのdestination IP、route、service log、latency/errorを保存する。
Evidence to keep
- resource ID / subscription / region / VNet / subnetを固定し、同名resource取り違えを防ぐ。
- DNS queryはresolver IP、query name、answer/CNAME、TTL、timestampを一緒に保存する。
- network testはsource、resolved destination IP、protocol/port、winning route/security decisionを保存する。
- 変更前後で同じquery/application journeyを再実行し、cache/既存sessionでの見かけ上成功を避ける。
# Service Endpoint side
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query "serviceEndpoints" -o jsonc
az network nic show-effective-route-table -g <rg> -n <source-nic> -o table
# Private Endpoint side
az network private-endpoint show -g <rg> -n <private-endpoint> -o jsonc
az network private-endpoint dns-zone-group list -g <rg> --endpoint-name <private-endpoint> -o jsonc
nslookup <service-fqdn>Get-AzVirtualNetwork -ResourceGroupName <rg> -Name <vnet> | Select-Object -ExpandProperty Subnets
Get-AzPrivateEndpoint -ResourceGroupName <rg> -Name <private-endpoint>
Get-AzPrivateDnsZoneGroup -ResourceGroupName <rg> -PrivateEndpointName <private-endpoint>障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| Service Endpointなのにprivate IPを期待 | model誤認 | DNS answer/effective route | public destination + service endpoint routeとして確認 |
| PEなのにpublic IPへ接続 | Private DNS不足 | CNAME/A chain | Private DNS/forwarding修正 |
| on-premからService Endpoint resource不可 | classic SEのscope | source path/service firewall | PEまたはpublic/NAT allow設計を検討 |
| SE有効化直後にfirewall deny | source IP semantics変化 | service diagnostics | VNet rule/private source対応 |
| PE inspectionが0/0で効かない | PE /32 longest prefix | effective route | PE network policy + specific UDR |
変更時の確認と rollback
- Service Endpoint enable/disableはexisting TCP connectionが切れる可能性があるためchange windowで実施する。
- SE→PE migrationではPrivate DNSを先にpilotし、public access disableはPE positive test後に行う。
- PE→SE rollbackではDNS private answer/cacheを確実に戻し、service VNet ruleを先に準備する。
- rollback完了はFQDN answer、winning route、service responseの3点で確認する。
Current notes — 2026-09-11
Microsoft LearnのService Endpoint overviewは2026-07-08更新で、Private Link/Private Endpointをsecure/private access向けに推奨しつつ、classic Service Endpointに加えてStandard service endpoint Public Previewも案内しています。このページではplanの対象であるclassic Service EndpointとPrivate Endpointの差を中心にし、Standard service endpointは別機能として注記します。