What is the Point? Comparing Microsoft Azure Service and Private Endpoints

Information is key in today’s business world. Not just having it, but making sure it does not end up in the wrong hands. This is true regardless if you are in a private cloud or leveraging a public cloud like Microsoft Azure.

Keeping your network traffic secure and avoiding routing over the internet is key to maintaining data security. Luckily, Microsoft Azure provides two “endpoint” methods to ensure data takes an optimized route:

• Service endpoint:
  • This provides secure and direct connectivity to Azure services over the Azure backbone

A list of Azure services supported with a service endpoint can be found here.

• Private endpoint:
  • Allows you to leverage a private IP from your virtual network to connect privately and securely to an Azure service

A list of Azure services supported with a private endpoint can be found here.

Before we get into the specifics of each endpoint, it is important to understand what occurs if there are no endpoints (service or private) configured.

Note: for the examples used in this blog, we will be connecting to a Microsoft Azure storage account.

When a storage account is created, a public endpoint is used for communication. This means that when a workload/client/application needs to communicate with the storage account, the public endpoint will resolve to a public IP address and the traffic will be routed over the internet.

Although the traffic is encrypted, it will traverse the internet.

The first way we can avoid sending traffic over the internet is via a service endpoint. But how do service endpoints function?

Believe it or not, the storage account endpoint still creates and resolves to the public IP… but an additional step occurs. When any Azure VM within the vNet attempts to connect to the PUBLIC endpoint of a storage account, the “next hop” will be redirected to the Azure network backbone.

The figure below highlights the properties of a vNIC and the “Effective routes”. We can see that there are additional routes automatically created/added when the service endpoint is configured:

And once the routes are added, any traffic that is targeting the public endpoint of the storage account will be directed over the Azure network backbone.

The second way we can avoid sending traffic over the internet that is destined for an Azure service is via a private endpoint. The benefit of a private endpoint is that all traffic will remain in the vNet and it will never traverse the internet and/or the Azure network backbone.

The first step is that the storage account will leverage a private IP address from within the vNet — in the example: 10.0.0.10. This will allow the workloads to communicate directly with the Azure service via the private IP.

Next, a public and private DNS entry/IP address will also be automatically created.

• Public Endpoint DNS name: <sa>.blob.core.windows.net
• Public Endpoint DNS name: <sa>.privatelink.blob.core.windows.net

Azure will also create a CNAME DNS record resolving the public address to the private IP. In this case, the public endpoint will resolve to 10.0.0.10. This means that all traffic will stay within the Azure vNet and not traverse the Azure network backbone.

And because we now have a routed network, resources from on-premises can communicate with Azure services WITHOUT going over the public internet — assuming there is an ExpressRoute or VPN connection.

Note: Keep in mind that DNS / HOSTS file will need to be updated to resolve appropriately for on-premises connectivity

Let’s now directly compare the service and private endpoints:

For details on use cases for service and private endpoint, please connect with your local Veeam account team.

A service or private endpoint is a great way to keep your data secure and maximize performance, all the while minimizing costs — the great combination when leveraging Veeam to protect your data.