Azure

Azure Private Endpoint vs Service Endpoint: Complete Comparison of Secure PaaS Connectivity Patterns

2026-05-24
NicheeLab Editorial Team

When you need secure access from VNet resources to Azure PaaS services (Storage Account, SQL Database, Cosmos DB, Key Vault, etc.), you have two patterns to choose from: Private Endpoint and Service Endpoint. This article compares how each works, their cost, security characteristics, and the scenarios they fit — and walks through the correct way to use Private Endpoint, which has become the modern best practice.

Side-by-Side Comparison of the Two Patterns

ItemService EndpointPrivate Endpoint
CategoryControls outbound traffic from the VNetPlaces the PaaS service in the VNet as a private IP
Public endpointRemains (firewall allows only VNet traffic)Can be disabled (fully private)
IP typePaaS keeps its public IPPrivate IP (address from the VNet)
PricingFree$0.01/h ≈ ¥700/month + data transfer
Name resolutionStandard public DNSRequires Private DNS Zone
On-premises accessNot supported (VNet only)Supported (via VPN/ExpressRoute)
NSG supportSupportedSupported (Network Policy must be enabled)
ComplianceLimitedStrong (data not exposed)
Recommendation (2026)Low (legacy scenarios)High (best practice)

How Service Endpoint Works

Service Endpoint routes outbound traffic from a subnet in your VNet to specific Azure PaaS services over the Azure backbone. On the PaaS side, you configure a firewall rule that says "allow only traffic from this VNet/subnet," which keeps the PaaS public endpoint in place while delivering effective network isolation.

How traffic flows

  1. Enable a Service Endpoint on the subnet (e.g., Microsoft.Storage)
  2. On the PaaS service (Storage Account), configure a firewall rule to allow access only from this VNet/subnet
  3. Access from a VM in the VNet to the Storage Account is routed over the Azure backbone
  4. The source IP reaches the PaaS as the subnet's public IP (a Service Endpoint quirk)

Pros and cons

  • Pros: free, easy to configure, and works in legacy environments
  • Cons: the PaaS public endpoint remains (DDoS exposure), no direct on-premises access, and it is hard to prove for compliance that data never leaves the organization's network

How Private Endpoint Works

Private Endpoint places the Azure PaaS service inside the VNet as a private IP. The PaaS service effectively becomes a VNet member; under the hood, the connection runs through the Microsoft-operated Private Link Service to reach the PaaS resource.

How traffic flows

  1. Create a Private Endpoint in the VNet (e.g., assign private IP 10.0.1.4 to the Storage Account)
  2. Link a Private DNS Zone (e.g., privatelink.blob.core.windows.net) to the VNet
  3. Disable the Storage Account's public endpoint
  4. A DNS query from a VM in the VNet for mystorageaccount.blob.core.windows.net resolves to the private IP (10.0.1.4)
  5. VM → private IP 10.0.1.4 → Storage Account, end-to-end over a fully private path

Pros and cons

  • Pros: you can disable the PaaS public endpoint (zero internet exposure), reach the service directly from on-premises via VPN/ExpressRoute, strengthen compliance posture, and align with zero-trust principles
  • Cons: paid (about ¥700/month per service + data transfer), requires Private DNS Zone design, requires enabling Network Policy on the subnet, and consumes IP addresses

Private DNS Zone and Name Resolution

Name resolution for Private Endpoint is handled by a dedicated Private DNS Zone. Each service has a specific zone name.

ServicePrivate DNS Zone name
Storage (Blob)privatelink.blob.core.windows.net
Storage (File)privatelink.file.core.windows.net
Storage (Data Lake Gen2)privatelink.dfs.core.windows.net
Azure SQL Databaseprivatelink.database.windows.net
Cosmos DB (NoSQL)privatelink.documents.azure.com
Key Vaultprivatelink.vaultcore.azure.net
App Serviceprivatelink.azurewebsites.net
Container Registryprivatelink.azurecr.io
Azure AI Searchprivatelink.search.windows.net

