Azure Service Endpoint and Azure Private Link

In general, we access PaaS workloads on Azure via public endpoints. At this point, when we want to make security tightenings or performance improvements, there are two different services that come across;

Azure Service Endpoint
Azure Private Link

Although these two services basically provide us to establish communication between Azure Virtual Networks (VNets) and Azure PaaS workloads over the Microsoft backbone network infrastructure, there are points where they differ from each other.

Firstly, let’s examine Azure Service Endpoint and Azure Private Link separately. Then let’s test the services with a demo and look at the differences between them.

Azure Service Endpoint

With Azure Service Endpoint, Azure services and Azure Virtual Networks (VNets) can establish a secure and direct connection over Microsoft backbone network. So, we can restrict connections to critical Azure PaaS workloads and ensure that only Azure Virtual Networks communicate.

Azure Service Endpoint provides devices connected to Azure VNet to access Azure platform services with their Private IP addresses without the need for a Public IP address on the VNet. It is possible to isolate this configuration up to the subnet level. In this way, PaaS resources accept traffic from the all of VNet or any subnet in the VNet.

By adding routes to Network Interfaces on the Azure Service Endpoint subnet, it directly to accesses the Azure platform services from Network Interfaces in the subnet. In this process, we use the Public Endpoints of PaaS resources, but the traffic travels within the Microsoft backbone network.

Azure Private Link

Azure Private Link is a service that allows access to Azure services by creating a Private Endpoint in Azure VNet. With Azure Private Link, traffic between Azure VNet and Platform as A Services travels over the Microsoft backbone network. So, services do not need to be opened to the internet.

By deploying Azure Private Link Service provided by Azure Private Link into our own Azure VNet, it can enable our other Azure Tenants or our business-partner’s Azure Tenants to communicate with Azure services running under the Azure Tenants. Business-partners need to just deploy a Private Endpoint in the VNet of the customers and to match it with the Private Link Service on the provider side.

Azure Private Endpoint, which we will demo and compare in a moment, is a Network Interface provided by Azure Private Link within Azure VNet to establish a private and secure connection. Azure Private Endpoint provide VNet to communicate with Azure service using a Private IP address within Azure VNet. We can use Azure Private Endpoint for Platform as a Services such as Azure Storage, Azure Cosmos DB, SQL to communicate with VNet.

Let’s look at the differences between Azure Service Endpoint and Azure Private Endpoint with a demo;

We have previously created the Azure Services we will use in the demo, Storage Account, VNet and VM. And to implement the scenario which the VM should not have a Public IP address, we disassociated the VM’s Public IP address and created Azure Virtual Network Gateway and configured Point-to-Site VPN with our VNet. In this way, we will be able to connect directly to our Azure VNet from our own computer and access the VM via its Private IP address. VM will not have a Public IP address.

After these configurations, we will perform the following steps in our Azure Service Endpoint test;

We will upload a text file to the Storage Account.
We will block Public access on Storage Account and connect Storage Account with our VNet via Azure Service Endpoint.
We will test access to the Storage Account from our own computer and Azure VM. We will see which IP address will return to us from Azure Storage Account when we try it from the VM on Azure.
After that, we will grant Azure Storage access permission for the Public IP where our computer accesses the Internet. And, we will test the access to Azure Storagre from Azure VM and our computer with IP permission defined over the public network.
In addition, we will look at the scenario that the VM can’t access the internet and only connect to the storage.
Finally, we will save the information about Azure Service Endpoint and reset our existing definitions so that we can begin our tests with Azure Private Endpoint. In this process, we will remove the access permission given to the VNet on the Azure Storage Account, test the connection with the VM and see it cannot connect.

After we remove our definitions, we will perform the following steps for Azure Private Endpoint tests;

We will turn off public access on Storage Account again, create an Azure Private Endpoint definition and connect Storage Account and Vnet. When we make this definition, we expect a Network Interface to be created in VNet. In parallel with this, a Private DNS Zone will be created for the devices connected to the subnet to return the DNS definition of the Storage Account over Private IP, and it will enable the DNS to be routed from Private IP for the Storage Account.
With our previous Azure Service Endpoint test, we will take the definitions to made for VM unable to access the internet one step further and remove the definition we added for Azure West Europe Storage Accounts. Our expectation is that Azure VM and Storage Account will comminicate in the same subnet, so the traffic will return from Private IP within the VNet and we will not have access problems.
Then, we will try to access the Storage Account via the VM and check which IP address will return to us from Azure Storage Account
In this process, we will open the Storage Account to public access, and check again from which IP will return to us from the Storage Account, both our own computer and the VM.

