As a software developer I have never given the networking side of deploying a simple website much thought. I have just setup an App Service and a SQL database in Azure and called it a day. But it turns out this opens op for a world of problems.

This guide explains how to securely connect an Azure App Service to an Azure SQL Server using a Virtual Network (VNet). VNets provide enhanced security, allowing your services to communicate without exposing them to the public internet.

Note that we aren't using proper Azure naming convention in this example. This to make everything a bit easier to follow

Why Use a Virtual Network?

• Enhanced Security: Ensures only trusted resources access your SQL Server.
• Network Isolation: Resources are isolated within a VNet, protecting your data.
• Compliance: Meets security and regulatory requirements by controlling access.

Prerequisites

• Azure SQL Database
• Azure App Service

Step-by-Step Guide

Step 1: Set Up a Virtual Network and Subnets

You will need to create a Virtual Network (VNet) with two separate subnets: one for App Service VNet Integration and another for the Private Endpoint. This is required because App Service VNet Integration and Private Endpoints cannot share the same subnet.

Portal:

1. In the Azure Portal, search for Virtual Networks and click Create.
2. Define the Address Space (e.g., 10.0.0.0/16), which represents the range of private IPs assigned within the network.
3. Create two separate subnets:
   • Subnet 1: For App Service VNet Integration (e.g., AppServiceSubnet, 10.0.1.0/24)
   • Subnet 2: For Private Endpoint (e.g., PrivateEndpointSubnet, 10.0.2.0/24)

Azure CLI:

az network vnet create     --name AppSQLVNet     --resource-group <resource-group>     --address-prefix 10.0.0.0/16

az network vnet subnet create     --address-prefix 10.0.1.0/24     --name AppServiceSubnet     --vnet-name AppSQLVNet     --resource-group <resource-group>

az network vnet subnet create     --address-prefix 10.0.2.0/24     --name PrivateEndpointSubnet     --vnet-name AppSQLVNet     --resource-group <resource-group>

Step 2: Configure SQL Server Private Endpoint

The private endpoint gives your SQL Server a private IP within the VNet, ensuring it can only be accessed by resources inside the VNet. You will assign this private endpoint to the PrivateEndpointSubnet.

Portal:

1. Go to your Azure SQL Server and click on Networking.
2. Create a Private Endpoint and select PrivateEndpointSubnet to provide private access to your SQL Server.

Azure CLI:

az network private-endpoint create     --name sqlPrivateEndpoint     --resource-group <resource-group>     --vnet-name AppSQLVNet     --subnet PrivateEndpointSubnet     --private-connection-resource-id <sql-server-id>     --group-ids sqlServer     --connection-name sqlPrivateConnection

Step 3: Enable VNet Integration for the App Service

VNet integration allows your App Service to connect securely to resources within the Virtual Network. This step enables the App Service to access the SQL Server via the private endpoint. Be sure to assign the App Service to the AppServiceSubnet.

Portal:

1. In your App Service, go to Networking and select VNet Integration.
2. Add your VNet and select AppServiceSubnet, allowing the App Service to communicate with resources inside the VNet.

Azure CLI:

az webapp vnet-integration add     --name <app-service-name>     --resource-group <resource-group>     --vnet AppSQLVNet     --subnet AppServiceSubnet

Step 4: Configure SQL Database Firewall

To restrict access further, configure the SQL Server's firewall to allow traffic only from your VNet. This prevents unauthorized access from outside the VNet and enhances security.

Portal:

1. Under your SQL Server Networking settings, disable Allow Azure services to access this server to block all public access.
2. Add your VNet to the SQL Server's firewall rules, ensuring that only resources inside the VNet can access it.

Azure CLI:

az sql server vnet-rule create     --resource-group <resource-group>     --server <sql-server-name>     --name VNetRule     --vnet-name AppSQLVNet     --subnet PrivateEndpointSubnet

Step 5: Test the Connection

After setting up the VNet, subnets, and firewall, it's important to test the connection between your App Service and SQL Server. Update the App Service connection string to point to the SQL Server's private endpoint and verify that it works.

Step 6: Optional - Configure a Private DNS Zone

Using a private DNS zone is optional, but recommended. This step assigns a user-friendly DNS name (like my-sql-server.database.windows.net) to the SQL Server’s private endpoint, simplifying management. Without it, you’ll need to use the SQL Server’s private IP in the connection string, which can be more cumbersome.

Portal:

1. Create a Private DNS Zone (privatelink.database.windows.net) to associate a friendly DNS name with the SQL Server’s private endpoint.
2. Link the DNS Zone to your VNet for automatic name resolution.

Azure CLI:

az network private-dns zone create     --resource-group <resource-group>     --name privatelink.database.windows.net

az network private-dns link vnet create     --resource-group <resource-group>     --zone-name privatelink.database.windows.net     --vnet-name AppSQLVNet     --registration-enabled false

This step is optional but recommended for easier management.

Conclusion

By following these steps, you've securely connected your Azure App Service to an Azure SQL Server using a Virtual Network with proper subnet separation. The configuration ensures that your SQL Server is isolated from the public internet and only accessible from your VNet. Adding a Private DNS Zone is optional but recommended as it simplifies name resolution and resource management.

To further improve this setup, consider using Managed Identity for authentication instead of SQL login. This eliminates the need to store and manage credentials, making your environment more secure. Additionally, you can add Azure Front Door or Application Gateway to provide advanced traffic management and security features, such as load balancing, SSL offloading, and DDoS protection, further enhancing your application's availability and security.