When you create the Private Endpoint, setting the Integrate with private DNS zone option to Yes will automatically create the matching Private DNS Zone, link it to the VNet, and register the A record. When multiple VNets share the same Private DNS Zone, the standard design is to consolidate it in a hub VNet.

Resolving from On-Premises

To access a Private Endpoint from an on-premises environment, you need to design the DNS resolution path.

  • Pattern A (simple): register the Private Endpoint's FQDN with its private IP directly as an A record on the on-prem DNS server. Manual to operate; brittle as resources change.
  • Pattern B (recommended): deploy an Azure DNS Private Resolver inbound endpoint in the VNet, configure a conditional forwarder on the on-prem DNS to that inbound endpoint's IP, and let the Private DNS Zone resolve the names.
  • Pattern C (DNS Forwarder VM): stand up a DNS forwarder VM (BIND, etc.) inside the VNet and forward from on-prem DNS. A legacy pattern from before Azure DNS Private Resolver shipped.

Integration with NSG / Firewall

NSG support for Private Endpoint rolled out gradually starting in 2021 and is now available in all GA regions.

  • Enable Private Endpoint Network Policies on the subnet (disabled by default — you must enable it explicitly)
  • Apply an NSG to the subnet to control traffic to the Private Endpoint by IP/port
  • Use a UDR to set the next hop for the Private Endpoint to Azure Firewall, routing traffic through the firewall
  • Delivering traffic from Application Gateway / Front Door to a Private Endpoint requires combining with Private Link Service

Supported Services

As of 2026, nearly every major Azure PaaS service supports Private Endpoint.

  • Storage: Blob / File / Queue / Table / Data Lake Gen2
  • Database: SQL DB / Managed Instance / Cosmos DB / PostgreSQL / MySQL
  • Compute: App Service / Functions / Container Apps / AKS Private Cluster
  • Container: Azure Container Registry
  • Security: Key Vault / Managed HSM
  • Messaging: Event Hub / Service Bus / Event Grid
  • AI / Search: Azure AI Search / Azure AI Foundry / Azure OpenAI / Azure Machine Learning
  • Data: Synapse Analytics / Data Factory / Microsoft Purview / Microsoft Fabric
  • Operations: Azure Monitor (Private Link Scope) / Automation / Backup / Site Recovery
  • Configuration: App Configuration

Private Endpoint Limitations

  1. Each Private Endpoint occupies 1-3 private IPs in the VNet, which impacts IP address planning.
  2. Unless you explicitly enable Private Endpoint Network Policies on the subnet, NSG and UDR will not apply to the Private Endpoint.
  3. Once created, a Private Endpoint cannot be moved to another subnet — you must delete and recreate it.
  4. Some services use a connection approval workflow that requires the PaaS resource owner to approve the request (when set to Manual Approval).
  5. Cost: $0.01/h × 730h ≈ ¥700/month + data transfer. Watch the running total if you plan to create many Private Endpoints.

Which Should You Choose?

Selection guide for new projects in 2026:

  • Security / compliance focused: Private Endpoint is the only choice. Required for GDPR, HIPAA, PCI DSS, and APPI.
  • On-premises access required: Private Endpoint is the only choice. Service Endpoint only works from inside the VNet.
  • Cost minimization is the top priority: consider Service Endpoint (¥700/month × dozens of services adds up).
  • New PaaS service that does not yet support Private Endpoint: use Service Endpoint as a temporary measure and migrate once Private Endpoint support lands.

Related Certifications

Frequently Asked Questions

What's the difference between Private Endpoint and Service Endpoint?

Service Endpoint routes outbound traffic from a VNet to a PaaS service over the Azure backbone. The PaaS service keeps its public endpoint, and a firewall rule restricts access to traffic from the designated VNet. Private Endpoint, by contrast, places the PaaS service inside the VNet as a private IP — effectively making the PaaS resource a VNet member. Service Endpoint is free, simple, and leaves the public endpoint exposed. Private Endpoint is paid (about $0.01/h, roughly ¥700/month plus data transfer), uses a private IP, and lets you disable the public endpoint entirely. In recent years Private Endpoint has become the best-practice default; Service Endpoint is positioned as a legacy option.

