0

I've seen a few articles dealing with the differences between Private Endpoints (with private Link) and Service Endpoints: https://samcogan.com/service-endpoints-and-private-link-whats-the-difference/

And I've found a few bits and pieces regarding using both together https://learn.microsoft.com/en-us/azure/postgresql/concepts-data-access-and-security-private-link#private-link-combined-with-firewall-rules

But I haven't found much about this. Specifically we are considering an architecture where we are using Service Endpoints and Vnets for communication within our microservice landscape and Private Endpoints for making some services available from an on-premise network using VPN with the specific private IPs of the private endpoints.

So we have some services with just Service Endpoints and some with Service Endpoints and Private Endpoints. Are there any problems with this approach? Will DNS cause a problem later? If I have a private DNS will the naming within my network always resolve to the internal IP?

I have create some services with both but cannot test the VPN side yet and could not test the private DNS as it is not yet enabled for us. But everything seems to work using the service endpoint side of things.

dashambles
  • 529
  • 8
  • 22
  • Have you been able to combine private endpoint access with VNets? I have app services in VNets accessing SQL Server, and adding a private endpoint access to that SQL Server makes it unavilable inside VNet. Can't figure out how to resolved that... – Arthur Stankevich Apr 28 '23 at 14:55

1 Answers1

0

So Service Endpoint and Private Link have pretty much the same use case but the difference come in the private vs public endpoint access. A service endpoint allows, for example, a VNet to have access to Azure Storage or whatnot but the public endpoint is still accessible via it's public endpoint on .blob.core.windows.net. If you create a private link to it, the dns is routed over a private ip and changes to .privatelink.blob.core.windows.net. More on that here.

So to come back to your architecture, I am not sure what your network looks like but let's assume you have configured connectivity to your on-premise and cloud vnet, endpoints that are exposed as private links should work as it has a dns-routable name and will be accessible via the subnet that you associated the private link to.

For us, this new feature is a bit of a game changer in terms of securing PaaS offerings as we don't have to place the resource directly in it's own VNet anymore (which can be expensive such as the case of an Isolated Web App).

Hope that helped a bit.

Michael vd Berg
  • 42
  • 4
  • Thanks for the reply Michael, it helps to know that it is in general possible! I have been playing around with DNS and am having trouble with it. The DNS with PEs works as detailed here https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns For example for a DB yout need to set up an A record dbname.privatelink.databases.windows.net to private ip. The private DNS is associated with a vnet. So for all name resolutions then within this vnet the private ip is returned. I would however like to use service endpoints everywhere except for the traffic originating from on prem. – dashambles Jul 21 '20 at 16:34
  • What about using an application gateway that will act like an aggregation to the back-end services that you host? You can therefore feel free to move your micro-services behind it too with all services hosted and grouped as back-end pools including the private linked ones. This way you can control both the public IP (if required) as well as the private IP for on-premise and internal through separate listeners and do all the magic of SSL offload, reverse-proxying and routing to the respective service endpoint that you need. – Michael vd Berg Jul 21 '20 at 18:03
  • Yes that's a good idea for own workloads, thanks for the hints. I think this combined with a second vnet for the private endpoints might work. It seems to be possible to use multiple service and private endpoints from different vnets. – dashambles Jul 23 '20 at 10:00