I’ve come across a scenario where one of my customer using Azure SQL DB wanted to share their Database with other customer who was also hosted on Azure. They were struggling to establish site-to-site connectivity so that Customer B could access Customer A’s network, enabling them to connect to the Azure SQL DB via the site-to-site tunnel. Though this can be achieved, there are better ways to connect to Azure SQL DB, or any PaaS instance for that matter, with another customer who is using Azure. This can also be used by customers who have multiple Azure AD tenants.
There are multiple benefits to using this:
So, it can happen that your Azure SQL DB resides in the Azure Central India region, but you’ve created the PE in the South India region of Fabrikam’s VNET. Though this shouldn’t be done, considering latency. But this similar type of architecture of private endpoints can be leveraged for other PaaS instances where latency is not a challenge or sometimes specific PaaS service itself is not available in your region. You’ll see a lot of similar deployments when you deploy the OpenAI service.
A common misconception is that you’ll need to peer the VNETs of Contoso and Fabrikam in order for an app residing in Fabrikam to connect to a DB in the Contoso tenant. Which is not the case. There shouldn’t be any connectivity between any of the VNET. As soon as private endpoint is created in Fabrikam and approved by Contoso you can connect to that endpoint from any of the VNETs hosted in Fabrikam as long as it has line of sight with the private endpoint IP Address. Even Fabrikam On-premises location which is connected with S2S can connect to Private Endpoint IP Address. All the connections flow through the Azure backbone and reach the actual PaaS instance without needing VNET Peering.
As mentioned in the architecture, this private endpoint and PaaS DB relationship can work across tenants. PE can be created in any Entra ID tenant, and the actual PaaS instance can reside in any of the customer tenants. This makes PE connectivity flexible to use in broad usecases.
please Note: Not all services would support cross tenant, I've found Azure PosgreSQL
One of the architecture pattern with private endpoint is, Fabrikam though they have their own IP Address space and Contoso might also be using same conflicting IP schema, still Fabrikam was able to create private endpoint in their own VNET with unique IP which is limited to their own environment only. It doesn’t matter to contoso whether PE was created with the same IP Address as of Contoso VNET. So, basically, you eliminate the need for NAT and complex routing in this scenario.
PE with PaaS is just one example; I’ve seen architecture where we’ve deployed customer application with Standard LB and used that to expose it as a private Link service, assuming PE pointing to private link service can be created in any of the VNETs with conflicting IP addresses as there is no need for VNET Peering. So, this exposes your own application with PLS and PE and eliminate the need of VNET Peering and NAT if you’ve conflicting IP Address space.
I hope above scenario help you to design more complex architecture leveraging private endpoint capabilities.
Happy Learning!
Aquib Qureshi
Technical Specialist
Visit my Blog: www.azuredoctor.com
Public blogpost : https://www.azuredoctor.com/posts/resourcesharing-with-azure-private-endpoint/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.