Private Endpoint and VNet firewall recommendation for Azure Storage Account

Hi @ $@chin,

Private Endpoints vs VNet Rules in Azure Storage

A lot of people assume that once you add a private endpoint to a storage account, it’s fully locked down—but that’s not exactly how it works.

Yes, a private endpoint gives your storage account a private IP inside your VNet, so traffic flows over Microsoft’s backbone instead of the public internet. That part is good from a security perspective.

But here’s the catch: it doesn’t automatically disable the public endpoint.

So unless you explicitly block it, your storage account is still accessible from the public internet. Even if all your applications are using the private endpoint, the public endpoint is technically still open.

That’s why Advisor or Defender keeps flagging it. From the platform’s point of view, public access is still possible, so it raises a warning.

What you should do about it

If your goal is to fully lock it down, you have two options:

Disable public network access completely

Or restrict it using firewall / VNet rules

In most secure setups, we just disable public access altogether and rely only on private endpoints.

How to think about it (practical view)

Private endpoint → secures your private path only

Public endpoint → still exists unless you explicitly block it

So just adding a private endpoint is not equal to locking down the storage account.

Design choices (what I’ve seen work in real setups)

Private endpoint only Use this when you want strict isolation. Everything goes through private connectivity. Downside: you need proper VNet connectivity everywhere (no direct public access).

VNet rules only This is easier to set up. You’re still using the public endpoint but restricting who can reach it. Good for simpler or transitional setups, but not as secure.

Combination of both This is actually quite common.

Critical workloads → private endpoints

  Specific allowed access → controlled via firewall/VNet rules
  

About the Defender/Advisor warning

If you’ve already completely blocked public access, you can safely ignore it (it’s just being overly cautious sometimes)

If public access is still open → then the warning is valid, and you should fix it

Hi @ $@chin,

Welcome to Microsoft Q&A Platform

It sounds like you’ve got your Private Endpoint up and running, but Defender/Advisor is still flagging “restrict network access using virtual network rules.”

That recommendation is actually calling out the storage account’s Firewall & virtual network settings on the public endpoint—which is separate from Private Link.

Why you’re still seeing the recommendation

• Creating a Private Endpoint only adds a private IP for your VNet and routes traffic over Microsoft’s backbone it does not automatically disable the public endpoint or flip on firewall rules under “Selected networks.” Defender looks at whether you’ve restricted the public endpoint via Firewall/VNet rules, so if you haven’t set that, you’ll keep getting the advice.

Does Private Endpoint alone lock down public access?

• No. By default, the public endpoint stays open (to “All networks”) even after you create a Private Endpoint. You must explicitly change the networking settings to block or restrict public access.

Do you still have to configure firewall/VNet rules?

• Yes, if you want to fully lock down public access. Go to your Storage Account > Networking > Firewalls and virtual networks: a. Select “Selected networks” b. Add your VNet/subnet(s) (your Private Endpoint subnet is fine here) c. Optionally remove any “Allow All” entries or disable Public network access d. Save

Best practice recommendation

• Use Private Endpoints for true isolation AND
• Enable Firewall/VNet rules on the public endpoint (Selected networks only), or even disable public access entirely. This gives you defense-in-depth: all traffic must come over the private link/subnet that you explicitly allow. If you only rely on Private Endpoint without changing the firewall settings, you still leave a public path
  open (and Defender will remind you to lock it down).

Ref:
Configure network access to Azure Storage (Firewalls & Virtual Networks) https://learn.microsoft.com/azure/storage/common/storage-network-security?tabs=azure-portal

• Use private endpoints for Azure Storage https://learn.microsoft.com/azure/storage/common/storage-private-endpoints
• Azure Storage firewall rules (Virtual network rules) https://learn.microsoft.com/azure/storage/common/storage-network-security-virtual-networks
• Restrict network access recommendation (Defender for Cloud) https://learn.microsoft.com/azure/defender-for-cloud/review-security-recommendations#restrict-network-access-for-storage-accounts

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Hi @$@chin ,

did you disable the public access for the Storage Account as well?

The access to a Storage Account is possible using different ways/connections.

For that reason it is recommended to disable the "Public network access" if it's not required to access from public/internet.

