This guide explains how to secure API access to an Azure SQL Database by isolating traffic within a Virtual Network (VNet). It covers how VNets and subnets work, how to connect an Azure App Service (hosting the API) and Azure SQL Server to the VNet, and how to enable manual access to the database from outside the VNet when necessary.
Understanding Virtual Networks
An Azure Virtual Network (VNet) is a part of the Azure cloud where you can securely run your resources. It works similarly to a traditional on-premises network.
Address Space: A VNet has a defined IP address space (e.g. 10.0.0.0/16).
Subnets: This address space can be divided into subnets (e.g. 10.0.1.0/24) to organize and isolate different resources.
Service Endpoints: VNets can be configured to allow access to Azure services (like SQL Database) over the Azure backbone network instead of the public internet.
Resources connected to the same VNet or subnet can communicate securely and directly without exposing themselves to the internet.
Creating a Virtual Network and Subnet
- In the Azure Portal, go to Virtual Networks and select Create
- On the Basics tab, enter a name and select a region
- On the IP Addresses tab:
- Define an address space (e.g. 10.0.0.0/16).
- Under Subnets, create a new subnet (e.g. app-subnet) with a subnet range such as 10.0.1.0/24.
- Complete the rest of the steps and click Create.
This sets up the network structure required to isolate and secure communication between the API and the SQL Database.
Integrating the App Service with the VNet
To enable the App Service to communicate with resources inside the VNet:
Enable Service Endpoints for Microsoft.Web on the Subnet
- Go to Virtual Networks > select your VNet > Subnets
- Under Service Endpoints, click + Add.
- Select Microsoft.Web and click Add.
Configure the App Service to connect to the VIrtual Network
- Go to the App Service in the Azure Portal.
- Navigate to Networking > Virtual Network Integration.
- Click Network Integration.
- Select the previously created Virtual Network and the appropriate subnet (e.g. app-subnet)
- Click OK to apply the integration.
This allows the App Service to send outbound traffic into the VNet and access private Azure resources, including the SQL Server.
Configuring SQL Server to Restrict Access to the VNet
By default, Azure SQL Servers are publicly accessible. To restrict access so that only traffic from the VNet is allowed:
a. Enable Service Endpoints for Microsoft.Sql on the Subnet
- Go to Virtual Networks > select your VNet > Subnets.
- Click on the subnet used by the App Service.
- Under Service Endpoints, click + Add.
- Select Microsoft.Sql and click Add.
This allows the subnet to connect to Azure SQL via Azure’s private backbone network.
b. Configure the SQL Server Firewall to Allow Only VNet Access
- Go to your SQL Server resource (not the database).
- Navigate to Networking > Firewall and virtual networks.
- Under Virtual Networks, click + Add existing virtual network.
- Choose the same Virtual Network and subnet used by the App Service
- Under Public access, set Deny public network access to Yes.
- Click Save.
With these settings, only resources inside the specified VNet (such as your App Service) will be able to connect to the SQL Database. All public traffic will be blocked.
Accessing SQL Server Manually from Outside the VNet
To connect to the SQL Server from a local development machine or other external source (e.g., using SQL Server Management Studio):
Option 1: Whitelist the Client IP
- Go to the SQL Server > Networking > Firewall rules.
- Click + Add client IP to allow access from your current machine’s IP address.
- Click Save.
This grants temporary access to your machine. Remove the rule when access is no longer needed.
Option 2: VPN Access to the VNet
As an alternative, you can set up a VPN Gateway for your VNet. This allows remote machines to securely connect to the VNet and access private resources as if they were inside Azure. This method is more secure and scalable but is outside the scope of this tutorial.
Conclusion
Setting up your App Service and SQL Database inside a Virtual Network gives you a secure way for them to talk to each other without exposing anything to the public internet. It keeps your data protected while still letting you connect manually when needed, either by whitelisting your IP or using a VPN for more secure access.
