Academmia

Public and Private Endpoints in Azure

az-900•mixed•

Azure architecture and services

Public and Private Endpoints in Azure

Short Summary

An endpoint is the network entry point (usually a hostname) your app uses to reach an Azure service. A public endpoint is reachable over the public internet, while a private endpoint gives the service a private IP address inside your Virtual Network (VNet) using Azure Private Link. In this lesson, you’ll learn how to tell them apart, what DNS changes to expect, and how to choose the right option for a real scenario.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define what an endpoint represents for an Azure service.
  • Differentiate a public endpoint from a private endpoint.
  • Explain how Azure Private Link and private endpoints change routing and name resolution.
  • Choose an endpoint approach based on connectivity and exposure requirements.
  • Identify common misconceptions that cause “it works on my machine” networking surprises.

Core Concepts

An endpoint is the “door” your client uses to reach a service. In practice, you typically connect to a Fully Qualified Domain Name (FQDN) (for example, myservice.contoso.com or myserver.database.windows.net). The Domain Name System (DNS) resolves that name to an Internet Protocol (IP) address, and your client connects to that IP.

Public endpoint

A public endpoint is reachable using a public IP address on the public internet.

Key ideas:

  • The service is reachable from anywhere in principle (internet-routable).

  • You can still secure it heavily using:

    • Authentication and authorization,
    • Service firewall rules (for example, allow only specific public IP ranges),
    • Network controls like “Public network access” settings (when supported by the service).

  • “Public endpoint” does not mean “wide open.” It means the address is internet-routable unless you restrict it.

Private endpoint

A private endpoint is a Network Interface (NIC) placed in a subnet in your VNet and assigned a private IP address from that VNet. That NIC connects privately to the Azure service using Azure Private Link.

Key ideas:

  • Clients in your VNet (and connected networks, such as peered VNets or on-premises via Virtual Private Network (VPN) / ExpressRoute) can reach the service using a private IP.
  • DNS often needs attention: the usual service hostname should resolve to the private IP of the private endpoint (often done with a private DNS zone).
  • A private endpoint provides a private way to reach the service, but it doesn’t automatically mean the service’s public endpoint is disabled. Many services let you explicitly disable public access if you want to go “private-only.”

Service endpoints (common source of confusion)

Virtual network service endpoints are a different feature from private endpoints:

  • Service endpoints keep the service on its normal endpoint, but provide secure, direct connectivity over the Azure backbone and let you restrict the service to traffic from specific subnets.
  • Service endpoints do not place a private IP for the service into your VNet like private endpoints do.
  • If you need the service to be reachable via a private IP inside your VNet, you’re in private endpoint territory.

Practical Understanding

Situation 1: “My app runs in a VNet and must reach Storage, but the service must not be exposed publicly.”

A private endpoint is usually the clean fit. Create a private endpoint in the app’s subnet (or a dedicated subnet), then configure DNS so the Storage hostname resolves to the private endpoint’s private IP. If the service supports it and your requirement is “private-only,” disable public network access for the resource.

Common misunderstanding: “If I create a private endpoint, public access is automatically off.” It isn’t. You typically need to explicitly restrict/disable public access at the service level if you want private-only.

Situation 2: “A partner on the internet needs to call my API, but internal systems should use a private path.”

You can use both: keep the public endpoint for partner access (protected by authentication and service/network controls) and add a private endpoint for internal traffic. This lets internal workloads avoid the public internet path while still supporting legitimate external users.

Common misunderstanding: “I must pick either public or private, never both.” In many designs, using both is normal: public for external clients, private for internal workloads.

Situation 3: “I want to restrict Azure SQL so only a specific subnet can reach it, but I’m not ready to manage private DNS.”

Service endpoints can be an option for supported services: enable the service endpoint on the subnet, then configure the service to allow only that VNet/subnet. It’s simpler operationally than private endpoints in some environments, but it’s not the same as giving the service a private IP in your VNet.

Common misunderstanding: “Service endpoints create a private endpoint-like private IP.” They don’t. Service endpoints secure access to the service from a subnet; they don’t inject a private IP for the service into your VNet.

Situation 4: “I created a private endpoint, but my app still connects to the public IP.”

This usually points to DNS. The app is still resolving the service hostname to the public IP instead of the private endpoint’s IP. Fix DNS (often via a private DNS zone) so the same hostname resolves privately for your VNet-connected clients.

Common misunderstanding: “Routing should ‘just know’ to use the private endpoint.” Your client follows DNS. If DNS points to the public IP, it’ll use the public endpoint.

Common Pitfalls

  • Mistake: Thinking “private endpoint” means “same service, but over the internet with encryption.” Correction: A private endpoint gives the service a private IP in your VNet through Azure Private Link, so the connection doesn’t traverse the public internet path.

  • Mistake: Creating a private endpoint but forgetting DNS. Correction: Ensure the service FQDN resolves to the private endpoint’s private IP for clients in the VNet (commonly via private DNS zones).

  • Mistake: Assuming public access is automatically disabled when a private endpoint exists. Correction: If your goal is “private-only,” explicitly restrict or disable public network access on the resource (when supported).

  • Mistake: Mixing up private endpoints and service endpoints. Correction: Private endpoints = private IP (NIC) in your VNet via Private Link. Service endpoints = secure access from a subnet to a service over Azure backbone, without placing a private IP for the service in your VNet.

  • Mistake: Assuming “private” means “only my current VNet can ever reach it.” Correction: Private endpoints can be reachable from peered VNets and on-premises networks too—if routing and DNS are set up accordingly.

Check Your Understanding

  1. In your own words, what does “public” refer to in “public endpoint”?
  2. Describe a scenario where you’d keep a public endpoint but still add a private endpoint for internal traffic.
  3. What would you check first if a private endpoint exists but your app still seems to connect “publicly”?
  4. How would you explain the difference between a service endpoint and a private endpoint to a teammate?
  5. When would disabling “public network access” be appropriate, and what else must be true for your apps to keep working?

Further Reading