To ensure your services are not exposed to the public internet:
- Enable Private Endpoint (or VNet Integration) for each backend App Service.
- In App Service → Networking:
- Disable public access by setting “Public network access” = Disabled.
- Configure Access restrictions to allow only traffic from the Application Gateway subnet.
- This way, only Application Gateway can reach the backend services.
As far as the Application Gateway goes:
- Deploy the Application Gateway in the same VNet.
- Configure it as a reverse proxy:
- Frontend: your public/custom domain (e.g.,
app.contoso.com). - Backend pool: your App Services private endpoints.
- Frontend: your public/custom domain (e.g.,
- Optionally enable Web Application Firewall (WAF) for security.
In regard to the custom domain donsiderations (custom domain vs the default *.azurewebsites.net)
- From the outside (UI app to users):
- You'll typically want a custom domain (e.g.,
ui.contoso.com) fronted by Application Gateway.
- You'll typically want a custom domain (e.g.,
- Between UI and backend services (internal calls):
- You don't have to use custom domains for backend services.
- Since all traffic flows through Application Gateway's private IP or private DNS zones, the default Azure-provided domains (
*.azurewebsites.net) are enough. - However, if you want TLS end-to-end with hostname validation, you'll need to configure either:
- Custom domains + certificates on the backend App Services, or
- Use the default domains with matching certificates (Azure already provides TLS certs for
*.azurewebsites.net).
For maintainability, I tend to stick with default domains internally, unless there is a requirement for custom hostnames for routing/security policies.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin