Azure Networking Explained: VNet Peering, Service Endpoints, Private Link & Private Endpoints

To understand these four concepts, it helps to think of them as different ways to build "roads" between your private network and other destinations. Each one solves a different problem — and picking the wrong one will either leave traffic on the public internet or leave your resources unreachable from on-premises. That's the kind of thing that bites you after a deployment.

1. VPC Peering (Virtual Network Peering)

VNet Peering is like building a highway between two separate cities (networks). It connects two Virtual Networks (VNets) so that resources in one can talk to resources in the other as if they were on the same network.

• •Scope: Full connectivity. Every VM in VNet A can talk to every VM in VNet B (unless blocked by a firewall).
• •IP Addressing: Both networks must have non-overlapping IP address spaces. Overlapping ranges will prevent peering from being established — plan your address space before you deploy anything.
• •Best For: Connecting your Development environment network to your Production environment network.

VNet A (10.0.0.0/16)  <──── Peering ────>  VNet B (10.1.0.0/16)
  VM-A1, VM-A2                               VM-B1, VM-B2

---

2. Service Endpoint

A Service Endpoint is a "shortcut" for specific Azure services (like Storage or SQL). It keeps your traffic on the Azure backbone network instead of the public internet, but the destination still uses its public IP address.

• •How it works: It overrides your subnet's existing routing table by injecting a more specific route for that Azure service. Instead of following the default 0.0.0.0/0 → Internet route, traffic destined for the service is redirected through the Azure backbone.
• •Limitation: It only works for traffic originating inside the Azure VNet. You cannot use a Service Endpoint to reach a database from your physical office via VPN — this trips people up more often than you'd think.
• •Best For: Simple, cost-effective security for resources that only need to be accessed by Azure VMs.

VM in VNet  ──── Azure Backbone (not internet) ────>  Azure Storage (public IP)

---

3. Private Link (The "Unblocker" & Mapping Engine)

Private Link is the underlying Software-Defined Networking (SDN) engine. It's the "permission" layer that makes 1-to-1 private connectivity possible.

• •The Action (Unblocking): It carves a private "back door" into a specific resource (like your SQL server). It "unblocks" the instance from the public world and projects it toward your network.
• •The Concept: Think of it as the "projector." It creates a 1-to-1 secure mapping between the service and your VNet.
• •The "Consent": This is just the configuration on the resource side. At this stage, there is no IP address.

---

4. Private Endpoint (The "Integration" & Private IP)

A Private Endpoint is the "physical presence" or the "arrival gate." It's the actual Network Interface (NIC) that puts the resource inside your network.

• •How it works (Integration): It takes the "unblocked" resource (provided by Private Link) and gives it a Private IP address from your local subnet (e.g., 10.0.1.5).
• •The Role: If Private Link is the "tunnel," the Private Endpoint is the "door" in your basement where the tunnel ends. Your VMs talk to this door (the IP).
• •Scope (The Superpower): Because it has a local IP, it's reachable from anywhere that can reach that VNet — including peered VNets and on-premises offices via VPN. This is what Service Endpoints can't do.

On-premises (VPN)  ─┐
Azure VM           ─┼──>  Private Endpoint (10.0.1.5)  ──>  SQL Database
Peered VNet        ─┘       (Actual IP in your subnet)

---

5. Important: Locking the Front Door

Simply enabling Private Link does not automatically turn off public internet access — and this is where a lot of people get burned.

• •Private Link adds a private "back door."
• •You must manually "lock the front door" by disabling Public Network Access in the resource's firewall settings. If you don't, the public IP is still active and reachable from anywhere.

---

6. Quick Comparison

---

Questions

1. •Does your setup require access from an on-premises office or just within Azure?
2. •Have you disabled "Public Network Access" on your resource after setting up the Private Endpoint?