Should an application use the privatelink Blob hostname to force private connectivity?

In a worked migration scenario, an engineer changes the blob endpoint in application settings from the normal account hostname to the privatelink form. The aim is to guarantee private traffic, but connectivity becomes inconsistent between environments. What hostname should remain in the application, and what evidence actually proves the private route?

Use the normal service endpoint for the storage account. Azure’s DNS arrangement allows that hostname to resolve through the private-link chain to the intended private address inside the configured network. The private route is established by DNS visibility and network reachability, not by inventing another application endpoint.

Restore the supported hostname, inspect resolution from the application environment and verify the returned address against the endpoint. Then test the required storage operation. Keep TLS verification enabled throughout; hostname changes and certificate bypasses can hide an incorrect endpoint configuration.

Our laptop outside the VNet resolves publicly. Does that invalidate the VM test?

No. Different network contexts can intentionally receive different DNS answers. The production workload’s resolver and route are the relevant ones for its private connection.

Also check the storage subresource. Private connectivity for blobs does not automatically cover queues, files or every other service under the account. Test the endpoint your operation actually uses.

Should an application use the privatelink Blob hostname to force private connectivity?

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments