Private Endpoint, Same Server Name: Azure SQL Connection Strings

Private Link changes where a connection lands, not what the connection is called. For Azure SQL Database that distinction is the whole design: the logical server keeps its name, and the private endpoint supplies a network entry the name resolves to. Replacing the name with an IP address is the one change that breaks TLS, credentials and tooling at the same time. Two connection strings can look equivalent and behave nothing alike.

Keep orders-db.database.windows.net and give the client a private answer for it.

The name and the address have different jobs

The name identifies the SQL service, which is what the certificate and the login expect. The private address supplies a network entry inside the connected virtual network. Confusing one for the other produces a connection that reaches something and authenticates against nothing.

Microsoft's guidance for Azure SQL requires the normal server name from clients. A direct IP, and equally the privatelink-prefixed name, is not an interchangeable login target. Tools that accept an IP will accept it and then fail at TLS or at authentication, which hides the real mistake. Those failures read like credential problems until you look at the hostname in the error.

What the private zone actually changes

The private DNS zone records one address for the server inside the privatelink namespace, and the zone is linked to the virtual network that should use it. Resolution moves; the connection string does not. The shape below is an illustration, not a record to paste into a public zone.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Maintain that record and its zone link as infrastructure, with an owner and a review date.

Two zones with the same origin and different answers is the normal end state, not a conflict. Public clients keep the public answer, and private clients get the endpoint address. The failure mode to watch for is partial propagation of the private view, where one subnet resolves privately and another quietly does not.

Clients outside Azure need a path into that zone

A VPN client sits outside Azure's resolver, so the private zone has to be reachable from the hybrid path. An Azure DNS forwarder or Azure DNS Private Resolver can serve queries arriving through that network. Microsoft's guidance is to forward the relevant public service zone through that arrangement rather than assume clients query the privatelink name directly. Clients that cannot resolve the private answer fall back to the public one without complaining.

Keep forwarding scope intentional, because replacing an in-use public zone breaks names the replacement does not contain.

Provision in an order that keeps identity fixed

The steps have separate owners: create and approve the endpoint, provide the VPN route, integrate private DNS, then configure the client with its normal server name. Doing DNS before the route produces timeouts that look like DNS failures. Doing the client last keeps one variable moving at a time. Each step has an observable result, so none of them has to be tested by guessing.

A connected VPN icon does not select a private destination by itself.

What a private endpoint does not switch off

Creating a private endpoint does not automatically disable public access to the logical server. That is a separate deployment decision, and it belongs after the intended private clients are confirmed working. Keep a recovery path and account for applications still using the public entry. Turning public access off first is how a working service becomes an outage with a tidy audit trail.

Check which connection policy the server uses as well.

Redirect sends the client to a port on the node after an initial gateway connection, which changes what the client network must allow. Proxy keeps traffic on the gateway. A successful TCP handshake on one port is not the whole login workflow.

This is Azure SQL Database, not SQL Managed Instance, which has its own connectivity model and no equivalent private endpoint story. In both cases, keep three things labelled separately: the name, the network entry, and the credential. Changing where a connection travels should never change which service the client thinks it is talking to.