Azure Static Web Apps is the ideal service for hosting modern frontend web apps and static sites on Azure. Many customers rely on Static Web Apps to host their HTML/CSS/JS, React, Vue, Angular, Blazor or NextJS apps (among others!), and they complement these with their APIs, microservices and other services such as databases. At times though, these downstream services are isolated within a virtual network, preventing access from Static Web Apps’ managed Azure Functions. This article explains how we can configure our Static Web Apps to support such access by leveraging Static Web Apps’ linked backends feature.
How can Azure Static Web Apps backends be configured to access network isolated APIs and databases
For context, Azure Static Web Apps is an optimized global host for modern frontend web apps, with globally distributed static content hosts, complemented by managed consumption Azure Functions that can be used as APIs or as compute for these frontend web apps. These Azure Functions are managed by the Static Web Apps resource itself.
Architecture diagram of a Static Web Apps resource trying to access network isolated web app or database
Since network isolation of databases or APIs prevents access from Static Web Apps’ managed functions, we can configure our Static Web Apps’ resource to have a linked standalone Azure Function instead of the Static Web Apps-managed Function App. Then, this standalone managed function can be integrated into the virtual network to have access to these network isolated services.
Architecture diagram of Static Web Apps with Azure Functions linked backend, integrated into a virtual network and accessing a web app and database
With this architecture, the Static Web App will proxy requests made to the ‘/api’ endpoint to the publicly available Azure Function resource, and this resource will be able to make requests to any APIs or databases within the virtual network that it is integrated into. Moreover, the connection between the Static Web Apps and the Azure Function will be secured through the linked backends feature.
Note: Static Web Apps supports private endpoints. This means that inbound traffic to the Static Web App can be restricted to a virtual network. However, outbound traffic from the Static Web App or Static Web Apps’ managed function cannot be restricted to a virtual network.
How to configure an Azure Static Web Apps with a linked Azure Function that is integrated into a virtual network
Diagram depicting converting a Static Web Apps without VNET-access into an architecture with VNET-access
We can convert a Static Web Apps with managed functions that does not have access VNet-bound resources, into an architecture that enables such access. Doing so involves the following steps:
Move the managed function into a standalone Azure Function
The Static Web Apps’ managed function must be converted into a standalone Azure Function resource to integrate it into the virtual network. As detailed in the Azure Functions docs, the Azure Functions must be of Premium, Dedicated or ASE plan for virtual network integration to be supported.
If the code for the managed function was previously in the same repository as the Static Web App, the deployment to the Azure Functions resource can be configured with the repository as a source by following the steps in the Deployment center.
Integrate the standalone Azure Function into the virtual network
Once the code has been deployed to the Azure Function, the Azure Function resource can be integrated into a virtual network. This can be done directly from the Azure Portal in the Networking tab of the Azure Function. Specifically, we are focused on setting up the outbound traffic to have VNet integration.Screenshot of Azure Functions networking tab
Note that the Function app cannot have access restriction or private endpoint, as it must be publicly accessible for Static Web Apps’ distributed hosts to have access to it. The following step will ensure that traffic to the backend resource is secured through Static Web Apps’ linked backend feature, which will restrict all traffic coming into the resource to the Static Web Apps resource.
Link the resource as a linked backend to the Static Web Apps resource
From the Static Web Apps’ APIs blade, we can link the Function App to the production Static Web Apps’ environment.Screenshot of Static Web Apps APIs blade
Doing this will configure the Static Web Apps’ resource to proxy requests made to the /api endpoint to the backend resource. When doing so, the backend resource will be configured to only accept requests from the Static Web Apps’ application, to ensure that the access to the backend resource is secured. With linked backends, the proxied requests to the backend API will also be injected with the authentication headers needed to use Static Web Apps’ authentication feature.
At this point, we have the workaround architecture proposed above. Requests made to the default-swa-hostname.azurestaticapps.net/api will be proxied by the Static Web Apps’ hosts to the standalone Azure Function, which can access the virtual network resources because of its virtual network integration.
Screenshot of a request to Static Web Apps' linked backend, showing access to network isolated database
In conclusion, by using Static Web Apps’ linked backends feature, we can securely configure a standalone Azure Function to serve as the Static Web Apps’ linked backend. Then, the Azure Function can be integrated into the virtual network, so that it can access the resources that are bound to that VNet, such as a database or an API.