After all these tests, we’ll make our general comparison of both Azure services.

Let’s start with Azure Service Endpoint.

I upload a text file to the Storage Account and control it over the URL. The URL returns me at IP 52.239.143.164.

I block public access on Storage Account and establish its connection with VNet. At this stage, we also see that a Service Endpoint has been deployed on the relevant subnet in Azure VNet. Service Endpoint can also be controlled on VNet. In addition, route definitions can be controlled from Network Interfaces in the subnet.

Cheking Service Endpoint on VNet.

In this step I try to recall the URL on my own computer. When I try to call from my own computer, I get the error, I expected, because I have an access block, then I connect to the server in Azure VNet with Point2Site VPN via Private IP and call the text file from browser and I see that the response is returned from the same Public IP again.

I authorize my Public IP address on Storage Account and try to go to the URL on my computer. I see that the URL coming successfully. This means, I can access Storage Account from within VNet and, in addition to this, from any IP or IP range I want in public.

I don’t want the VM to access the internet and I want it to access the Azure Storage Account, and I organize my Network Security Group as follows. It should be noted here that the VM is allowed to access all Storage Accounts in Azure West Europe. We will look at Azure Private Endpoint tests, is this the case for Private Endpoint? I observe that the VM cannot access the internet and can access the Storage Account.

Finally, I remove the VNet connection on the Storage Account and the Service Endpoint definition on the VNet. After doing this, I re-check the route definitions applied by the subnet to Network Interfaces and I see that the routes to the Service Endpoint have been removed. Afterwards, I check the access to the Storage Account from within the VM and see that I cannot access it.

Now let’s start to our tests about Azure Private Endpoint;

I am creating Azure Private Endpoint definition that will connect VNet with Storage Account. After that, I check the automatically created Private DNS Zone definition and the Network Interface created within the VNet.

Network Interface;

DNS Zone;

As you will remember, we have defined outbound permission for West Europe location Storage Accounts on VM’s Network Security Group. But after we removed the Service Endpoint, we could not access because Storage Account was closed to public access. At this stage, I go one step further and remove this definition on NSG and block all traffic from the VM to the internet. Our expectation is that we will not have comminication problems because the traffic will not go out of the VNet.

I am trying to access Storage Account again from the VM and check from which IP the Storage Account will return. And Bingo! Storage Account return to its Private IP address. So my traffic does not go out of the VNet. If you remember, I could access the Public IP address of the Storage Account with Service Endpoint.

We are reopening Storage Account for public access. Here, if we want, we can give access permission to our own IP or only the IPs we want to access. We are trying to access the URL from my own computer and the VM. As we expected, we can access the URL from Public IP on my own computer and we can access it from Private IP with the definition of DNS Zone in the VM.

When I control routes over a Network Interface in Subnet, I see the Private IP address created by the Private Endpoint for the Storage Account and the Interface Endpoint as Next Hop Type. If you remember, we were seeing Public IP addresses here in Service Endpoint.

Now let’s summarize the differences in the light of our demo and other theoretical information;

First of all, the first point we paid attention to was that when we used Service Endpoint, the traffic did not come out of the Microsoft backbone network, but the service connection with VNet was made through public endpoint. In the Priave Endpoint, a Network Interface was automatically created in the relevant subnet within the VNet and DNS redirection was made by the automatically created Private DNS Zone. So, we were able to access the Storage Account via Private IP and our traffic did not leave our VNet.

Another advantage of Private Endpoint for us is that it allows access restrictions with the Network Security Group within the subnet, as communication is established via the Network Interface in the subnet. On the Service Endpoint side, we can do this with the help of Service Tags, as we did in our demo. The point we need to pay attention to is that Service Tags can allow a wide range of places that we do not want to access.

With Private Endpoint, there will be a built-in data exfiltration protection, because the traffic will not go outside the VNet. In Service Endpoint, we may need to take protections such as Firewall.

Private Endpoint kullanımında DNS Zone, Newtork Interface gibi ek kaynaklar olacaktır. Bu sebeple, mevcut topolojimize Service Endpoint’i eklemek daha kolay bir seçenek olarak karşımıza çıkacaktır.