The use of Private Endpoints is an increasingly popular choice, and Microsoft suggest their use is considered best practice (ref), 

In this article, I'll explain what Private Endpoints are in comparison to Service Endpoints and present examples of what I believe are the realities of dealing with them.

What is a Private Endpoint?

A Private Endpoint adds a network interface to a resource, giving it a private IP address issued by your VNET (Virtual Network). Once applied, you can only interface with this resource using the VNET.

Service Endpoints are an alternative to Private Endpoints in that the resources are still accessible via the public internet; however, their embedded firewalls limit access to specific VNETS/subnets or public IP addresses.

Private Endpoints are more safe in this scenario, but they add complexity.

When used with a Private Endpoint, a resource endpoint is no longer publicly routable.

Private DNS Zones address this issue. A Private DNS Zone is linked to one or more VNETS and contains DNS entries for private resources. When you deploy a Private Endpoint and link it to a Private DNS Zone, the resource's public IP address is changed with a CNAME record that points to the Private DNS Zone.

The Consideration

With Service Endpoints, a PaaS resource remains publicly available. You can direct inbound traffic to arrive from specific public IP addresses or from within the VNET itself. The resource itself is still available online.

However, with a Private Endpoint, it is not possible to accept specific public IP addresses. Traffic enters via the VNET, or not at all.

As a result, performance may be increased by lowering network latency because communication occurs within the Microsoft network backbone.

Also, you can apply network policies to Private Endpoints (NSGs and Route Tables on the subnet that hosts them) to gain granular control over your network traffic.

In a word, a Private Endpoint gives the most secure and granular network access to a resource. But what does private truly mean in this instance, and do the disadvantages of having a Private Endpoint outweigh the benefits?

Consider the following:

Control plane vs. data plane

It's crucial to understand the distinction between control plane and data plane operations.

For example, suppose we have an Azure Storage Account with a Private Endpoint configured for the blob endpoint. A control plane operation would be something like utilising the Azure CLI to retrieve the account key. A data plane action would be similar to listing blobs within a private container.

With a Private Endpoint configured for the blob endpoint, you can perform control plane actions regardless of your presence on the VNET. Yes, you must be authorised, however your originating IP is irrelevant in this situation.

However, data plane operations can only be performed if they are initiated from within the VNET.

I bring this up to emphasise that adding a Private Endpoint does not make the resource completely private, only certain activities.

This is critical when determining expectations.

DEVOPS AND IAC

From a DevOps standpoint (i.e., utilising pipelines to deploy infrastructure-as-code), you'll most likely need to employ self-hosted runners with network access to the VNET where the Private Endpointed resources will be located. Using a hub and spoke model, you might install a VM within the hub to host the DevOps agents, ensuring that the hub VNET is peerable and routable to the speak VNETS with Private Endpointed resources enabled.

NETWORK COMPLEXITIES

Assume you have a hub and spoke network topology. Your hub contains a VNET and shared Private DNS Zones. There are several spokes, each with its own VNET, including resources with Private Endpoints enabled.

The hub VNET would need to peer with each spoke VNET, and all Private DNS Zones would need to be connected to both the hub VNET and each spoke VNET.

Granular permissions should be used to isolate the hub from the spokes, according to best practices. For example, the hub and each spoke could be on separate subscriptions with their own RBAC policies in place.

COSTS

A single Private Endpoint costs approx INR 795.00 per month. Multiply that by how many resources you plan to add a Private Endpoint to, over how many environments you need to deploy, and the result can be expensive. Especially when you consider resources like Storage Accounts that have multiple endpoints (blob, table, file, queue) and therefore need multiple Private Endpoints for every endpoint used.

Furthermore, a single Private DNS Zones also costs approx INR 795.00

CONCLUSION

In summary, Azure Private Endpoints and Service Endpoints provide secure connection between virtual networks and Azure services, but their approaches and benefits differ.

Private endpoints offer a more secure and efficient communication alternative, but they come with additional expenses and difficulties. Also, understand the term 'private', as it can imply different things to different people.

Service Endpoints, on the other hand, are simpler to set up and support, but they do not provide as secure access to Azure services as Private Endpoints do.

When deciding between Private Endpoints and Service Endpoints, businesses should examine their security and performance requirements, as well as the Azure services they want to utilise. With the proper configuration, both solutions can assist organisations in creating a safe and effective cloud environment.