Share via

Public Azure App Service accessing Private Azure OpenAI via VNet Integration and confusion around Secure Web Gateway (SWG) rewritten URLs

Shubhangi Nannware 120 Reputation points
2026-05-07T19:10:54.6466667+00:00

Problem Statement

We have a chatbot application hosted as an Azure App Service (Web App) with the following configuration:

App Service:

  • Private Endpoint enabled (inbound)

*Public network access disabled

*VNet Integration enabled (outbound)

  • Azure OpenAI resource:

Private Endpoint enabled*

Public access disabled*

The Web App consumes Azure OpenAI models (for example, GPT and embedding models).

Currently, internal users access the application through a corporate Secure Web Gateway (SWG) / Web Proxy, which rewrites the application URL into the following format:

https://security-proxy.example.com/___https://myapp.azurewebsites.net/___<encoded-data>

This rewritten URL works for internal users because traffic is routed through the organization’s security gateway.

Now, the client wants:

  1. The chatbot application to be accessible globally to any external user
  2. The GPT and embedding model functionality to be available to those users
  3. Clarification on whether the SWG‑rewritten URL itself can be made public, or whether users should access the application differently

#Proposed Understanding / Approach

One proposed approach is:

  1. Enable public network access on the Azure Web App
  2. Remove the Private Endpoint from the Web App (inbound)
  3. Keep VNet Integration enabled** on the Web App (outbound)
  4. Use VNet Integration to allow the Web App to access the private Azure OpenAI resource via its Private Endpoint
  5. Keep Azure OpenAI private, so GPT and embedding endpoints are not publicly exposed
  6. End users interact with GPT features only through the Web App

However, there is confusion about:

Whether this configuration would allow global users to access the SWG‑rewritten URL

Or whether external users should access only the native Web App URL, such as:

    https://myapp.azurewebsites.net

(or a custom domain)

