Azure Private endpoints for Paas resources and Global Vnet peering

Question

Azure Private endpoints for Paas resources and Global Vnet peering

Nikita 20

Hi,

We have multiple Paas resources like Cosmos db in a single azure region (CUS) and App services across multiple azure regions.

We have one vnet created per region, connected to the app services in that region.

All of these app services access the Paas resources in the central region.

We are working on the network design to secure the incoming traffic to the Paas resources. What would be the ideal approach among the following and why:

Global vnet peering of all vnets with the vnet in the central region and private endpoints created in the central region vnet
Private endpoints created in each vnet without peering

Or is there another approach that is better?

We are currently leaning towards #1 since the number of private endpoints to be managed will be less. Are there disadvantages to this?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Venkatesan S 6,920 Microsoft External Staff Moderator

Hi Nikita,

Thanks for reaching out in Microsoft Q&A forum,

We are working on the network design to secure the incoming traffic to the Paas resources. What would be the ideal approach among the following and why:

Global vnet peering of all vnets with the vnet in the central region and private endpoints created in the central region vnet

Private endpoints created in each vnet without peering

Or is there another approach that is better?

For the above scenario, multiple regional App Services connecting to centralized PaaS resources in one region global VNet peering with Private Endpoints only in the central region (Option 1) is the way to go. It follows Azure’s recommended hub-and-spoke model for PaaS and drastically reduces operational overhead: one Private Endpoint per resource instead of one per region means less to deploy, fewer DNS records to manage, and simpler security policies.

There are a few caveats to accept:

Cross-region latency and cost: Traffic from regional App Services travels over VNet peering to CUS, adding roughly 10–30ms and costing about $0.01/GB in egress charges. For typical workloads this is negligible, but it adds up at very high throughput.
DNS complexity: You’ll need Private DNS Zones with conditional forwarding from each regional VNet so PaaS FQDNs resolve to the central PE’s private IP instead of public endpoints.

Option 2 (Private Endpoints in every VNet) is only worth it if you absolutely need regional isolation, can’t tolerate any extra latency, or have massive data transfer volumes that make peering costs prohibitive. For most cases, Option 1 is the simpler, more sustainable choice.

References:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Nikita 20 Reputation points

2026-04-03T06:23:41.59+00:00

Thanks for the explanation.
I have a question on this point:

Single point of failure: An outage in the central CUS VNet, its subnet, or the Private Endpoint takes down PaaS access for all regions at once. You can reduce this risk by spreading the PE across multiple subnets with Availability Zones.

When I create subnets, I don't see any availability zones to be set. They seem to inherit the zone of the vnet. Similarly, when I create private endpoints in a particular region, I am able to select only the vnets in that region.

So, does this mean that if I have two vnet regions CUS and EUS, I will need to create a PE in subnet of CUS vnet and another PE in subnet of EUS vnet? Isn't this option #2 with multiple PEs and no peering?

Sorry if I am missing something.
Venkatesan S 6,920 Reputation points Microsoft External Staff Moderator

2026-04-03T06:31:12.6466667+00:00
Hi Nikita,

You can’t spread a single Private Endpoint across multiple Availability Zones or subnets. A Private Endpoint is a regional, zonal resource that lives in one specific subnet, in one specific VNet, in one specific region. When you create a subnet, it inherits the VNet’s region, and the PE you deploy there is locked to that region.

So, here’s what’s actually possible with Option 1 (Global VNet Peering + Centralized PE):

You create one VNet in CUS (your central region).

You deploy one Private Endpoint for Cosmos DB in a subnet of that CUS VNet.

You peer all regional VNets (EUS, WUS, etc.) to this central CUS VNet using global VNet peering.

Traffic flows: App Service (EUS) > EUS VNet > (peering) > CUS VNet > Private Endpoint > Cosmos DB.

The “Availability Zone” mitigation I mentioned means deploying the CUS VNet itself as a zone-redundant VNet (available in most regions now). Cosmos DB Private Link endpoints are zone-redundant by default in zone-enabled regions, so even though the PE sits in one subnet, the underlying PaaS connectivity can failover across zones within CUS. The real single point of failure is the CUS region itself, not a specific AZ.

What you’re describing creating one PE in CUS VNet and another PE in EUS VNet with no peering is actually Option 2 (distributed PEs, no peering). You’d have two Private Endpoints for the same Cosmos DB account, each in a different region.

The real trade-off restated:

Option 1: 1 PE in CUS only + global peering. Failure domain: CUS region outage affects all regions.

Option 2: N PEs (one per region), no peering. Failure domain: Only that region is affected if its PE or region goes down.

So, your understanding is correct: there’s no middle ground of “multiple PEs in one VNet across zones.” The choice really is one PE in CUS with global peering, or multiple PEs, one per regional VNet, with no peering.

The zone-redundancy benefit of Option 1 only protects against a single AZ failure within CUS, not a full CUS region outage. If region-level resilience is critical, Option 2 (or a hybrid with PEs in 2–3 regions plus peering) is the only way to achieve it.

Sorry for the confusion your catch was spot on.

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Share via

Azure Private endpoints for Paas resources and Global Vnet peering

0 additional answers

Your answer