Note: This is the second article on the topic of integrating Static Web Apps with resources bound to a virtual network. See the first article for more context: Integrating network isolated backends with Azure Static Web Apps (microsoft.com)
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.
I’ve previously documented a pattern to do so with the article Integrating network isolated backends with Azure Static Web Apps (microsoft.com). In this article, I document an alternative method that can be used to integrate Static Web Apps within an architecture that has VNET-isolated resources using Function Apps (or Web Apps).
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.
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.
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
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.
- 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.
- 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.
Conclusion
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.
Read more about architectures to integrate Static Web Apps with network isolated backends here: Integrating network isolated backends with Azure Static Web Apps (microsoft.com)