Azure Private Access Options: Comparison

Posted on | In |

A practical comparison of Azure private networking options: VNet Service Endpoints, Private Endpoints, Private Link Service, and VNet Integration. When to use each, limitations, and a quick decision matrix.

1. VNet Service Endpoints

What it is: Extends your VNet's private address space and identity to Azure PaaS services over the Azure backbone network. The service is still accessed via its public IP, but traffic stays on Azure's backbone (never hits the internet).

How it works:

  • Enabled at the subnet level
  • Azure PaaS resource's firewall is configured to allow traffic only from that subnet
  • The PaaS resource still has a public IP — it's just restricted to your VNet

Use when:

  • Simple setup, no DNS changes needed
  • You want to restrict access to a PaaS service from specific subnets
  • Cost-sensitive (free)
  • On-premises access via VPN/ExpressRoute is not required (traffic can't route from on-prem through service endpoints)

Limitations:

  • PaaS resource retains its public IP (some compliance regimes don't allow this)
  • Only works from the configured VNet/subnet — no on-prem reach
  • No cross-region support (VNet and PaaS must be in same region, with some exceptions like Storage/SQL paired regions)

2. Azure Private Endpoints

What it is: A NIC in your VNet with a private IP from your subnet, mapped to a specific instance of a PaaS resource. Traffic goes entirely over private IP.

How it works:

  • Creates a network interface in your subnet with a private IP (e.g., 10.0.1.5)
  • DNS resolution for the PaaS resource (e.g., mystorageaccount.blob.core.windows.net) resolves to that private IP via Private DNS Zone
  • The PaaS resource's public endpoint can be disabled entirely

Use when:

  • Compliance requires no public IP on the PaaS resource
  • You need access from on-premises via VPN/ExpressRoute (private IP is routable)
  • You need cross-region access (Private Endpoint in Region A can connect to PaaS in Region B)
  • You need granular access to a specific resource instance (e.g., one specific Storage Account, not all Storage Accounts)

Limitations:

  • Costs money (per-hour NIC charge + data processing charge)
  • Requires Private DNS Zone configuration (adds complexity)
  • NSG support was added later; UDR support has nuances

What it is: Lets you expose your own service (behind a Standard Load Balancer) to other consumers via Private Endpoint. This is the provider side of Private Endpoint.

How it works:

  • You deploy your app behind a Standard Load Balancer
  • You create a Private Link Service attached to that LB
  • Consumers in other VNets/subscriptions/tenants create a Private Endpoint that connects to your Private Link Service
  • Traffic flows: Consumer VNet → Private Endpoint → (Azure backbone) → Private Link Service → Your LB → Your app

Use when:

  • You're a service provider (ISV, shared platform team) exposing a service to consumers
  • Consumer and provider can be in different VNets, subscriptions, or even AAD tenants
  • You want NAT'd connectivity — consumer doesn't see your internal IPs, you don't see theirs
  • SaaS multi-tenant scenarios

Limitations:

  • Only works with Standard Load Balancer (not Application Gateway, etc.)
  • Provider must approve consumer connections (manual or auto-approval)
  • One-directional: consumer initiates, provider receives

4. VNet Integration (App Service / Functions)

What it is: Allows Azure App Service / Functions to make outbound calls into your VNet. The app gets a virtual presence in your subnet.

How it works:

  • App Service delegates to a dedicated subnet in your VNet
  • Outbound traffic from the app can now reach private resources in the VNet (VMs, Private Endpoints, on-prem via VPN/ER)
  • Inbound traffic is NOT affected — the app still receives traffic via its public endpoint (use Private Endpoint separately for private inbound)

Use when:

  • Your App Service / Function needs to call a database, VM, or other resource inside a VNet
  • You need outbound access to on-prem resources through VPN/ExpressRoute
  • Combined with Private Endpoints: VNet Integration (outbound) + Private Endpoint (inbound) = fully private App Service

Limitations:

  • Outbound only — does not make the app privately accessible (use Private Endpoint for that)
  • Requires a dedicated subnet (can't share with VMs or other delegated resources)
  • Only for App Service / Functions (not a general-purpose feature)

Quick Decision Matrix

Requirement Service Endpoint Private Endpoint Private Link Service VNet Integration
Direction VNet → PaaS VNet → PaaS Consumer VNet → Your service App Service → VNet
Public IP removed? No Yes N/A (your LB) No (outbound only)
On-prem reachable? No Yes Yes N/A (outbound)
Cross-region? Limited Yes Yes Same region
Cross-tenant? No No Yes No
Cost Free ~$7.30/mo + data ~$7.30/mo + data Free (or plan-dependent)
DNS changes needed? No Yes Yes (consumer side) No
Granularity Whole service type per subnet Specific resource instance Specific service Subnet-level

TL;DR — When to Pick What

  • “I want to restrict Storage/SQL access to my VNet, cheaply” → Service Endpoints
  • “I need fully private access with no public IP, works from on-prem” → Private Endpoints
  • “I'm exposing my own service to other teams/customers privately” → Private Link Service
  • “My App Service needs to call stuff inside my VNet” → VNet Integration

In practice, most production architectures use Private Endpoints as the default for PaaS access, with VNet Integration layered on for App Service outbound, and Private Link Service only when you're building a shared/SaaS platform.