Azure Private Endpoint vs Service Endpoint: The Azure Interview Question Everyone Gets Wrong

In this blog, we will cover:

1. Private Endpoint

2. Important related terminologies to Private Endpoint and their meaning

3. Service Endpoint

4. Important related terminologies to Service Endpoint and their meaning

5. Difference between Private Endpoint and Service Endpoint

6. Two hands-on lab

   a) End-to-end lab on private Endpoint

   b) End-to-end lab on Service Endpoint

7. Troubleshooting/FAQs

𝐄𝐯𝐞𝐫 𝐰𝐨𝐧𝐝𝐞𝐫𝐞𝐝 𝐡𝐨𝐰 𝐀𝐳𝐮𝐫𝐞 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬 𝐥𝐢𝐤𝐞 𝐒𝐭𝐨𝐫𝐚𝐠𝐞, 𝐒𝐐𝐋 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞, 𝐨𝐫 𝐊𝐞𝐲 𝐕𝐚𝐮𝐥𝐭 𝐜𝐚𝐧 𝐛𝐞 𝐚𝐜𝐜𝐞𝐬𝐬𝐞𝐝 𝐩𝐫𝐢𝐯𝐚𝐭𝐞𝐥𝐲 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐞𝐱𝐩𝐨𝐬𝐢𝐧𝐠 𝐭𝐫𝐚𝐟𝐟𝐢𝐜 𝐭𝐨 𝐭𝐡𝐞 𝐢𝐧𝐭𝐞𝐫𝐧𝐞𝐭?

𝐓𝐡𝐞 𝐚𝐧𝐬𝐰𝐞𝐫 𝐥𝐢𝐞𝐬 𝐢𝐧 𝐀𝐳𝐮𝐫𝐞 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭, 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐋𝐢𝐧𝐤, 𝐚𝐧𝐝 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒.
Understanding how these components work together is essential for designing secure Azure networking architectures.

Private Endpoint:

A 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 is an Azure resource that creates a private network interface (NIC) with a private IP address inside the VNet that provides a private connection to access Azure services like Storage and SQL.

𝐖𝐡𝐲 𝐢𝐬 𝐢𝐭 𝐧𝐞𝐞𝐝𝐞𝐝?

It is needed for secure access over Microsoft's backbone network to supported Azure PaaS resources using a private IP and private connectivity, without exposing the traffic to the internet.

W𝐡𝐚𝐭 𝐢𝐬 𝐍𝐈𝐂?

NIC (Network Interface Card) is a virtual network adapter that allows an Azure resource to communicate with a VNet.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐍𝐈𝐂?

A Private Endpoint creates a special NIC. A Private Endpoint is an Azure resource, and the NIC is the implementation behind it. When we create a Private Endpoint, a NIC is created. Azure also creates a new private IP address in the subnet where you deploy the Private Endpoint.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐋𝐢𝐧𝐤?

Private Link is the Azure technology/service that provides the private connection between the Private Endpoint and the destination Azure service (SQL, Cosmos DB).

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐫𝐨𝐥𝐞 𝐨𝐟 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒 𝐙𝐨𝐧𝐞 𝐡𝐞𝐫𝐞?

A Private DNS Zone contains DNS records that map the target Azure service's FQDN (Fully Qualified Domain Name) to the private IP address of the Private Endpoint. For example, the target Azure service can be a Storage Account.

𝐓𝐡𝐞 F𝐢𝐧𝐚𝐥 T𝐫𝐚𝐟𝐟𝐢𝐜 𝐟𝐥𝐨𝐰:

When a VM wants to connect to a target Azure resource like a Storage Account, the Private DNS Zone resolves the service's DNS name to the Private Endpoint NIC's private IP address. The VM then connects to that private IP, and Private Link provides the private connection from the Private Endpoint to the Storage Account over Microsoft's backbone network, without exposing the traffic to the internet.

𝐒𝐮𝐩𝐩𝐨𝐫𝐭𝐞𝐝 𝐀𝐳𝐮𝐫𝐞 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐬 𝐛𝐲 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭:

SQL Server, Cosmos DB, Key Vault, Storage Account, Azure Event Hubs, Container Registry, etc.

When you worked on a Private Endpoint, have you faced any problems, or what was your new learning?

let us understand Azure Service Endpoints, how they work, and how and why they differ from Private Endpoints.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

