Forum Discussion
Storage Accounts - Networking
Hi All, Seems like a basic issue, however, I cannot seem to resolve the issue. In a nutshell, a number of storage accounts (and other resources) were created with the Public Network Access set a...
When you switch a storage account from public access to "selected virtual networks and IP addresses" or to disabled public network access, existing clients can break unless you also create an allowed private or trusted path.
The clean pattern is:
- Identify every client that uses the account: VMs, apps, build agents, Functions, backup jobs, portal users, and any SaaS/service integration.
- If clients are in VNets, prefer Private Endpoints for the required subresources: blob, file, queue, table, dfs if ADLS Gen2 is used.
- Configure private DNS zones so the storage FQDN resolves to the private endpoint from the VNet.
- If you use service endpoints instead, add the exact VNet/subnet to the storage firewall. Remember that this still uses the storage public endpoint with VNet-based authorization.
- Do not disable public network access until private endpoint DNS and client testing are complete.
For most production designs, Private Endpoint plus private DNS is easier to reason about than broad IP allowlists.
Useful docs:
https://learn.microsoft.com/azure/storage/common/storage-network-security
https://learn.microsoft.com/azure/storage/common/storage-private-endpoints
https://learn.microsoft.com/azure/private-link/private-endpoint-overview