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.
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.