Service endpoints vs private endpoints
Verdict: A service endpoint switches the subnet's source to the VM private IP, but DNS still resolves the service public IP and there is no charge. A private endpoint creates a NIC with a stable private IP in the subnet.
| Criterion | Service endpoint | Private endpoint |
|---|---|---|
| Source IP effect | Subnet traffic uses the VM private IPv4 address as its source | Consumer connects inbound to a private IP inside the subnet |
| DNS behaviour | Entries still resolve to the service public IP; no DNS change needed | Needs a private DNS zone record pointing at the endpoint IP |
| Network object | Subnet-level toggle; no interface created | Auto-created read-only NIC holds a stable private IP for the endpoint lifecycle |
| Cost and model | No additional charge; Azure Resource Manager virtual networks only | Billed per endpoint; targets a specific Private Link resource |
| Reaches on-premises | No; endpoints cannot carry on-premises traffic | Yes, once DNS and routing resolve the private IP |
Rules
- Enabling a service endpoint makes subnet traffic use the VM private IP as source, so an existing IP network rule permitting that subnet stops matching.
- Under service endpoints, DNS entries for the Azure service still resolve to its public IP, so applications need no DNS change; there is also no additional charge.
- Enabling a service endpoint and adding a virtual network rule secures the account to the subnet because storage now sees the VM private IPv4 source.
- A private endpoint auto-creates a read-only NIC whose private IP stays unchanged for the endpoint lifecycle, so DNS records can safely point at it.
Traps
- A service endpoint does not delete IP network rules; the rules simply stop matching that subnet's now-private source traffic.
- Service endpoints introduce no NAT or gateway address; the source becomes the VM's own private IP, not a shared or reserved address.