Azure SQL Database and Private Endpoint

A practical note on Azure SQL Database, Private Endpoint, and regional constraints in virtual network selection

I recently had the opportunity to configure the networking settings for an Azure SQL database, and I would like to share an aspect I had not considered during the initial deployment decisions for the solution.

The solution includes an Azure SQL database, an application, and an Azure virtual machine hosting the application, which needs to connect to the database.

For security reasons, the application database must be accessible, in some cases, from the public internet, after authorizing the client IP address on the database-level firewall. The database must obviously also be accessible from the Azure VM. In addition, the principle of least privilege must always be respected.

After deploying the Azure SQL database and the virtual machine, since there were no current access requirements from the public internet, I disabled public access to the SQL server. The configuration of IP addresses in the firewall can be done later.

The next step was to configure a Private Endpoint that would allow the VM to connect to the database through private connectivity, limiting access from the virtual network where the virtual machine hosting the application is located.

The procedure is described in the Microsoft documentation at this link.

It consists of configuring a private endpoint capable of connecting the VM’s virtual network to the Azure SQL server through Azure Private Link. To do this, simply access the Networking blade in the Security section of the SQL server. The Create a private endpoint button in the Private access tab opens the configuration page; however, in my case, it was not possible to select the virtual network associated with the virtual machine, and therefore the private endpoint could not be created.

Looking at the networks available for association, I realized that the list only included virtual networks deployed in the same region selected for the Private Endpoint. The VM I was trying to connect was instead located in a different region. The issue, therefore, was not the region of the Azure SQL server, but the region selected for the Private Endpoint: by selecting the same region as the VM’s virtual network, the network appeared among the selectable options, and I was able to complete the configuration.

Conclusions

In the case of Private Endpoints, the selectable virtual network must be located in the same region as the Private Endpoint being created. The Azure SQL server can also be located in a different region, because the resource connected through Private Link does not necessarily have to be deployed in the same region as the virtual network.