A Service Endpoint enables secure access to an Azure PaaS service's public endpoint from a selected Azure resource's (for example, a VM's) VNet/subnet via the Microsoft backbone network without exposing the traffic to the Internet.

𝐇𝐨𝐰 𝐢𝐬 𝐢𝐭 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭 𝐟𝐫𝐨𝐦 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

Unlike a Private Endpoint, a Service Endpoint does not create any new resource object/instance of a Service Endpoint, NIC, or private IP.

A Private Endpoint can be deployed in an existing or newly created VNet/Subnet, which is not possible for a Service Endpoint because a Service Endpoint cannot be deployed as a separate resource instance.

𝐇𝐨𝐰 𝐢𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐞𝐧𝐚𝐛𝐥𝐞𝐝 𝐢𝐟 𝐧𝐨 𝐧𝐞𝐰 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐢𝐬 𝐜𝐫𝐞𝐚𝐭𝐞𝐝?

It is enabled on the client-side Azure resource's subnet properties. It is more like a configuration setting rather than creating a new resource instance.

𝐈𝐟 𝐭𝐡𝐞 𝐩𝐮𝐛𝐥𝐢𝐜 𝐞𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐢𝐬 𝐞𝐧𝐚𝐛𝐥𝐞𝐝, 𝐡𝐨𝐰 𝐝𝐨𝐞𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐫𝐞𝐬𝐭𝐫𝐢𝐜𝐭 𝐚𝐜𝐜𝐞𝐬𝐬 𝐭𝐨 𝐚 𝐒𝐭𝐨𝐫𝐚𝐠𝐞 𝐀𝐜𝐜𝐨𝐮𝐧𝐭?

Through firewall rules/policies (for example, the Storage Account firewall), a Service Endpoint restricts access to the Storage Account's public endpoint if traffic comes from anywhere other than the selected client-side VNet/subnet.

𝐖𝐡𝐞𝐧 𝐲𝐨𝐮 𝐜𝐫𝐞𝐚𝐭𝐞 𝐚 𝐒𝐭𝐨𝐫𝐚𝐠𝐞 𝐀𝐜𝐜𝐨𝐮𝐧𝐭, 𝐢𝐭 𝐚𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐜𝐚𝐥𝐥𝐲 𝐡𝐚𝐬 𝐚 𝐩𝐮𝐛𝐥𝐢𝐜 𝐞𝐧𝐝𝐩𝐨𝐢𝐧𝐭. 𝐓𝐡𝐞𝐧 𝐡𝐨𝐰 𝐝𝐨𝐞𝐬 𝐮𝐬𝐢𝐧𝐠 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐦𝐚𝐤𝐞 𝐢𝐭 𝐬𝐚𝐟𝐞𝐫?

By default, a Storage Account has a public endpoint, but public network access can be disabled after creating a Private Endpoint. For a Service Endpoint, this is not possible because it still needs the public endpoint for access.

You must manually update the Networking settings to deny public access when using a Private Endpoint. This is not done automatically by Azure.

𝐃𝐨 𝐰𝐞 𝐧𝐞𝐞𝐝 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒 𝐙𝐨𝐧𝐞 𝐟𝐨𝐫 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

No. We do not need a Private DNS Zone for a Service Endpoint because the Storage Account does not need to resolve to a private IP. Public Azure DNS maintains a record between the public endpoint and the public IP. When traffic comes via a Service Endpoint, it resolves to the public IP.

[If you want to know more about DNS, check the detailed blog here.]

𝐒𝐮𝐩𝐩𝐨𝐫𝐭𝐞𝐝 𝐀𝐳𝐮𝐫𝐞 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐬

Unlike a Private Endpoint, a Service Endpoint does not support Azure AI Services, Azure Machine Learning, Azure App Service etc.

Use Service Endpoint when:

1. Public Endpoint can still exist.

2. There is no compliance or security mandate to disable access to the Azure resource through its public Endpoint.

3. In development or internal workloads, where restricting access through the Azure service firewall to the selected VNet/subnet provides sufficient security.

4. Where external clients are still using the public Endpoint, moving to a Private Endpoint and accessing the Azure resource only through a private IP can add more complexity.

5. You do not want any added cost, as a Service Endpoint is essentially a configuration change at the subnet level; it does not deploy any new Azure resource.

6. The resource supports Azure Service Endpoint.

Use Private Endpoint when:

1. Exposure of the public Endpoint is absolutely a NO-GO.

2. It breaks compliance (especially in banking, healthcare, etc.).

3. For sensitive production workloads that require stronger network isolation. Azure Private Link capabilities ensure access through a private IP.

4. You are comfortable with the cost and management of deployed Private Endpoint-related resources.

5. You want to secure Azure resources that do not support Service Endpoint, or you want capabilities that Service Endpoint lacks, such as private IP connectivity or disabling public network access.

Why is using the Service Firewall recommended with a Service Endpoint, even if you are using a Central Hub Firewall?

The Service Firewall (for example, if you want to access a Storage Account through a Service Endpoint) is considered the last line of defense.

Ideally, if you restrict access to the Storage Account's public Endpoint through the selected VNet/subnet by adding adequate firewall rules in the Hub Firewall, that provides sufficient security.

However, if someone later creates a new VNet/subnet and a direct network path from the client service (for example, a VM) to the Storage Account, or if there is a misconfigured UDR, then the previous rule may be bypassed.

Therefore, it is essential that, on the Storage service side, we also have a firewall that restricts access to the Storage Account's public Endpoint in the right manner.

Why is using a Private Endpoint recommended in a Hub-and-Spoke architecture?

In a Hub-and-Spoke architecture, using a Private Endpoint is recommended because, sometimes, due to misconfigured UDRs or difficulty in identifying the originating source (as the source may appear to be the firewall instead of the client service's IP), Service Endpoints can face challenges due to complex, indirect network traffic paths. It becomes difficult to manage Service Endpoints in such complex scenarios (forced tunneling, centralized firewall, and UDR configuration).

How does a Private Endpoint overcome this complication?

A Private Endpoint, through its Private Link capability, accesses the target Azure service using a private IP address and a Private DNS Zone.

You can completely disable public network access to the target Azure service.

Multi-region/Cross-tenant support for Service Endpoint/Private Endpoint

Multi-region support is not available for a Service Endpoint because it is enabled in the client service's subnet configuration. No new resource is created.

A Private Endpoint can be created in a different region than the client service and the target Azure service.

Cross-tenant support is not available for a Service Endpoint. If a client service in Tenant A needs to establish a secure private connection to a target Azure service in Tenant B, a Private Endpoint can be used.

What does it mean, "Service Endpoints are enabled on a resource type, not on a resource"?

You have:

Subnet → Service Endpoint → Microsoft.Storage

You enable the Service Endpoint for the entire Microsoft.Storage resource type, not for individual Storage Accounts.

At the individual Storage Account level, you create firewall rules to allow traffic from specific VNets/subnets.

• Storage1 – Allow traffic from Subnet1 of VNet A

• Storage2 – Allow traffic from Subnet2 of VNet B

That is why Microsoft says you enable a Service Endpoint for a resource type, not for an individual resource.

Now, let us look at a Private Endpoint.

A Private Endpoint is a dedicated Azure resource with its own NIC and private IP address. Each Private Endpoint connects to a specific Azure resource.

• Private Endpoint1 → Storage1

• Private Endpoint2 → Storage2

Practical Labs:

Lab 1: Test connectivity to storage account using private endpoint.

Lab 2: Test connectivity to storage account using service endpoint.

In lab 1, we shall cover followings:

1. Create a VM

2. Create a Storage Account and container

3. Create a Private Endpoint

4. Create a Private DNS Zone

5. Disable public network access for Storage Account

6. Create another VM without association of PE and Private Link.

7. Verify DNS from both VMs

8. Verify permission for storage account containers from both VMs

Create a virtual network:

It will contain 2 subnets.

[VNET address space is 10.0.0.0/16]

• VMSubnet (10.0.1.0/24)

• PrivateEndpointSubnet (10.0.2.0/24)

We can deploy private end point in VMSubnet only, but enterprise practice is deploying private endpoint in a dedicated subnet.

Create a VM and deploy in the above created VMSubnet:

You can choose Windows Or Ubuntu. I have deployed Windows VM and for this lab purpose, enabled RDP connection and public IP. You can choose to connect via bastion. If you want to know about using bastion to securely connect to a VM, check here.

Create Storage account and add private endpoint:

While creating storage account, disable public network access and add private endpoint (give name PE-storage).

Also, as shown below, choose VNET and subnet accordingly and enable "Integrate with private DNS zone".

Azure automatically creates privatelink.blob.core.windows.net and links it with VNET-Lab.

See the Virtual Network Link which is connected to VNET-Lab:

Now check Private DNS Zone Record set, you will see a private IP (10.0.2.4) is created, storage account FQDN resolves to that.

Copy the blob service name (exclude https://)

Now login to VM and verify DNS

open powershell and run below command

You see in output Address: 10.0.2.4 is printed. It means, the connection happened via private IP with help of private Link capability. See private Endpoint overview and match private IP:

Doubly verify public network access to be 100% sure:

Troubleshooting/FAQ:

What happens if we make Public Network Access=Enabled after creating private endpoint?

Case 1: for the VNET-Lab subnet, it will still use private endpoint connection to connect to storage account.

If you run above command post enabling the public network access, you will see it is still connecting via private IP.

Case 2: If you create a new VM and do not link it to private end point, post enabling public network access, you will see that it is connecting via public endpoint.

For implementing case 2, I have created new VM and verified DNS

See above - Address: 52.239.155.228. When we create a Storage Account, Azure automatically creates the required public DNS records behind the scenes.

The Storage Account's FQDN, mystoragepelabmadhu.blob.core.windows.net, has a CNAME DNS record that points to an Azure-managed host, blob.blz21prdstr01a.store.core.windows.net, which then resolves to an Azure-managed public IP address, 52.239.155.228 for storage service.

Verify the permission to list storage account containers from both VMs post disablement of public network access:

Ensure you have created a container inside storage account

Ensure public network access is disabled:

Now Login to each VM:

First Login to VM-PE-Lab, open powershell :

Install az cli.

winget install -e --id Microsoft.AzureCLI

Do az login for your tenant.

once you az login, execute:

az storage container list --account-name mystoragepelabmadhu --auth-mode login

Expected output: pecontainer will be enlisted.

Now login to the other VM VM-pubend-Lab and open powershell.

Similarly install az cli and login to your tenant.

Now execute same command.

You will see output similar to:

Now we shall perform Lab 2:

Test connectivity to storage account using service endpoint.

In Lab2, we shall cover thee followings:

1. Create a new storage account

2. Enable Service Endpoint

3. Reuse VM-PE-LAB and its subnet VMSubnet.

4. Check connectivity to new storage account via service endpoint through selected subnet.

5. Create another VM but deploy it to different VNET/Subnet

6. Do not enable service Endpoint for step 5

7. Check connectivity to new storage account from new VM's subnet

   
   

Create a new storage account:

Enable Public Network Access and Service Endpoint (Reuse vnet-lab)

Login to VM-PE-Lab and in powershell run:

So, it was able to enlist storage account.

Now, let us create new VM in new subnet with no private endpoint or service endpoint connectivity:

Now, login to this VM and open powershell to run below command:

Takeaways:

As we have gone through this comprehensive blog, we should be more confident now in our understanding of:

• How a Private Endpoint works.

• How a Service Endpoint works.

And what the use cases are to decide which one to use and when.

We learned what a Private Endpoint NIC is and understood that the private IP it creates does not belong to the VM, but rather to the Private Endpoint. We also learned about Private Link capabilities, why it is recommended for Hub-and-Spoke architecture, and the role of the Private DNS Zone.

See you in my next blog. Reach out to me on LinkedIn.

PS C:\Windows\system32> nslookup mystoragepelabmadhu.blob.core.windows.net

Server: UnKnown

Address: 168.63.129.16

Non-authoritative answer:

Name: mystoragepelabmadhu.privatelink.blob.core.windows.net

Address: 10.0.2.4

Aliases: mystoragepelabmadhu.blob.core.windows.net

PS C:\Windows\system32> az storage container list --account-name mystoragepelabmadhu --auth-mode login

[

{

-----

-------

"name": "pecontainer",

"properties": {

"etag": "\"0x8DEF05AD7409B01\"",

-----

----

}

]

PS C:\Windows\system32> hostname

VM-PE-LAB

PS C:\Windows\system32> az storage container list --account-name mystorageaccountselab --auth-mode login

[

{

.....

.......

"name": "container",

"properties": {

"etag": "\"0x8DEF052ADE33E88\"",

.....

},

"publicAccess": null

},

"version": null

}

]

PS C:\Windows\system32> az storage container list --account-name mystorageaccountselab --auth-mode login

The request may be blocked by network rules of storage account. Please check network rule set using 'az storage account show -n accountname --query networkRuleSet'.

If you want to change the default action to apply when no rule matches, please use 'az storage account update'.

PS C:\Windows\system32> hostname

VM-SE-LAB

In this blog, we will cover:

1. Private Endpoint

2. Important related terminologies to Private Endpoint and their meaning

3. Service Endpoint

4. Important related terminologies to Service Endpoint and their meaning

5. Difference between Private Endpoint and Service Endpoint

6. Two hands-on lab

   a) End-to-end lab on private Endpoint

   b) End-to-end lab on Service Endpoint

7. Troubleshooting/FAQs

𝐄𝐯𝐞𝐫 𝐰𝐨𝐧𝐝𝐞𝐫𝐞𝐝 𝐡𝐨𝐰 𝐀𝐳𝐮𝐫𝐞 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬 𝐥𝐢𝐤𝐞 𝐒𝐭𝐨𝐫𝐚𝐠𝐞, 𝐒𝐐𝐋 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞, 𝐨𝐫 𝐊𝐞𝐲 𝐕𝐚𝐮𝐥𝐭 𝐜𝐚𝐧 𝐛𝐞 𝐚𝐜𝐜𝐞𝐬𝐬𝐞𝐝 𝐩𝐫𝐢𝐯𝐚𝐭𝐞𝐥𝐲 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐞𝐱𝐩𝐨𝐬𝐢𝐧𝐠 𝐭𝐫𝐚𝐟𝐟𝐢𝐜 𝐭𝐨 𝐭𝐡𝐞 𝐢𝐧𝐭𝐞𝐫𝐧𝐞𝐭?

𝐓𝐡𝐞 𝐚𝐧𝐬𝐰𝐞𝐫 𝐥𝐢𝐞𝐬 𝐢𝐧 𝐀𝐳𝐮𝐫𝐞 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭, 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐋𝐢𝐧𝐤, 𝐚𝐧𝐝 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒.
Understanding how these components work together is essential for designing secure Azure networking architectures.

Private Endpoint:

A 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 is an Azure resource that creates a private network interface (NIC) with a private IP address inside the VNet that provides a private connection to access Azure services like Storage and SQL.

𝐖𝐡𝐲 𝐢𝐬 𝐢𝐭 𝐧𝐞𝐞𝐝𝐞𝐝?

It is needed for secure access over Microsoft's backbone network to supported Azure PaaS resources using a private IP and private connectivity, without exposing the traffic to the internet.

W𝐡𝐚𝐭 𝐢𝐬 𝐍𝐈𝐂?

NIC (Network Interface Card) is a virtual network adapter that allows an Azure resource to communicate with a VNet.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐍𝐈𝐂?

A Private Endpoint creates a special NIC. A Private Endpoint is an Azure resource, and the NIC is the implementation behind it. When we create a Private Endpoint, a NIC is created. Azure also creates a new private IP address in the subnet where you deploy the Private Endpoint.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐋𝐢𝐧𝐤?

Private Link is the Azure technology/service that provides the private connection between the Private Endpoint and the destination Azure service (SQL, Cosmos DB).

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐫𝐨𝐥𝐞 𝐨𝐟 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒 𝐙𝐨𝐧𝐞 𝐡𝐞𝐫𝐞?

A Private DNS Zone contains DNS records that map the target Azure service's FQDN (Fully Qualified Domain Name) to the private IP address of the Private Endpoint. For example, the target Azure service can be a Storage Account.

𝐓𝐡𝐞 F𝐢𝐧𝐚𝐥 T𝐫𝐚𝐟𝐟𝐢𝐜 𝐟𝐥𝐨𝐰:

When a VM wants to connect to a target Azure resource like a Storage Account, the Private DNS Zone resolves the service's DNS name to the Private Endpoint NIC's private IP address. The VM then connects to that private IP, and Private Link provides the private connection from the Private Endpoint to the Storage Account over Microsoft's backbone network, without exposing the traffic to the internet.

𝐒𝐮𝐩𝐩𝐨𝐫𝐭𝐞𝐝 𝐀𝐳𝐮𝐫𝐞 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐬 𝐛𝐲 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭:

SQL Server, Cosmos DB, Key Vault, Storage Account, Azure Event Hubs, Container Registry, etc.

When you worked on a Private Endpoint, have you faced any problems, or what was your new learning?

let us understand Azure Service Endpoints, how they work, and how and why they differ from Private Endpoints.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

A Service Endpoint enables secure access to an Azure PaaS service's public endpoint from a selected Azure resource's (for example, a VM's) VNet/subnet via the Microsoft backbone network without exposing the traffic to the Internet.

𝐇𝐨𝐰 𝐢𝐬 𝐢𝐭 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭 𝐟𝐫𝐨𝐦 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

Unlike a Private Endpoint, a Service Endpoint does not create any new resource object/instance of a Service Endpoint, NIC, or private IP.

A Private Endpoint can be deployed in an existing or newly created VNet/Subnet, which is not possible for a Service Endpoint because a Service Endpoint cannot be deployed as a separate resource instance.

𝐇𝐨𝐰 𝐢𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐞𝐧𝐚𝐛𝐥𝐞𝐝 𝐢𝐟 𝐧𝐨 𝐧𝐞𝐰 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐢𝐬 𝐜𝐫𝐞𝐚𝐭𝐞𝐝?

It is enabled on the client-side Azure resource's subnet properties. It is more like a configuration setting rather than creating a new resource instance.

𝐈𝐟 𝐭𝐡𝐞 𝐩𝐮𝐛𝐥𝐢𝐜 𝐞𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐢𝐬 𝐞𝐧𝐚𝐛𝐥𝐞𝐝, 𝐡𝐨𝐰 𝐝𝐨𝐞𝐬 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐫𝐞𝐬𝐭𝐫𝐢𝐜𝐭 𝐚𝐜𝐜𝐞𝐬𝐬 𝐭𝐨 𝐚 𝐒𝐭𝐨𝐫𝐚𝐠𝐞 𝐀𝐜𝐜𝐨𝐮𝐧𝐭?

Through firewall rules/policies (for example, the Storage Account firewall), a Service Endpoint restricts access to the Storage Account's public endpoint if traffic comes from anywhere other than the selected client-side VNet/subnet.

𝐖𝐡𝐞𝐧 𝐲𝐨𝐮 𝐜𝐫𝐞𝐚𝐭𝐞 𝐚 𝐒𝐭𝐨𝐫𝐚𝐠𝐞 𝐀𝐜𝐜𝐨𝐮𝐧𝐭, 𝐢𝐭 𝐚𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐜𝐚𝐥𝐥𝐲 𝐡𝐚𝐬 𝐚 𝐩𝐮𝐛𝐥𝐢𝐜 𝐞𝐧𝐝𝐩𝐨𝐢𝐧𝐭. 𝐓𝐡𝐞𝐧 𝐡𝐨𝐰 𝐝𝐨𝐞𝐬 𝐮𝐬𝐢𝐧𝐠 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 𝐦𝐚𝐤𝐞 𝐢𝐭 𝐬𝐚𝐟𝐞𝐫?

By default, a Storage Account has a public endpoint, but public network access can be disabled after creating a Private Endpoint. For a Service Endpoint, this is not possible because it still needs the public endpoint for access.

You must manually update the Networking settings to deny public access when using a Private Endpoint. This is not done automatically by Azure.

𝐃𝐨 𝐰𝐞 𝐧𝐞𝐞𝐝 𝐚 𝐏𝐫𝐢𝐯𝐚𝐭𝐞 𝐃𝐍𝐒 𝐙𝐨𝐧𝐞 𝐟𝐨𝐫 𝐚 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭?

No. We do not need a Private DNS Zone for a Service Endpoint because the Storage Account does not need to resolve to a private IP. Public Azure DNS maintains a record between the public endpoint and the public IP. When traffic comes via a Service Endpoint, it resolves to the public IP.

[If you want to know more about DNS, check the detailed blog here.]

𝐒𝐮𝐩𝐩𝐨𝐫𝐭𝐞𝐝 𝐀𝐳𝐮𝐫𝐞 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐬

Unlike a Private Endpoint, a Service Endpoint does not support Azure AI Services, Azure Machine Learning, Azure App Service etc.

Use Service Endpoint when:

1. Public Endpoint can still exist.

2. There is no compliance or security mandate to disable access to the Azure resource through its public Endpoint.

3. In development or internal workloads, where restricting access through the Azure service firewall to the selected VNet/subnet provides sufficient security.

4. Where external clients are still using the public Endpoint, moving to a Private Endpoint and accessing the Azure resource only through a private IP can add more complexity.

5. You do not want any added cost, as a Service Endpoint is essentially a configuration change at the subnet level; it does not deploy any new Azure resource.

6. The resource supports Azure Service Endpoint.

Use Private Endpoint when:

1. Exposure of the public Endpoint is absolutely a NO-GO.

2. It breaks compliance (especially in banking, healthcare, etc.).

3. For sensitive production workloads that require stronger network isolation. Azure Private Link capabilities ensure access through a private IP.

4. You are comfortable with the cost and management of deployed Private Endpoint-related resources.

5. You want to secure Azure resources that do not support Service Endpoint, or you want capabilities that Service Endpoint lacks, such as private IP connectivity or disabling public network access.

Why is using the Service Firewall recommended with a Service Endpoint, even if you are using a Central Hub Firewall?

The Service Firewall (for example, if you want to access a Storage Account through a Service Endpoint) is considered the last line of defense.

Ideally, if you restrict access to the Storage Account's public Endpoint through the selected VNet/subnet by adding adequate firewall rules in the Hub Firewall, that provides sufficient security.

However, if someone later creates a new VNet/subnet and a direct network path from the client service (for example, a VM) to the Storage Account, or if there is a misconfigured UDR, then the previous rule may be bypassed.

Therefore, it is essential that, on the Storage service side, we also have a firewall that restricts access to the Storage Account's public Endpoint in the right manner.

Why is using a Private Endpoint recommended in a Hub-and-Spoke architecture?

In a Hub-and-Spoke architecture, using a Private Endpoint is recommended because, sometimes, due to misconfigured UDRs or difficulty in identifying the originating source (as the source may appear to be the firewall instead of the client service's IP), Service Endpoints can face challenges due to complex, indirect network traffic paths. It becomes difficult to manage Service Endpoints in such complex scenarios (forced tunneling, centralized firewall, and UDR configuration).

How does a Private Endpoint overcome this complication?

A Private Endpoint, through its Private Link capability, accesses the target Azure service using a private IP address and a Private DNS Zone.

You can completely disable public network access to the target Azure service.

Multi-region/Cross-tenant support for Service Endpoint/Private Endpoint

Multi-region support is not available for a Service Endpoint because it is enabled in the client service's subnet configuration. No new resource is created.

A Private Endpoint can be created in a different region than the client service and the target Azure service.

Cross-tenant support is not available for a Service Endpoint. If a client service in Tenant A needs to establish a secure private connection to a target Azure service in Tenant B, a Private Endpoint can be used.

What does it mean, "Service Endpoints are enabled on a resource type, not on a resource"?

You have:

Subnet → Service Endpoint → Microsoft.Storage

You enable the Service Endpoint for the entire Microsoft.Storage resource type, not for individual Storage Accounts.

At the individual Storage Account level, you create firewall rules to allow traffic from specific VNets/subnets.

• Storage1 – Allow traffic from Subnet1 of VNet A

• Storage2 – Allow traffic from Subnet2 of VNet B

That is why Microsoft says you enable a Service Endpoint for a resource type, not for an individual resource.

Now, let us look at a Private Endpoint.

A Private Endpoint is a dedicated Azure resource with its own NIC and private IP address. Each Private Endpoint connects to a specific Azure resource.

• Private Endpoint1 → Storage1

• Private Endpoint2 → Storage2

Practical Labs:

Lab 1: Test connectivity to storage account using private endpoint.

Lab 2: Test connectivity to storage account using service endpoint.

In lab 1, we shall cover followings:

1. Create a VM

2. Create a Storage Account and container

3. Create a Private Endpoint

4. Create a Private DNS Zone

5. Disable public network access for Storage Account

6. Create another VM without association of PE and Private Link.

7. Verify DNS from both VMs

8. Verify permission for storage account containers from both VMs

Create a virtual network:

It will contain 2 subnets.

[VNET address space is 10.0.0.0/16]

• VMSubnet (10.0.1.0/24)

• PrivateEndpointSubnet (10.0.2.0/24)

We can deploy private end point in VMSubnet only, but enterprise practice is deploying private endpoint in a dedicated subnet.

Create a VM and deploy in the above created VMSubnet:

You can choose Windows Or Ubuntu. I have deployed Windows VM and for this lab purpose, enabled RDP connection and public IP. You can choose to connect via bastion. If you want to know about using bastion to securely connect to a VM, check here.

Create Storage account and add private endpoint:

While creating storage account, disable public network access and add private endpoint (give name PE-storage).

Also, as shown below, choose VNET and subnet accordingly and enable "Integrate with private DNS zone".

Azure automatically creates privatelink.blob.core.windows.net and links it with VNET-Lab.

See the Virtual Network Link which is connected to VNET-Lab:

Now check Private DNS Zone Record set, you will see a private IP (10.0.2.4) is created, storage account FQDN resolves to that.

Copy the blob service name (exclude https://)

Now login to VM and verify DNS

open powershell and run below command

You see in output Address: 10.0.2.4 is printed. It means, the connection happened via private IP with help of private Link capability. See private Endpoint overview and match private IP:

Doubly verify public network access to be 100% sure:

Troubleshooting/FAQ:

What happens if we make Public Network Access=Enabled after creating private endpoint?

Case 1: for the VNET-Lab subnet, it will still use private endpoint connection to connect to storage account.

If you run above command post enabling the public network access, you will see it is still connecting via private IP.

Case 2: If you create a new VM and do not link it to private end point, post enabling public network access, you will see that it is connecting via public endpoint.

For implementing case 2, I have created new VM and verified DNS

See above - Address: 52.239.155.228. When we create a Storage Account, Azure automatically creates the required public DNS records behind the scenes.

The Storage Account's FQDN, mystoragepelabmadhu.blob.core.windows.net, has a CNAME DNS record that points to an Azure-managed host, blob.blz21prdstr01a.store.core.windows.net, which then resolves to an Azure-managed public IP address, 52.239.155.228 for storage service.

Verify the permission to list storage account containers from both VMs post disablement of public network access:

Ensure you have created a container inside storage account

Ensure public network access is disabled:

Now Login to each VM:

First Login to VM-PE-Lab, open powershell :

Install az cli.

winget install -e --id Microsoft.AzureCLI

Do az login for your tenant.

once you az login, execute:

az storage container list --account-name mystoragepelabmadhu --auth-mode login

Expected output: pecontainer will be enlisted.

Now login to the other VM VM-pubend-Lab and open powershell.

Similarly install az cli and login to your tenant.

Now execute same command.

You will see output similar to:

Now we shall perform Lab 2:

Test connectivity to storage account using service endpoint.

In Lab2, we shall cover thee followings:

1. Create a new storage account

2. Enable Service Endpoint

3. Reuse VM-PE-LAB and its subnet VMSubnet.

4. Check connectivity to new storage account via service endpoint through selected subnet.

5. Create another VM but deploy it to different VNET/Subnet

6. Do not enable service Endpoint for step 5

7. Check connectivity to new storage account from new VM's subnet

   
   

Create a new storage account:

Enable Public Network Access and Service Endpoint (Reuse vnet-lab)

Login to VM-PE-Lab and in powershell run:

So, it was able to enlist storage account.

Now, let us create new VM in new subnet with no private endpoint or service endpoint connectivity:

Now, login to this VM and open powershell to run below command:

Takeaways:

As we have gone through this comprehensive blog, we should be more confident now in our understanding of:

• How a Private Endpoint works.

• How a Service Endpoint works.

And what the use cases are to decide which one to use and when.

We learned what a Private Endpoint NIC is and understood that the private IP it creates does not belong to the VM, but rather to the Private Endpoint. We also learned about Private Link capabilities, why it is recommended for Hub-and-Spoke architecture, and the role of the Private DNS Zone.

See you in my next blog. Reach out to me on LinkedIn.

Previous Lesson (Hub-And-Spoke Architecture Simplified)

PS C:\Windows\system32> nslookup mystoragepelabmadhu.blob.core.windows.net

Server: UnKnown

Address: 168.63.129.16

Non-authoritative answer:

Name: mystoragepelabmadhu.privatelink.blob.core.windows.net

Address: 10.0.2.4

Aliases: mystoragepelabmadhu.blob.core.windows.net

PS C:\Windows\system32> az storage container list --account-name mystoragepelabmadhu --auth-mode login

[

{

-----

-------

"name": "pecontainer",

"properties": {

"etag": "\"0x8DEF05AD7409B01\"",

-----

----

}

]

PS C:\Windows\system32> hostname

VM-PE-LAB

PS C:\Windows\system32> az storage container list --account-name mystorageaccountselab --auth-mode login

[

{

.....

.......

"name": "container",

"properties": {

"etag": "\"0x8DEF052ADE33E88\"",

.....

},

"publicAccess": null

},

"version": null

}

]

PS C:\Windows\system32> az storage container list --account-name mystorageaccountselab --auth-mode login

The request may be blocked by network rules of storage account. Please check network rule set using 'az storage account show -n accountname --query networkRuleSet'.

If you want to change the default action to apply when no rule matches, please use 'az storage account update'.

PS C:\Windows\system32> hostname

VM-SE-LAB