On-premise to Azure SQL connectivity

Question

I'm seeking a low-cost solution for on-premise to Azure SQL connectivity.

We already have an Azure environment with 4 Subscriptions in a Hub & Spoke model. Traffic from within the on-premise VPN connects to the Hub VNet via a VPN Gateway, then it connects to the 3 Spokes using VNet peering.

I want to deploy Azure SQL databases in the 3 spoke Subscriptions. What networking/connectivity requirements should I consider? DNS, Private Link, VNet integration, SubNet delegation etc.

The Microsoft.Sql resource provider is already enabled for all 4 Subscriptions.

For additional context, I already have some PostgreSQL Flexible Servers deployed within SubNets in the 3 Spoke VNets. FQDN calls from on-premise clients are handled by an on-premise DNS server which conditionally forwards the request onto a Private DNS Resolver resource in the Hub VNet, with an inbound endpoint. This then passes the request onto Azure DNS for ultimate resolution.

Are there any components of the PostgreSQL setup I can re-use for an Azure SQL setup?

Thanks.

Answer 1

https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-architecture?view=azuresql

https://techcommunity.microsoft.com/t5/azure-database-support-blog/azure-sql-db-private-link-private-endpoint-connectivity/ba-p/1235573

Connectivity Architecture: For clients connecting to Azure SQL Database, the connection is first established to the gateway that has a public IP address and listens on port 1433. The gateway then redirects or proxies the traffic to the appropriate database cluster.

Connection Policies: Azure SQL supports three connection policies: Redirect, Proxy, and Default. The Default policy is Redirect for all client connections originating inside of Azure and Proxy for all client connections originating outside of Azure, like your on-premise connections. However, Microsoft recommends the Redirect policy for lower latency and higher throughput, although it requires additional network traffic management. Connections to private endpoints only support the Proxy connection policy.

Private Link/Private Endpoints: Azure will create a CNAME on the public DNS to redirect the resolution to the suggested domain names. This allows the applications to connect without changing the connection URL as the DNS server will now resolve to the private endpoints.

DNS Configuration: If your client is in Azure, the DNS on the VM can be a forwarder to Azure DNS. If you are using an on-premise DNS, you might need a Conditional Forwarder. The DNS Domain should be database.windows.net. You can check if the name resolution works correctly by using the nslookup command with your database's FQDN. If you don't want to use a forwarder, you can create a forward lookup zone and manually add the host to match the FQDN.

VNet Integration: To make Azure Function connect to a private endpoint, you'll need to use VNet integration. After your app integrates with your VNet, it uses the same DNS server that your VNet is configured with. To work with Azure DNS Private Zones, add the following app settings:

• WEBSITE_DNS_SERVER with value 168.63.129.16
  • WEBSITE_VNET_ROUTE_ALL with value 1.
  Private Zone Network Link Configuration: You should configure private zone network links for both networks. This model can be extended to multiple peered virtual networks that are associated with the same private endpoint, by adding new virtual network links to the private DNS zone for all peered virtual networks. Components from your PostgreSQL setup that you can reuse for an Azure SQL setup include the on-premise DNS server, Private DNS Resolver resource in the Hub VNet, and potentially the Azure DNS, depending on your existing DNS configuration.