Azure Private Endpoint

Azure Private Endpointを理解するための前提

Private EndpointはVNetのprivate IPを使うnetwork interfaceで、Azure Private Link対応serviceの特定subresourceへ接続する。 Private EndpointはVNetと同じregion/subscriptionに配置する一方、接続先private-link resourceは別regionでもよい。

connection stateはApproved/Pending/Rejected/Disconnectedを持ち、data trafficを送れるのはApprovedな接続。同じprivate-link resourceへ複数PEを作成できるが、共通DNSを使う単一networkでは重複PEがDNS conflictを作らないか設計する。

VNet/peered VNetに加えて、VPN/ExpressRoute等でprivate IPへ到達できるon-premises clientからも利用できる。 Private EndpointのIPへ届くこととservice FQDNがそのIPへ解決されることは別条件。applicationは通常FQDNを使うためDNSをacceptanceに含める。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Resource object

Microsoft.Network/privateEndpoints。subnet、privateLinkServiceConnections、groupIds、connection stateを保持。

NIC / IP

lifecycleに紐づくread-only NICとprivate IPがconsumer VNet側のdata-plane destinationになる。

Service binding

resource ID + target subresource(groupId)が「どのserviceのどの機能へ繋ぐか」を決め、owner approvalで有効化される。

判定順序まず client がどの resolver を使い何IPを得たか固定し、そのIPに対するroute/securityを確認します。DNSを確認せずroute tableだけを見る、またはprivate IPを得ただけでservice到達済みと判定するのは避けます。

Query / packet path

作成時にtarget resourceとtarget subresource、subnet、approval方式を指定する。
AzureがPE用NIC/private IPをconsumer VNetへ作り、private-link resource側にconnectionを作成する。
自動またはmanual approvalでconnectionがApprovedになる。
DNS zone groupまたは手動DNS設計によりservice FQDNがPE private IPを返す。
clientは通常のservice FQDNへ接続し、VNet routing/securityを通ってPEへ到達する。
Private Link mappingによりserviceの指定subresourceへtrafficが渡される。

仕組みを分解する

Private Endpointのresource stateを見るだけでは、実際にapplicationがそのendpointを利用しているかは分かりません。PE作成後もpublic DNS answerが残ればclientはpublic endpointを選び得ます。またtarget subresourceが誤っていれば「private IPへのTCP接続はできるが必要なAPIだけ失敗する」といったservice固有の症状が出ます。resource ID、groupId、private IP、DNS answer、actual connection destinationを一続きで記録します。

設計判断

判断軸	設計方針
Subnet placement	PE専用/共有subnetを決め、IP capacity、network policy、UDR/NSG適用方針を先に固定する。
Approval model	cross-subscription/tenantや権限不足でmanual approvalになる運用を想定し、Pendingを障害と誤認しない。
IP management	serviceのstatic IP supportやIPAM方針をcurrent service docsで確認。DNSはIP直書きではなくzone group/lifecycle管理を優先する。
Redundancy	multi-region serviceで複数PEを使う場合、endpoint数ではなくDNS answer/failover behaviorとapplication retryまで設計する。

確認手順

Read-only verification

PortalのPrivate Endpoint > Overview/Connectionsでconnection stateとtarget subresourceを確認する。
PEのprivate IP/NICを取得し、client側DNS answerと一致するか確認する。
sourceごとにTest-NetConnection/curl等でFQDN接続し、実際のdestination IP/HTTP status/service logを記録する。
on-premises利用ではPE subnetへのrouteだけでなくDNS conditional forwarding先とTCP/UDP 53到達も確認する。

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での見かけ上成功を避ける。

Azure CLI / client — read-only first

az network private-endpoint show -g <rg> -n <private-endpoint> -o jsonc
az network private-endpoint ip-config list -g <rg> --endpoint-name <private-endpoint> -o jsonc
az network private-endpoint dns-zone-group list -g <rg> --endpoint-name <private-endpoint> -o jsonc
az network nic list -g <rg> --query "[?contains(name, '<private-endpoint>')]" -o table

PowerShell — read-only first

$pe = Get-AzPrivateEndpoint -ResourceGroupName <rg> -Name <private-endpoint>
$pe.PrivateLinkServiceConnections
Get-AzPrivateDnsZoneGroup -ResourceGroupName <rg> -PrivateEndpointName <private-endpoint>

障害切り分け

症状	第一候補	証拠	次の確認
Pendingのまま	manual approval待ち/権限境界	connection stateとresource owner側request	ownerが意図したrequestか確認して承認
Approvedだが名前解決public	DNS未統合	FQDNのCNAME/A chain	zone group/zone link/forwarder
private IPへrouteなし	peering/VPN/ER/UDR	effective route/route table	network path修正
特定APIだけ失敗	groupId/subresource不足	PE connection groupIdsとservice docs	必要subresource用PE/DNSを追加
削除後もprivate IPへ向く	stale DNS/cache/manual record	zone recordとTTL/client cache	zone group lifecycle/record cleanup

変更時の確認と rollback

private IP、NIC ID、connection resource ID、groupIds、zone groupをexportしてから変更する。
PE再作成はIP/DNS recordが変わり得るため、applicationがIP固定していないか先に確認する。
manual approvalを解除/PE削除する場合はservice owner側connection stateも追跡する。
rollback後はFQDN、actual TCP destination、service responseの3点を同じclientから再試験する。

Current notes — 2026-09-11

Current behavior / guidance

Private Endpointは現在、private IP version/static configurationなどservice/CLI側の選択肢が増えています。全serviceが同じsupport matrixではないため、汎用PE仕様と対象service固有のPrivate Link documentationを分けて確認します。