Why is Private Endpoint recommended?

Private Endpoint wins on three fronts: security, compliance, and operations. 1) Security: the PaaS service is fully isolated as a private IP inside the VNet, and you can disable the public endpoint to eliminate internet exposure. 2) Compliance: for GDPR, HIPAA, PCI DSS, and similar regulations, you can prove that data never leaves the organization's network. 3) Operations: on-premises access reaches the Private Endpoint directly through VPN/ExpressRoute, making hybrid environments seamless. Microsoft itself recommends Private Endpoint, and choosing it by default for new projects is the industry standard.

How does name resolution work with Private Endpoint?

When you create a Private Endpoint, the public DNS name of the corresponding Azure service (e.g., <strong>mystorageaccount.blob.core.windows.net</strong>) needs to resolve to the private IP. This is handled by a Private DNS Zone (e.g., <strong>privatelink.blob.core.windows.net</strong>), which can be auto-configured when the Private Endpoint is created. Linking the VNet to the Private DNS Zone makes DNS queries inside the VNet resolve to the Private Endpoint's private IP. For on-premises access, the standard pattern is to configure a conditional forwarder on your on-prem DNS toward Azure DNS (168.63.129.16) and resolve the Private DNS Zone through the inbound endpoint of Azure DNS Private Resolver.

Which Azure services support Private Endpoint?

As of 2026, nearly every major Azure PaaS service supports Private Endpoint. Representative services include Azure Storage (Blob / File / Queue / Table / Data Lake), Azure SQL DB, Azure SQL Managed Instance, Cosmos DB, Key Vault, Azure App Service (App Service Plan), Azure Functions, Azure Container Registry, Azure AI Search, Azure Synapse Analytics, Azure Data Factory, Microsoft Purview, Azure Backup, Azure Site Recovery, Azure Event Hub, Azure Service Bus, Azure Cache for Redis, Azure App Configuration, Azure Monitor (Private Link Scope), Azure Machine Learning, Azure OpenAI, and Microsoft Fabric. Microsoft ships almost all new PaaS services with Private Endpoint support at GA, so confirming Private Endpoint availability up front is essential.

How does Private Endpoint interact with NSG / Firewall?

NSG support for Private Endpoint rolled out gradually from 2021 and is now available in all GA regions. Applying an NSG at the subnet level lets you control traffic to the Private Endpoint by IP, port, and protocol. To capture access logs by routing through Azure Firewall, design routing through the hub VNet's firewall (use a UDR to set the next hop toward the Private Endpoint to the firewall). When accessing a Private Endpoint via Application Gateway or Front Door, you can combine it with Private Link Service — an important pattern in modern zero-trust designs.

What are the limitations of Private Endpoint?

Key limitations: 1) Each Private Endpoint occupies 1-3 private IPs inside the VNet, which impacts IP address planning. 2) Placing a Private Endpoint in a subnet changes some NSG/UDR behavior in that subnet with special rules. 3) NSG and UDR will not apply to a Private Endpoint unless you explicitly enable Private Endpoint Network Policies on the subnet (disabled by default). 4) Once created, a Private Endpoint cannot be moved to another subnet — you must delete and recreate it. 5) Some services use a connection approval workflow that requires the PaaS resource owner to approve the request (when set to Manual Approval). 6) Cost: $0.01/h × 730h ≈ ¥700/month plus data transfer. The total adds up quickly if you create many Private Endpoints.

When should you still use Service Endpoint?

Service Endpoint is still a reasonable choice in these scenarios: 1) cost minimization is the top priority (you want to avoid ¥700/month × N services from Private Endpoint), 2) leaving the PaaS public endpoint exposed is acceptable (firewall locks it to VNet-only traffic), 3) a legacy service does not yet support Private Endpoint, 4) maintaining existing Service Endpoint deployments. For new projects with strict security or compliance requirements, Private Endpoint is the only choice — but for small to mid-sized cost-sensitive projects, Service Endpoint is still valid. Microsoft has not announced a deprecation timeline for Service Endpoint, so the two continue to coexist.