(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

Regards

Andreas Baumgarten

Private endpoints and virtual network (VNet) rules solve related but different problems for Azure Storage.

1. Why Advisor/Defender still recommends VNet rules

Azure Advisor/Defender checks the storage account’s public endpoint configuration and firewall rules. A private endpoint:

• Assigns a private IP from a VNet and secures traffic over the Microsoft backbone network.
• Does not automatically block the public endpoint.

So even if all applications are using the private endpoint, the storage account’s public endpoint may still be reachable unless explicitly restricted. Advisor/Defender flags this and recommends restricting public access using firewall/VNet rules.

Relevant points:

• “Creating a private link does not automatically block connections on the public endpoint.”
• “When access to the public endpoint is disabled, the storage account can still be accessed through its private endpoints. Otherwise valid requests to the storage account's public endpoint will be rejected.”

2. Does enabling a private endpoint automatically secure from public access?

No.

• Private endpoint secures one path (private link) to the storage account.
• The public endpoint remains active unless you:
  • Disable public network access, or
  • Restrict it with firewall rules (VNet rules, IP rules, trusted services, etc.).

From the network security overview:

• “You can secure your storage account by requiring HTTPS connections, implementing private endpoints for maximum isolation, or configuring public endpoint access through firewall rules and network security perimeters.”

3. Is it required to configure firewall rules when a private endpoint is in place?

Not strictly required for functionality, but required if the goal is maximum isolation and often for security/compliance:

• With only a private endpoint configured and no firewall restrictions, the public endpoint is still open.
• To ensure traffic comes only via private link, you must block or restrict the public endpoint.

Options for the public endpoint when using private endpoints:

• Best isolation: Set Public network access = Disabled. Then:
  • All access must use private endpoints.
  • “When access to the public endpoint is disabled, the storage account can still be accessed through its private endpoints.”
• Controlled public access: Keep public endpoint enabled but restrict via:
  • VNet service endpoints (virtual network rules), and/or
  • IP rules, and/or
  • Trusted service exceptions.

4. Recommended best practice in this scenario

From the provided guidance:

• “Where possible, create private links to your storage account to secure access through a private endpoint… To permit traffic only from private links, you can block all access over the public endpoint. Private endpoints incur extra costs but provide maximum network isolation.”

Given that all traffic is already using the private endpoint:

Recommended pattern for maximum security:

• Use private endpoints for all required access.
• Disable public network access on the storage account (or otherwise deny all public endpoint traffic).
• Optionally allow trusted Microsoft services if needed (for example, Azure File Sync or other first-party services), understanding that trusted services can still access even when public network access is disabled, per the firewall limitations.

This aligns with:

• “Create one or more private endpoints for the storage account and disable access to the public endpoint. This ensures that only traffic originating from within the desired virtual networks can access the Azure file shares within the storage account.”

5. Private endpoint only vs VNet rules vs both

Based on the context:

• Private endpoint only (with public network access disabled)
  • Pros: Maximum isolation; traffic only over private link; no exposure on public IP.
  • Cons: Requires that all consumers can reach the VNet (via VNet peering, VPN, ExpressRoute, etc.).
• VNet rules/service endpoints only (no private endpoint)
  • Pros: Simpler in some scenarios; still uses public endpoint but restricted to specific VNets.
  • Cons: Traffic still goes to the public IP; less isolation than private endpoint.
• Both private endpoint + VNet rules
  • Typical when:
    • Some workloads use private endpoints.
    • Others still need controlled public endpoint access via service endpoints.
  • For pure private-link-only designs, VNet service endpoints for the same storage account are not required and can be avoided.

6. What to do about the Advisor/Defender recommendation

If the design goal is private-link-only access and:

• Public network access is disabled, or
• Public endpoint is otherwise fully blocked,

then the recommendation is effectively an additional hardening suggestion focused on the public endpoint. In that case, it can be ignored or exempted as long as the organization’s security/compliance requirements are met.

If public network access is still enabled, then to satisfy the recommendation and improve security:

• Either disable public network access and rely solely on private endpoints, or
• Configure firewall rules (VNet rules/IP rules/trusted services) to restrict the public endpoint.

References:

• Use private endpoints for Azure Storage
• Azure Storage network security
• Configure Azure File Sync public and private network endpoints
• Improved-security access to App Service web apps from an on-premises network
• Security recommendations for Blob storage
• Guidelines and limitations for the Azure Storage firewall
• Azure Storage firewall rules
• Network security perimeter for Azure Storage