Add VNet Integration for managed API in Static Web App

[PaoloCastAway]

The need: reaching a VNet-bound resource from a managed API in Static Web App.

A VNet-bound resource could be a VM, or - more likely - a data source with a Private Endpoint (CosmosDB, SQL Database, Storage Account).

Today the data source must allow incoming public traffic, without even the ability of filtering by Service Tag. Most of the times this is forbidden by company policies.

If Static Web Apps could integrate into a VNet, that could solve the issue, i.e. one could block public access to the data source.

[ics-development]

I have the same issue, any ideas?

[thomasgauvin]

Thanks for the feedback Paolo Castaldi (@PaoloCastAway) and Kush Vadgama (@ics-development), this is something that we've also heard others ask for. At the moment, due to Static Web Apps' distributed architecture, it can't be deployed to VNETs (and therefore cannot proxy requests to network isolated backends). We're definitely noting the feedback.

[thomasgauvin]

Hey Paolo Castaldi (@PaoloCastAway) and Kush Vadgama (@ics-development)! I've been investigating this topic since I saw this thread. Regarding the managed API, it would not be possible to integrate it with VNET due to our distributed architecture like I mentioned, and also due to the fact that managed APIs are consumption Functions that have limited network integration options.

What you could do is create a standalone Function App with one of the plans that supports virtual network integration (https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options?tabs=azure-cli#matrix-of-networking-features), enable virtual network integration on that Function App to allow outbound requests on that Function App to access your resources in the virtual network, and then link that resource to your Static Web App resource as a Bring Your Own Function.

With this method, the Function App would be publicly accessible so that Static Web Apps' distributed runtime can route calls to these. Note that we lock down the inbound traffic to your Function App to ensure it only comes from us (Static Web Apps) for the backend integration feature.

On a similar note, I've written up a blog post considering different approaches for integrating network-bound APIs with Static Web Apps which may be an interesting read as well.

Hope this helps!

[artisticcheese]

Azure frontdoor have private endpoint integration, they figured out how to do that with distributed nature of FrontDoor, so shall be possible with static web apps too from that point of view.

[thomasgauvin]

GSA (@artisticcheese) Static Web Apps also has the ability to have a private endpoint to restrict any inbound traffic to a specific vnet. However, vnet integration to communicate to any downstream backend services is not possible with managed APIs of Static Web Apps. This is a use case we are looking into improving however, but at this time, the approaches I document above are recommended.

[artisticcheese]

I did not mean private endpoints for incoming connection but Frontdoor allows connections to services behind private endpoints (not exposed externally) in FrontDoor premium (https://learn.microsoft.com/en-us/azure/frontdoor/private-link), so technically Azure already allowed similar setup for different resource type with similar characteristic to Static Web Apps.

[MDendura]

I would be very keen to see this feature added too. Due to policy we are not allowed to turn on public networking for functions, container apps etc. and I imagine that this cannot be uncommon in other organisations.

It would also be useful to have an error message on creation of a linked backend to a resource that doesn't have public networking enabled as this would really help with diagnosing problems.

I had been tearing my hair out trying to understand what could have been causing a "Backend call failure" when the linked backend was successfully created and the auth appeared to be setup properly. After much searching I found this thread and realised it must be that the Static Web App backend cannot see our Container App sat on the VNet.

[cargallo]

When will this available?? It is a failure in the architecture design of SWA, since it has the option to be behind a private endpoint but no access to private apps service it has no sense at all.

[xInfinitYz]

+1

[FlorentATo]

For anyone interested, please upvote this feature here: https://feedback.azure.com/d365community/idea/fa02d50e-6967-ed11-a81b-000d3ae5ae95

[ycamargo]

As GSA (@artisticcheese) suggested, a Private Link from Static Web App to a backend would be the best option. It doesn't need to be injected on a VNET, but would allow us to configure backends without enabling their public endpoints. I have a configuration exactly like that using Azure Front Door with a Private Link for our APIM. APIM has its public endpoint disabled and Front Door routes public requests (after "WAFing" them) for a few API endpoints that needs to be publicly accessible.
We have some Angular applications that are meant to be accessed only through the internal network. Why it's possible to create a Private Endpoint for the Static Web App itself but, then, the backend application (which is way more critical to secure) needs to be publicly accessible. That doesn't make sense at all.