Scope of NSG Rules in multi-region Azure Cloud Project

Question

Scope of NSG Rules in multi-region Azure Cloud Project

Rajoli Hari Krishna 781

In our Azure Landing Zone Architecture, the organization has implemented a policy at the management group level that requires subnets to be created with a Network Security Group (NSG) in the subscription.

Referencing my previous question here:

https://learn.microsoft.com/en-us/answers/questions/2259499/confusion-in-the-subnets-creation-with-the-multi-r

We have provisioned Azure Infrastructure in the UK South region, secured within the VNet and NSG rules.

For staff in other countries, we created private endpoints using Subnet 1 in the East US VNet.

This setup results in two NSGs: one in the UK South region and another in the East US region.

As we know, private endpoints require a dedicated subnet (Subnet 1), VNet integration requires a dedicated subnet (Subnet 2), and logic apps require a dedicated outbound subnet (Subnet 3).

For all these subnets, I have defined NSG rules to ensure secure communication and the necessary ports.

Note: All VNets are internally connected using peering.

Question: Since I do not require outbound subnets in the East US VNet, are the NSG rules present in the UK South NSG also unnecessary in the East US NSG?

Accepted answer

0 additional answers

Your answer

Answer 1

Marcin Policht 45,880 MVP Moderator

The NSG rules you apply in East US should be tailored to the Private Endpoint in that region. Based on your description, it appears that you only need inbound NSG rules (if any) that allow your East US staff's traffic to reach those private endpoints from wherever they are accessing (e.g., from on-prem or other peered VNets).

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Rajoli Hari Krishna 781 Reputation points

2025-04-20T05:09:31.8+00:00

We have external APIs like graph.microsoft.com and smtp.proofpoint.com. Therefore, we have configured an outbound rule in the UK South NSG to allow traffic from the UK South outbound subnet to the internet on ports 443 and 587.

In the East US VNet, since there are no dedicated outbound subnets, these rules are not required.

When an East US user utilizes the mail server functionality (Proofpoint SMTP), the request will travel from the East US private endpoint to the UK South private endpoint. The UK South NSG rules will then manage the outbound traffic to the external API servers, ensuring the response is allowed.

Is my understanding correct?
Marcin Policht 45,880 Reputation points MVP Moderator

2025-04-20T11:19:42.1166667+00:00
Almost there...

External APIs (e.g., graph.microsoft.com, smtp.proofpoint.com)

You've allowed UK South outbound traffic to internet on ports 443 (HTTPS) and 587 (SMTP submission).

That makes sense — your apps (web apps, function apps, logic apps, etc.) in UK South need this to reach out to external services.

No outbound subnets in East US

Correct — since East US only has Private Endpoints, there's no application workload there needing to access the internet.

So you don’t need outbound rules in the East US NSG.

“When an East US user utilizes the mail server functionality (Proofpoint SMTP), the request will travel from the East US private endpoint to the UK South private endpoint.”

This sentence suggests East US users are sending requests through the private endpoint to UK South and then UK South routes it to Proofpoint. That's not exactly how it works — here's how to interpret it more accurately:

A Private Endpoint is essentially a private entry point to an Azure resource (e.g., a storage account, function app, etc.). It's not a "gateway" or "hop" through which client traffic gets routed.

So what actually happens is:

An East US user connects to an Azure resource (e.g., Function App) via its Private Endpoint, which is hosted in UK South.

That Azure resource in UK South executes code that, for example, sends an email using smtp.proofpoint.com.

So the actual outbound SMTP traffic originates from the UK South VNet, and your UK South NSG outbound rules allow this.

In other words, there is no routing of East US traffic through East US Private Endpoints to UK South — Private Endpoints are entry points, not tunnels or proxies.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

Scope of NSG Rules in multi-region Azure Cloud Project

0 additional answers

Your answer