1
votes

We have a SQL Azure database and enabled VNET service endpoint. The service endpoint is listed in our VNET and the Azure SQL lists our VNET. According to documentation found here, connections applications inside our VNET should use the Azure backbone and not travel through the public internet.

There was another stack overflow article asking a similar question but I still didn't see an answer (maybe I missed it). That article is here

This is great, but I don't see how to build the connection string to utilize this internal network path since the only name available is the public DNS name (which we can still use with SSMS to manage the server from our on-premise location).

Is Azure smart enough to know that this public DNS name is routed differently when used inside the VNET versus when its used from our on-premise site?

1

1 Answers

2
votes

Is Azure smart enough to know that this public DNS name is routed differently when used inside the VNET versus when its used from our on-premise site?

Yes. And that doesn't even require a VNET service endpoint. Connections within Azure, even across Regions never leave Microsoft private networks.

A Virtual Network Service Endpoint is mostly just a firewall rule on your SQL Instance, so you can cut off all public IP access if you want.