Network security in Azure often comes down to one critical question: how do you lock down access to PaaS services like Azure Storage, SQL Database, or Key Vault? Microsoft gives you two primary tools — Service Endpoints and Private Endpoints — and choosing the wrong one can leave gaps in your security posture or add unnecessary complexity to your architecture.

In this post, I'll break down both options from an architect's perspective, compare them head-to-head, and walk through a real-world scenario so you can make an informed decision.

What Are Azure Service Endpoints?

A Service Endpoint extends your Virtual Network (VNet) identity to an Azure PaaS service over the Azure backbone network. When you enable a service endpoint on a subnet, traffic from that subnet to the target service (e.g., Microsoft.Storage) travels over Microsoft's private backbone instead of the public internet — but the service's public IP is still used as the destination.

How It Works

  1. You enable a service endpoint on a VNet subnet (e.g., Microsoft.Storage).
  2. Azure updates the effective routes on that subnet — traffic destined for the service is routed through the Azure backbone.
  3. On the PaaS service side, you configure a firewall rule to allow only traffic from that specific subnet.
  4. Traffic originates from the VNet's private IP space, but the destination is still the service's public endpoint.

Key Characteristics

  • Free — no additional cost beyond standard networking charges.
  • Easy to configure — enabled in minutes via the Azure portal, CLI, or ARM template.
  • Subnet-scoped — applies to all resources in the subnet.
  • Public IP destination — the PaaS resource's public endpoint remains active; it's just restricted via firewall rules.
  • No DNS change — the service resolves to its public IP; only routing changes.
  • On-premises access not covered — traffic from on-premises (via VPN/ExpressRoute) does NOT benefit from the service endpoint by default.

What Are Azure Private Endpoints?

A Private Endpoint is a network interface with a private IP address from your VNet that connects directly to an Azure PaaS service. Under the hood, it uses Azure Private Link to map the PaaS resource into your VNet as if it were a native VM or NIC.

How It Works

  1. You create a Private Endpoint resource in your VNet, linked to a specific PaaS service instance.
  2. Azure provisions a NIC in your subnet with a private IP (e.g., 10.0.1.10).
  3. Azure Private DNS zones (e.g., privatelink.blob.core.windows.net) are updated so the service's FQDN resolves to the private IP inside your VNet.
  4. Traffic never leaves the Microsoft network — not even to the backbone in the service endpoint sense. The service is fully private.
  5. The public endpoint can be completely disabled on the PaaS resource.

Key Characteristics

  • Paid — there is a per-hour charge per private endpoint plus data processing fees.
  • Resource-scoped — you get a private IP for one specific resource instance (e.g., one storage account).
  • Works from on-premises — with proper DNS configuration, on-premises clients via VPN or ExpressRoute can resolve and reach the service over the private IP.
  • DNS-dependent — requires correct Private DNS Zone configuration; misconfiguration leads to resolution failures.
  • Public endpoint can be disabled — strongest security posture, completely eliminating the public attack surface.
  • Supports network policies — NSGs and UDRs can be applied to private endpoint subnets (with the PrivateEndpointNetworkPolicies flag).

Service Endpoints vs Private Endpoints: Side-by-Side Comparison

Feature Service Endpoint Private Endpoint
Traffic path Azure backbone (public IP destination) Fully private (private IP in VNet)
Private IP in VNet No Yes
Public endpoint disabled No (restricted only) Yes (optional)
On-premises access Not supported Supported (with DNS)
Cost Free Per-endpoint + data charges
DNS changes required No Yes (Private DNS Zone)
NSG support No (on endpoint subnet) Yes (with policy flag)
Scope Subnet-wide (all resources) Per PaaS resource instance
Setup complexity Low Medium–High
Best for Dev/test, simple workloads Production, regulated environments

When to Use Service Endpoints

Service Endpoints are appropriate when:

  • You have a dev or test environment and need a quick, cost-effective way to restrict PaaS access.
  • All client traffic originates within Azure VNets (no on-premises access needed).
  • Your security policy permits the PaaS service to have a public endpoint (restricted by subnet firewall rules).
  • You need to lock down access from a specific subnet to Azure Storage or SQL quickly.
  • Budget is a constraint and the workload does not handle sensitive regulated data.

When to Use Private Endpoints

Private Endpoints are appropriate when:

  • You are deploying production workloads with strict compliance requirements (PCI-DSS, HIPAA, ISO 27001).
  • You need on-premises systems to privately access Azure PaaS services.
  • You want to completely disable the public endpoint on your storage account, SQL server, or Key Vault.
  • You need to apply NSG rules or UDRs to control traffic to/from the PaaS service.
  • You are operating in a hub-and-spoke or Azure Virtual WAN topology where centralized DNS resolution is required.
  • You are working with Azure Kubernetes Service (AKS) or App Service that needs secure backend connections to PaaS services.

Real-World Case Study: Financial Services Data Platform

Background

A mid-sized financial services company was migrating its on-premises data warehouse to Azure. The architecture included:

  • Azure SQL Managed Instance for transactional data.
  • Azure Blob Storage (ADLS Gen2) for raw and processed data files.
  • Azure Key Vault for secrets and certificate management.
  • On-premises data center connected via ExpressRoute.
  • Analytics workloads running in a dedicated analytics VNet peered to the hub VNet.

The security team's requirements were non-negotiable:

  1. No PaaS resource should be accessible over the public internet.
  2. On-premises ETL tools must reach Azure Storage and Key Vault.
  3. All traffic must be auditable and flow through the hub for inspection.
  4. The solution must pass a PCI-DSS Level 1 audit.

Initial Attempt: Service Endpoints