Which certification exams cover these topics?

AZ-700 (Network Engineer Associate) tests Private Endpoint and Service Endpoint in depth, with frequent questions on design decisions, name resolution, and NSG integration. You'll also see them on AZ-104 (Administrator) Domain 4 for fundamentals, AZ-305 (Solutions Architect Expert) for architect-level selection, SC-300 (Identity Admin) for identity integration scenarios, DP-300 (DBA) for applying Private Endpoint to SQL DB / MI, and SC-100 (Cybersecurity Architect Expert) in the context of zero-trust network design. For any engineer working with Azure, understanding Private Endpoint and Service Endpoint is an essential skill.

Related articles and deep dives

Azure DNS / Private DNS Zones / Private Resolver 完全ガイド|ハイブリッド DNS 設計【2026 年版】

Azure DNS (Public)・Private DNS Zones・Azure DNS Private Resolver の完全ガイド。3 サービスの使い分け、Private Endpoint との統合、Conditional Forwarding、オンプレからの解決パターン、DNSSEC、設計の落とし穴、関連認定試験 (AZ-700 / AZ-305) を日本語で網羅。

Azure Managed Identity vs Service Principal 完全比較|認証パターンの選定と実装ベストプラクティス【2026 年版】

Azure の認証エンティティ Managed Identity と Service Principal を完全比較。System-assigned / User-assigned の使い分け、Client Secret vs Certificate vs Workload Identity Federation の選定、AKS Workload Identity、Azure サービス対応状況、関連認定試験 (SC-300 / AZ-204 / AZ-400) を日本語で網羅。実装パターン集付き。

Azure Architect キャリアロードマップ|AZ-900 → AZ-305 → SC-100 シニアアーキテクトへの道【2026 年版】

Azure Solutions Architect になるための認定取得ロードマップ完全版。AZ-900 → AZ-104 → AZ-305 の王道ルート、AZ-400 / SC-100 / AZ-700 との二刀流 / 三刀流戦略、マルチクラウド対応 (AWS / GCP)、未経験から 7-12 ヶ月の学習プラン、年収レンジまで日本語で網羅。

Azure セキュリティエンジニア キャリアロードマップ|SC-900 → SC-200/300/400 → SC-100 シニアへの道【2026 年版】

Azure セキュリティエンジニアになるための認定取得ロードマップ完全版。SC-900 → SC-200/300/400 のいずれか → SC-100 / SC-500 の王道ルート、ロール別の優先順序、CISSP との二刀流戦略、SC-500 (旧 AZ-500 後継、2026-09 GA 予定) の動向、10-15 ヶ月の学習プラン、年収レンジまで日本語で網羅。

The technical information in this article is based on the Azure Private Link Documentation. This article is not an official Microsoft Corporation product and has no affiliation or sponsorship with Microsoft. Microsoft and Azure are trademarks of the Microsoft group of companies. Information is based on publicly available official material as of May 24, 2026. Always check the official pages for the latest information.

Check what you learned with practice questions

Practice with certification-focused question sets

View Azure exam prep page
Author

NicheeLab Editorial Team

NicheeLab editorial team focused on data engineering and cloud certification learning. Content is structured around practical study needs and official exam domains.


Related articles
Azure

AZ-900 Azure Fundamentals: Complete Exam Guide (2026)

Pass AZ-900 — cloud concepts, Azure architecture, management...

Azure

Azure Certification Roadmap: Which Cert to Take Next (2026)

Choose your Azure certification path — Fundamentals, Associa...

Azure

AI-901 Azure AI Fundamentals (Beta): Complete Guide (2026)

Pass AI-901 — Microsoft Foundry, generative AI, responsible ...

Azure

Microsoft Entra ID Fundamentals for Azure Certs (2026)

Entra ID basics every cert candidate needs — tenants, identi...

Azure

DP-900 Azure Data Fundamentals: Complete Guide (2026)

Pass DP-900 — relational, non-relational, analytics, Power B...

Browse all Azure articles (104)
© 2026 NicheeLab All rights reserved.