Azure® Private Endpoint provides private IP address access by using a network interface controller (NIC) attached to a virtual network subnet for an Azure web app, allowing access from an on-premise VPN or ExpressRoute. Implementing an endpoint effectively blocks the public inbound access. This technology is very similar to an internal App Service Environment (ASE) but much cheaper.
You should know the following details about Azure Private Endpoint:
For a real-world test, I provisioned a Sitecore® 9.3 XM scaled development environment within Azure PaaS. I deployed SolrCloud® into a virtual network (VNet) with the correct subnets for regional VNet integration and a VPN gateway to my on-premise location. VNet integration allows App Service web apps to make outbound calls into a virtual network, but not inbound. While Azure has a neat Azure private DNS offering, it does not work with VNet integration. You need a DNS server for name resolution into the VNet. Not to jump ahead, but creating a private endpoint gives you the option to use an Azure private DNS zone. I skipped it because I am already using a DNS server. Putting everything together, a private endpoint allows private inbound into the web app, and VNet integration allows private outbound to my virtual network. This setup sounds like a cheaper ASE.
With my Sitecore environment provisioned, I wanted only users within my on-premise corporate network to access the Content Management (CM) web app. Out of the box, the CM web app has a public endpoint that anyone can access. To meet my requirements, I need to provision a private endpoint for the web app. Follow these steps to create an endpoint:
After you provision the endpoint, the web app loses all inbound public connectivity because you associated a private IP address with the fully qualified domain name (FQDN) and Kudu® URL.
If you are using the azurewebsites.net domain, you need to add a DNS zone to route traffic to the private IP address associated with the web app. With Sitecore, this would effectively break the application because I added only one web app with a private endpoint. Consider the CM login that talks to the Sitecore Identity (SI) web app for authentication. If I had one zone for azurewebsites.net, I would also need to add private endpoints to all my web apps and then add A records into that zone for communication. Gets pricey, making everything a PremiumV2 SKU. It would also break any other web app that I wanted to browse to on the azurewebsites.net domain.
You can approach this problem in two ways. Use a custom domain name on the web app that matches a zone in your DNS server or create a DNS zone with the azurewebsites.net FQDN of the web app. Because this is a test, I opted to use the latter and just created an A record pointing to the private IP of the endpoint for that specific web app.
Just like an internal ASE, you need to take into account the Kudu software configuration management (SCM) URL. As the preceding image shows, I have two zones per web app with an A record pointing to the private IP address of the endpoint for each zone.
Now that on-premise users can access the CM web app for secure content authoring, I wanted to figure out what I need to do if I have a Content Delivery (CD) web app behind a private endpoint but needed public users to access it. Previously, by using an internal ASE, I could provision an application gateway and plug a hole into the VNet. I didn’t see how this is any different, so I approached it by using the following steps:
You can easily create a secure routable solution from on-premise to an Azure web with a combination of private endpoints and regional VNet integration. Instead of using an internal ASE, try testing out the preceding steps to see if this solution meets your needs. Find more information at the private endpoint documentation.