The first architect on the project proposed using Service Endpoints on the analytics subnet pointing to Microsoft.Storage and Microsoft.KeyVault. Access was then locked down via storage firewall rules and Key Vault network ACLs to only allow the analytics subnet.

Problems encountered:

  1. On-premises ETL tools couldn't reach storage or Key Vault — Service Endpoints don't extend to on-premises clients over ExpressRoute by default.
  2. The auditor flagged the public endpoint as open — even though subnet-restricted, the storage account's public FQDN still resolved to a public IP, which the PCI auditor treated as a non-compliant exposure.
  3. NSG rules couldn't be applied to the storage-bound traffic from the subnet, making traffic inspection partial.

Solution: Private Endpoints with Hub-and-Spoke DNS

The architecture was redesigned using Private Endpoints:

  1. Private Endpoints created in the hub VNet for:

    • Azure Blob Storage (ADLS Gen2): 10.0.4.4
    • Azure Key Vault: 10.0.4.5

  2. Public access disabled on both the storage account and Key Vault — completely removing the public attack surface.

  3. Azure Private DNS Zones configured:

    • privatelink.blob.core.windows.net → 10.0.4.4
    • privatelink.vaultcore.azure.net → 10.0.4.5
    • DNS zones linked to both the hub VNet and the analytics spoke VNet.

  4. On-premises DNS forwarded queries for *.blob.core.windows.net and *.vault.azure.net to Azure DNS via a DNS forwarder VM in the hub — resolving the ExpressRoute access problem.

  5. NSGs applied to the private endpoint subnet in the hub, logging all accepted/denied flows to Log Analytics.

Results

  • PCI-DSS audit passed — no public endpoints, private IP resolution, and full NSG flow logs.
  • On-premises ETL tools successfully reached storage and Key Vault over ExpressRoute via private IPs.
  • Zero-trust posture achieved — traffic was inspectable, routable, and auditable end-to-end.
  • The added cost of private endpoints (~$14/month per endpoint) was negligible compared to compliance risk.

Architecture Diagram (Conceptual)

On-Premises (ExpressRoute)
        │
        ▼
  [Hub VNet]
  ┌──────────────────────────────────┐
  │  DNS Forwarder VM (10.0.1.4)     │
  │  Azure Firewall                  │
  │  Private Endpoint NIC – Storage  │ ← 10.0.4.4
  │  Private Endpoint NIC – KV       │ ← 10.0.4.5
  └──────────────────────────────────┘
        │ VNet Peering
        ▼
  [Analytics Spoke VNet]
  ┌──────────────────────────────────┐
  │  ADF Self-Hosted IR              │
  │  Databricks Compute Clusters     │
  └──────────────────────────────────┘

DNS Resolution:
  storage.blob.core.windows.net
       → privatelink.blob.core.windows.net
       → 10.0.4.4  (private IP, not public)

Common Mistakes to Avoid

1. Forgetting to Update DNS for Private Endpoints

If you create a Private Endpoint but don't configure the Private DNS Zone (or link it to the VNet), clients will still resolve the public IP and bypass the private endpoint entirely. Always validate DNS resolution with nslookup or Resolve-DnsName from inside the VNet.

2. Enabling Both Service Endpoints and Private Endpoints on the Same Subnet

This creates a routing conflict. If you migrate from Service Endpoints to Private Endpoints, disable the service endpoint on the subnet after the private endpoint is operational and DNS is confirmed working.

3. Not Disabling the Public Endpoint

Creating a Private Endpoint does NOT automatically disable public access. You must explicitly set publicNetworkAccess: Disabled on the storage account, SQL server, or Key Vault to eliminate the public attack surface.

4. Assuming Service Endpoints Work Over ExpressRoute

A common misconception. Service Endpoints only apply to traffic originating from within the VNet subnet. On-premises traffic arriving via ExpressRoute does not use the service endpoint path — you need Private Endpoints for that.

5. Ignoring Private Endpoint Network Policies

By default, NSGs and UDRs are not enforced on private endpoint subnets. You must enable PrivateEndpointNetworkPolicies on the subnet to apply NSG rules and route private endpoint traffic through Azure Firewall or an NVA.

Decision Framework: Quick Reference

Use this quick checklist to decide:

Choose Service Endpoints if ALL of the following are true:

  • All clients are within Azure VNets (no on-premises access needed)
  • You don't need to disable the PaaS public endpoint
  • Cost is a priority and the workload is non-regulated
  • You need a fast, low-complexity implementation

Choose Private Endpoints if ANY of the following are true:

  • On-premises systems need access to the PaaS service
  • Compliance requires the public endpoint to be disabled
  • You need NSG/UDR enforcement on PaaS-bound traffic
  • You operate in a regulated industry (finance, healthcare, government)
  • The service hosts sensitive data that must never traverse public paths

Summary

Both Service Endpoints and Private Endpoints help you secure Azure PaaS services — but they operate at fundamentally different levels of isolation. Service Endpoints are a lightweight, routing-based control that restrict which subnets can reach a service over the Azure backbone. Private Endpoints are a full network-level integration that bring the PaaS service into your VNet with a private IP, support on-premises access, and allow you to completely eliminate public exposure.

For production workloads, regulated environments, or any architecture requiring on-premises connectivity to PaaS, Private Endpoints are the right choice. For simpler, VNet-only scenarios where cost and speed matter more than deep isolation, Service Endpoints remain a valid option.

As Azure continues to expand Private Link support across more services, the architectural recommendation is clear: default to Private Endpoints for new production deployments, and plan Service Endpoint migrations where compliance or zero-trust requirements demand it.