#Questions

  1. Can a Secure Web Gateway (SWG) / Web Proxy–rewritten URL (for example, https://security-proxy.example.com/___https://myapp.azurewebsites.net/___<encoded-data>) ever be made publicly accessible to global users?
  2. If the Azure Web App is made public, is it correct that:
    • Internal users may continue to access the app through the SWG‑rewritten URL due to corporate security policies
    • External/global users should access the application only via the native App Service URL or a custom domain, and not through the SWG URL?
  3. Is the following architecture supported and recommended?
    • Public Azure Web App
    • VNet Integration enabled (outbound)
    • Azure OpenAI kept private via Private Endpoint
    • Web App accessing Azure OpenAI privately while users access only the Web App
  4. In this use case, is a custom domain and/or Azure Web Application Firewall (WAF) required or recommended for global access and security?
  5. Are there any Azure architectural best practices or limitations we should be aware of when exposing a public Web App that consumes private Azure OpenAI endpoints?
Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

Answer accepted by question author

  1. Praneeth Maddali 9,595 Reputation points Microsoft External Staff Moderator
    2026-05-07T19:43:22.56+00:00

    Hi @Shubhangi Nannware

    Thank you for the detailed explanation of your current setup and requirements. I fully understand your goal: make the chatbot application accessible to external users worldwide, while keeping the Azure OpenAI resource completely private and secure.

    your proposed approach is valid and follows a well-supported Azure networking pattern. Implementing the changes below should resolve your issue

    Recommended Architecture

    • Enable public network access on the Azure App Service and remove the inbound Private Endpoint.
    • Keep VNet Integration enabled (outbound) so the Web App can reach your virtual network.
    • Keep Azure OpenAI fully private — leave public network access disabled and retain the Private Endpoint.

    This configuration allows:

    • External/global users to access the chatbot via the public App Service URL (or custom domain).
    • The Web App to securely call Azure OpenAI models over private connectivity (Private Link) without exposing the OpenAI endpoints to the internet.
    • Internal users to continue using your corporate Secure Web Gateway (SWG) / rewritten URL as before.

    Access Clarification

    • Internal users: They can keep accessing the application through the existing SWG-rewritten URL (corporate policies will continue to apply).
    • External users: They should access the application using the native App Service URL (https://<yourapp>.azurewebsites.net) or a custom domain.

    We do not recommend making the SWG-rewritten URL publicly available, as these gateways are intended for internal traffic inspection and control.

    Important Configuration Tips

    To ensure reliable connectivity from the App Service to the private Azure OpenAI endpoint, please make sure to:

    • Link the Private DNS zone (privatelink.openai.azure.com) to the VNet used by your App Service.
    • Set the app setting WEBSITE_VNET_ROUTE_ALL = 1 (this is strongly recommended for Private Endpoint scenarios).

    Production Recommendations

    For better security, performance, and user experience, we also suggest:

    • Adding a custom domain with a managed certificate.
    • Placing Azure Front Door (with WAF) or Application Gateway with WAF in front of the App Service.

    reference :

    https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration

    https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-routing

    https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/network

    https://learn.microsoft.com/en-us/azure/frontdoor/front-door-waf

    If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

    If you have any other questions, let me know in the "comments" and I would be happy to help you

     

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-07T19:11:27.4966667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more
    1. A Secure Web Gateway (SWG) / proxy–rewritten URL is not a general-purpose public endpoint.

    The rewritten URL (for example, https://security-proxy.example.com/___https://myapp.azurewebsites.net/___<encoded-data>) is an internal construct of the organization’s SWG/proxy. It is designed for traffic that first enters the corporate network (or VPN / managed devices) and is then routed through the SWG. Making that SWG URL “public” would require exposing the SWG itself to the internet and allowing unauthenticated external clients to use it, which is outside normal Azure App Service or Azure OpenAI patterns and is controlled entirely by the organization’s network/security team, not by Azure configuration.

    From an Azure architecture perspective, the SWG URL is not the correct public entry point for global users.

    1. With a public Azure Web App:
    • Internal users can continue to use the SWG‑rewritten URL if corporate policy forces all outbound web traffic through the SWG. The SWG will still rewrite https://myapp.azurewebsites.net (or a custom domain) into its internal format for those users.
    • External/global users should access the application via the Web App’s public hostname (for example, https://myapp.azurewebsites.net) or a custom domain mapped to the Web App. They should not use the SWG‑rewritten URL, because that URL depends on the corporate SWG infrastructure and is not a standard public endpoint.
    1. The proposed architecture is supported and aligns with documented patterns:
    • Public Azure Web App (App Service) for user access.
    • VNet Integration enabled (outbound) so the Web App can send traffic into a virtual network.
    • Azure OpenAI resource with public network access disabled and a Private Endpoint in the VNet.
    • Private DNS zone configured so the Web App resolves the Azure OpenAI hostname to the Private Endpoint IP.

    The documentation explicitly describes this pattern for a web app that talks to an Azure OpenAI resource with public network disabled:

    • Configure a private DNS zone mapping the Azure OpenAI hostname to the Private Endpoint IP.
    • Link the private DNS zone to the VNet used by the Web App.
    • Enable VNet Integration on the Web App and place it in a subnet that can reach the Private Endpoint.

    This results in:

    • Users (internal or external) only see and call the Web App.
    • The Web App calls Azure OpenAI privately over the VNet via the Private Endpoint.
    1. Custom domain and WAF considerations:
    • Custom domain: Not required by Azure for functionality, but commonly recommended for production, branding, and easier DNS-based controls. Global users can use either the default *.azurewebsites.net hostname or a custom domain.
    • Web Application Firewall (WAF): Not required by the App Service/OpenAI integration itself, but recommended for internet-facing applications that need enhanced security (for example, OWASP rule sets, IP restrictions, geo-filtering). In Azure, WAF is typically provided via services such as Azure Front Door or Application Gateway in front of the Web App. This is an architectural choice based on the organization’s security posture, not a requirement for the VNet Integration + Private Endpoint pattern.
    1. Relevant Azure architectural best practices / limitations for this pattern:
    • Keep Azure OpenAI private: Use Private Endpoint and disable public network access on the Azure OpenAI resource so only the Web App (and other authorized workloads in the VNet) can reach it.
    • Use VNet Integration correctly: Ensure the Web App is deployed in a SKU that supports VNet Integration and that the integration subnet has proper routing to the Private Endpoint subnet.
    • Configure private DNS: Create a private DNS zone, add a record for the Azure OpenAI hostname pointing to the Private Endpoint’s private IP, and link the zone to the VNet used by the Web App. Without this, the Web App will not resolve the Azure OpenAI endpoint to the private IP.
    • Keep the Web App as the only public surface: Users should only access the Web App; the Azure OpenAI endpoints remain private behind the VNet and Private Endpoint.
    • Authentication and authorization: For the Web App itself, use App Service authentication/authorization and/or an identity provider (for example, Microsoft Entra ID) as appropriate. For Azure OpenAI, use managed identity or keys from the Web App, not from the client.

    These practices match the documented “web app + private Azure OpenAI” configuration where the Web App is integrated with a VNet and uses a Private Endpoint to reach Azure OpenAI while public access to Azure OpenAI is disabled.

    References:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.