Azure Blob Storage Private Endpoint Access Across Subscriptions & VNets – Cost

Question

Hello All,

I’d like to validate my understanding of Azure Private Endpoint and Blob Storage access across subscriptions and VNets, especially regarding costs and required architecture.

Scenario:

I have a Blob Storage account in Subscription A (sub1), with public endpoint disabled.

• I have Azure Functions in two different VNets:
  • azfunc1 in Subscription B (sub: abc), VNet: vnet-abc
  azfunc2 in Subscription A (sub1), VNet: vnet-sub1 Both subscriptions and VNets are in the same Azure region. Both functions need to access the Blob Storage privately (no public endpoint).

My understanding:

1. Private Endpoint Placement:
   • I need to create a Private Endpoint for the Blob Storage in each VNet that requires private access (so one in vnet-abc for azfunc1, one in vnet-sub1 for azfunc2).
   The storage account itself does not need a separate Private Endpoint—just the VNets that need to access it.
2. VNet Peering:
   • VNet peering between vnet-abc and vnet-sub1 is not required for Blob Storage access if each VNet has its own Private Endpoint to the storage account.
   DNS: Each VNet must have DNS configured so the storage account’s FQDN resolves to the Private Endpoint’s private IP in that VNet.
3. Cost:

For each Private Endpoint, I pay the hourly fee (about $0.015 AUD/hr) and the data processing fee ($0.015 AUD/GB).

• For example, if azfunc1 in vnet-ai reads 1TB/month from Blob Storage, the cost is:

Private Endpoint fixed fee: ~$10.80 AUD/month

- Data processed: 1240GB × $0.015 = $15.36 AUD

- **Total for 1TB/month:** $16.44 AUD for that Private Endpoint.

• If azfunc2 in vnet-sub1 also reads 1TB, the same cost applies for its Private Endpoint.

No additional cost for VNet peering in this scenario, since peering is not used for Blob Storage access.

Questions for validation:

Is my understanding correct on the need for one Private Endpoint per VNet (not per storage account)?

Is it correct that VNet peering is unnecessary for this pattern?

Are the costs as described above accurate for this scenario?

Are there any best practices or caveats I should be aware of for this cross-subscription, cross-VNet, same-region setup?

Answer 1

Hello, Welcome to Microsoft Q&A

I will try to answers all your question making a detail explanation with official documentation from Microsoft supporting it .

Private Endpoints are VNet-scoped, meaning if multiple VNets need to access a single Storage Account, you must create a separate Private Endpoint per VNet. https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints

• It’s tied to the network interface inside a specific VNet.
• So in your case:
  • One Private Endpoint in vnet-abc (Subscription B)
  • One Private Endpoint in vnet-sub1 (Subscription A)

You do not need multiple storage accounts or multiple endpoints per subscription — just per VNet

Since each VNet has its own Private Endpoint, no VNet peering is needed.The traffic from the function to the Blob Storage stays within the VNet, and DNS resolves to the local Private IP of the endpoint.

However, VNet peering might be required if:

• You consolidate DNS resolution (e.g., centralized private DNS zone in one VNet).
• You want shared services (e.g., logging, monitoring, DNS forwarders) across VNets.

Finally you estimate cost are accurate nothing to add there..

If you found it helpful, could you kindly click the “Accept Answer and upvote” on the post

Answer 2

Hi there S79

Thanks for using QandA platform

Yes, your understanding is correct. For private access to a Blob Storage account with public access disabled, you need to create a separate Private Endpoint in each VNet (regardless of the subscription) where services like Azure Functions need access. VNet peering is not required in this case, as each Private Endpoint connects directly to the storage account over Azure’s backbone. Your cost estimate also looks accurate—around $10.80 AUD/month per endpoint plus $0.015 AUD/GB of data processed. Just make sure DNS is properly configured in each VNet so the storage account's FQDN resolves to the correct private IP. Using Azure Private DNS Zones linked to each VNet is a good approach. Also, watch out for cross-subscription permissions and ensure the right roles.

If this helps kindly accept the answer thanks much.