Azure Private Link Part 2, What is Private Link Service and why use it?

In part one of this series on Private Link I talked about the Private Endpoint and how it allowed you to consume PaaS services via a private IP (read more here). Private Link has a second component – Private Link Service that can be used to expose services deployed on your VNET to others who can consume it through their own Private Endpoint.

One of the key things that I covered in the previous posts is that Private Endpoints work across subscriptions, Azure AD tenants and will eventually work across regions. So you’ve now got the capability of standing up a service in your own VNET and allowing partners, customers, subsidiaries, etc to consume them privately. You don’t need to expose your service to the internet and you don’t need to worry about ip address space overlapping and you don’t need to try setting up VPNs or peering VNETs.

If you’re a service provider I think this could be an interesting option for you. More information on Private Link Service can be found here: https://docs.microsoft.com/en-us/azure/private-link/private-link-service-overview

What services can you offer?

Private Link Service can expose services sitting behind an Azure Standard Load Balancer. So you could run a web farm of IIS servers sitting behind a load balancer and expose these for consumption via the Private Link Service. That will allow consumers of your service to access it privately from their own VNET without needing to expose your service to the internet.

Private Link Service should support any service you can front with a Standard Load Balancer that leverages IPv4 and TCP.

How do your services get consumed?

Essentially when you stand up a Private Link Service you’re providing a service link that a Private Endpoint can connect to. On the Private Link Service side you need to consent to any connections made via the setup of a Private Link Endpoint. You can choose to automatically approve connection requests if you want your endpoint to be easily consumable. On the consumer side they will need to know the Private Link Service id. Setup is rather simple.

From a security perspective not availing of the automatic approval makes sense and would be a must if you’re exposing anything sensitive using the Private Link Service.

Keep in mind that you can setup and consume a Private Link Service within a single subscription, so you could choose to have multiple VNETs that aren’t peered, publishing services in one VNET and consuming them from another. This allows you to limit access into the “services” VNET with less effort than trying to achieve the same thing with VNET peering.

Why use it?

As a service provider the benefit as I see it is a simplified deployment model and a more secure way of offering your services. From the deployment standpoint you can setup your application/service being offered as if you were deploying it for internal use. You don’t need to expose it to the internet, you don’t need to continually manage NSGs, and firewall rules.

As a consumer of a Private Link Service you get the benefit of being able to consume the service over a private IP, so you don’t need to worry about consuming a service over the public internet. If you’re doing that from on-prem and have Express Route then you’ll get the benefit of lower latency. With this consumption model you also remove any concerns you might have around IP address overlaps with whoever you’re consuming the service from and don’t have to peer entire VNETs.

Like any services offered by a 3rd Party be that via a PaaS or SaaS keep in mind you’re trusting the service provider to secure their backend with an adequate level of security and governance. While you can use Private Link to consume services privately which is a big plus that doesn’t remove all the risks of poor security at the service provider side.

Any drawbacks?

Well the main one I see is the consumer of your service has to be on Azure in some shape or form. At minimum they’d need a VNET (for Azure to Azure consumption) and connectivity back to on-prem if they want to consume the service from there (on-prem to Azure consumption).