This example scenario describes how to set up private connectivity from an Azure Web App to Azure Platform-as-a-Service (PaaS) services, or between Azure PaaS services that aren't natively deployed in isolated Azure Virtual Networks. The example shows a typical combination of hosting a web application in Azure App Service and connecting to Azure SQL Database.
The web app can securely connect to a backend database over a fully private connection. The public internet can't reach the database, which eliminates a common attack vector.
Potential use cases
These similar design patterns are variations on the same underlying principle:
Connect from a Web App to Azure Storage, Azure Cosmos DB, Azure Cognitive Search, Azure Event Grid, or any other service that supports an Azure Private Endpoint for inbound connectivity.
Connect from an Azure Functions App to any Azure service that supports an Azure Private Endpoint, as long as the Function App is deployed in a pricing plan that supports Virtual Network integration.
Connect from a Web App or Functions App to another Web App, because App Service also supports Private Endpoints for inbound connectivity. For example, connect from a website to a REST API hosted in another Azure App Service instance.
1. Using Azure App Service regional VNet Integration, the web app connects to Azure through an AppSvcSubnet delegated subnet in an Azure Virtual Network.
o In this example, the Virtual Network only routes traffic and is otherwise empty, but other subnets and workloads could also run in the Virtual Network.
o The App Service and Private Link subnets could be in separate peered Virtual Networks, for example as part of a hub-and-spoke network configuration.
2. Azure Private Link sets up a private endpoint for the Azure SQL Database in the PrivateLinkSubnet of the Virtual Network.
3. The web app connects to the SQL Database private endpoint through the PrivateLinkSubnet of the Virtual Network.
4. The database firewall allows only traffic coming from the PrivateLinkSubnet to connect, making the database inaccessible from the public internet.
Components
This scenario uses the following Azure services:
Azure App Service hosts web applications, allowing autoscale and high availability without having to manage infrastructure.
Azure SQL Database is a general-purpose relational database managed service that supports relational data, spatial data, JSON, and XML.
Azure Virtual Network is the fundamental building block for private networks in Azure. Azure resources like virtual machines (VMs) can securely communicate with each other, the internet, and on-premises networks through Virtual Networks.
Azure Private Link provides a private endpoint in a Virtual Network for connectivity to Azure PaaS services like Azure Storage and SQL Database, or to customer or partner services.
Alternatives
An alternative approach for private connectivity is an App Service Environment for hosting the web application within an isolated environment, and Azure SQL Managed Instance as the database engine. Both of these services are natively deployed within a Virtual Network, so there's no need for VNet Integration or private endpoints. These offerings are typically more costly, because they provide single-tenant isolated deployment and other features.
If you have an App Service Environment but aren't using SQL Managed Instance, you can still use a Private Endpoint for private connectivity to a SQL Database. If you already have SQL Managed Instance but are using multi-tenant App Service, you can still use regional VNet Integration to connect to the SQL Managed Instance private address.
As an alternative to the Private Endpoint, you can use a Service Endpoint to secure the database. With a Service Endpoint, the private endpoint, PrivateLinkSubnet, and configuring the Route All regional VNet integration setting are unnecessary. You still need regional VNet Integration to route incoming traffic through the Virtual Network.
Compared to Service Endpoints, a Private Endpoint provides a private, dedicated IP address toward a specific instance, for example a logical SQL Server, rather than an entire service. Private Endpoints can help prevent data exfiltration towards other database servers.
Considerations
The following considerations apply to this scenario.
Security
This scenario secures the outbound connection from an App Service web app to a downstream dependency like a database. You can secure the inbound connection to the web app by fronting the app with a service like Application Gateway or Azure Front Door, optionally with Web Application Firewall capabilities.
To prevent users from bypassing the front-end service and accessing the web app directly, set App Service access restrictions like IP address rules or service endpoints.
SQL Database firewall options
The most important security consideration in this scenario is how to configure the SQL Database firewall.
Without using private connectivity, you can add firewall rules that allow inbound traffic from specified IP address ranges only. Another approach is to allow Azure services to access the server, which locks down the firewall to allow only traffic from within Azure. However, this traffic includes all Azure regions and other customers.
You can also add a more restrictive firewall rule to allow only your app's outbound IP addresses to access the database. But because App Service is a multi-tenant service, these IP addresses are shared with and allow traffic from other customers on the same deployment stamp, which uses the same outbound IP addresses.
Using private connectivity through the Virtual Network provides the following firewall options to prevent others from accessing the database:
Create a virtual network rule that allows traffic only from the regional VNet Integration delegated subnet, AppSvcSubnet in this example. The delegated subnet must have a Service Endpoint configured for Microsoft.Sql, so the database can identify traffic from that subnet.
Configure the firewall to Deny public network access, which turns off all other firewall rules and makes the database accessible only through its private endpoint.
The option of denying public network access is the most secure configuration but means that database access is only possible by going through the Virtual Network that hosts the private endpoint. To connect to the database, anything other than the web app must have direct connectivity to the Virtual Network.
Availability
Azure Private Link supporting Azure SQL Database is available in all public and government regions.
Private Link introduces an additional component and availability consideration into the architecture. The Private Link service has an availability SLA of 99.99%, which must be taken into account when calculating the composite SLA of the entire solution.
Global peering
Any service in any Azure region that can connect through the Virtual Network can reach the database's private endpoint.
Cost
There's no additional cost for App Service regional VNet Integration in a supported pricing tier of Standard or above. Standard is a minimum recommendation for production workloads.
The Azure Private Link service that enables the database's private endpoint has an associated cost based on an hourly fee plus a premium on bandwidth.
Logging and monitoring
Azure Private Link is integrated with Azure Monitor, which allows you to see if data is flowing and troubleshoot connectivity problems.