Below is a engineer-grade explanation of Private Endpoint – why it exists, how it works internally, and when it matters. I’ll treat this like a network + cloud architecture problem. lets read now
Private Endpoint — Basic Principles (Deep but Clear)
1️⃣ What problem does a Private Endpoint solve? (WHY)
The core problem
Cloud services (Storage, SQL, Event Hub, ADX, etc.) are multi-tenant and public by default.
Even when:
- authentication is strong
- TLS is enabled
- firewall rules exist
👉 Traffic still traverses the public internet fabric
This creates three real risks:
- Data exfiltration risk (public path)
- Compliance violations (data must stay inside VNet)
- Attack surface expansion (public IP exists)
The fundamental goal
Make a cloud PaaS service behave like a private server inside your VNet
That is the entire reason Private Endpoint exists.
2️⃣ What exactly is a Private Endpoint? (WHAT)
Precise definition
A Private Endpoint is:
A network interface (NIC) with a private IP address inside your VNet that maps to a specific cloud service resource.
Key points:
- It lives inside your VNet
- It uses RFC 1918 private IP
- It connects to the service via Private Link
- The service no longer needs public access
Important mental model
Think of it as:
[Your VM / Pod]
|
| 10.0.1.4 (private)
|
[Private Endpoint NIC]
|
| Azure backbone (not internet)
|
[Azure PaaS Service]
The service is still managed by Azure —
but network-wise, it is now inside your VNet.
3️⃣ Private Endpoint vs Public Endpoint (First-Principles Comparison)
| Aspect | Public Endpoint | Private Endpoint |
|---|---|---|
| IP type | Public IP | Private IP |
| Network path | Internet | Azure backbone |
| VNet required | ❌ | ✅ |
| Firewall complexity | High | Low |
| Zero Trust friendly | Weak | Strong |
| Compliance (ISO, SOC, HIPAA) | Risky | Preferred |
| DNS complexity | Low | Higher |
4️⃣ How traffic actually flows (HOW)
Step-by-step packet journey
- Client makes request
https://myaccount.blob.core.windows.net - DNS resolution (critical step)
- Public DNS ❌ → resolves to public IP
- Private DNS zone ✅ → resolves to private IP (e.g.
10.0.2.5)
- Traffic stays inside VNet
- Routed using VNet rules
- Enforced by NSG + UDR if present
- Private Link backbone
- Azure maps private IP → service internally
- No public internet hop
- Service processes request
- Authentication still applies (RBAC, SAS, tokens)
5️⃣ DNS is NOT optional — it is the heart of Private Endpoint
Why DNS matters
Private Endpoint does not change the URL
It changes what IP that URL resolves to
Correct DNS flow
App → DNS Query
|
v
Private DNS Zone
|
v
10.x.x.x (Private Endpoint IP)
Common Azure private DNS zones
| Service | Private DNS Zone |
|---|---|
| Blob Storage | privatelink.blob.core.windows.net |
| ADX | privatelink.kusto.windows.net |
| SQL | privatelink.database.windows.net |
| Event Hub | privatelink.servicebus.windows.net |
⚠️ If DNS is wrong → traffic goes public even if PE exists
6️⃣ Private Endpoint vs Service Endpoint (Very Important)
Conceptual difference
| Feature | Service Endpoint | Private Endpoint |
|---|---|---|
| IP of service | Public | Private |
| Internet exposure | Yes (restricted) | No |
| Multi-tenant isolation | Partial | Strong |
| Works across tenants | ❌ | ✅ |
| Compliance grade | Medium | High |
First-principles takeaway
- Service Endpoint = “Allow my VNet to reach public service securely”
- Private Endpoint = “Bring the service into my VNet”
7️⃣ Security model (WHO can access?)
Private Endpoint does NOT replace identity security
You still need:
- Azure RBAC
- Managed Identity
- SAS tokens / OAuth
- Application authentication
Security layers stack
[Identity] → RBAC / OAuth
[Network] → Private Endpoint
[Transport]→ TLS
[Service] → Resource firewall
This is defense in depth, not replacement.
8️⃣ Real industrial / IIoT example (WHY it matters)
Scenario: Factory → ADX ingestion
Without Private Endpoint:
- Edge gateway → public ADX endpoint
- Internet dependency
- Firewall exceptions everywhere
With Private Endpoint:
- Edge gateway → VNet → Private IP → ADX
- No internet
- Works in air-gapped or restricted environments
- Clean ISA-95 Level 3 → Level 4 boundary
This is why regulated manufacturing, energy, pharma insist on it.
9️⃣ Typical failure modes (learn from real systems)
| Mistake | Result |
|---|---|
| PE created but DNS not linked | Traffic still public |
| Public access not disabled | False sense of security |
| Using wrong subnet | Routing failure |
| Expecting NSG on PE to filter | NSG mostly ignored |
| Thinking PE = authentication | Security gap |
🔟 One-page cheat sheet
Private Endpoint = Private IP + NIC + Private Link
✔ Keeps traffic off internet
✔ Requires Private DNS
✔ Works with PaaS
✔ Strong compliance
✖ More DNS complexity
✖ Needs VNet design discipline
mental model (remember this)
Private Endpoint is not a security feature —
it is a network topology change.
Security comes after topology is correct.
Private Endpoint + NSG
Private Endpoint + NSG
Executive truth (read this first)
NSGs do NOT work on Private Endpoints the way engineers expect.
If you rely on NSGs for traffic control at a Private Endpoint, you are already exposed.
Now let’s prove why.
1️⃣ What people think happens (MYTH)
Most engineers assume:
Client → NSG → Private Endpoint → Service
Meaning:
- You attach NSG to PE subnet
- You control inbound / outbound ports
- You block unwanted sources
❌ This is wrong
2️⃣ What actually happens (REALITY)
Actual packet path
Client VM / Pod
|
| (VNet routing)
|
Private Endpoint NIC
|
| Azure Private Link (provider-managed)
|
Azure PaaS Service
Key detail (this changes everything)
Private Endpoint NIC is provider-managed
- No user-controlled NIC-level firewall
- No user-controlled inbound rules
- NSG is largely ignored
Azure bypasses NSG enforcement for PE traffic to maintain service reliability.
3️⃣ Why NSG is mostly ignored (FIRST PRINCIPLES)
Reason 1: PaaS services are multi-tenant
Azure must:
- Guarantee service availability
- Prevent tenant-induced outages
- Avoid customer NSGs breaking control plane traffic
So Azure short-circuits NSG enforcement.
Reason 2: Private Endpoint is not a VM
NSG assumes:
- Stateful connection tracking
- VM-level ingress/egress
Private Endpoint is:
- A mapped service interface
- Not a compute host
- Not a packet-terminating device
4️⃣ What NSG can do (LIMITED but real)
✅ NSG still applies on the client side
[Client Subnet NSG] → ALLOWED → Private Endpoint
So you can:
- Restrict who can initiate traffic
- Control which subnets / IPs reach PE
- Enforce east-west segmentation
❌ NSG does NOT control:
- Traffic into the Private Endpoint
- Traffic from the PaaS service
- Port-level filtering on PE
5️⃣ Microsoft’s own quiet documentation hint
Azure states (paraphrased):
“Network security groups are not supported for Private Endpoint traffic.”
This is not a bug.
This is by design.
6️⃣ So how do you actually secure Private Endpoint traffic?
The correct control layers (ordered)
1. DNS (most important)
2. VNet / Subnet segmentation
3. Client-side NSG
4. Private Endpoint approval
5. Disable public access
6. Identity-based access (RBAC)
7. Application-level auth
7️⃣ Correct security patterns (REAL solutions)
Pattern A: Subnet isolation (MOST USED)
Subnet A (Apps) → Allowed
Subnet B (Jump) → Allowed
Subnet C (Other) → Blocked
Use client subnet NSGs, not PE subnet NSGs.
Pattern B: Dedicated PE subnet (BEST PRACTICE)
- One subnet only for Private Endpoints
- No workloads inside
- No routing complexity
- Clean blast-radius control
Pattern C: Hub-Spoke with Firewall
Spoke → Hub Firewall → Private Endpoint
Firewall controls:
- Source
- Destination
- Protocol (before PE)
This is how regulated enterprises do it.
8️⃣ What happens if you try to block PE using NSG?
Result:
- Random failures
- Platform health probes blocked
- Unpredictable outages
- Microsoft support ticket → “unsupported configuration”
9️⃣ Industrial / IIoT example (REAL WORLD)
Scenario: Factory Edge → Cloud Storage
Bad design:
- NSG on PE subnet trying to allow only port 443
- Works today, fails tomorrow
Correct design:
- NSG on edge subnet
- Only allow traffic to PE private IP
- Public access disabled
- RBAC enforced
This survives audits, upgrades, and scale.
🔟 One-page cheat sheet
❌ NSG on Private Endpoint = FALSE SECURITY
✅ NSG on client subnet = REAL CONTROL
Private Endpoint security = TOPOLOGY + IDENTITY
NOT packet filtering
Final rule (remember this)
Private Endpoint is a trust boundary, not a firewall.
If you want firewall behavior:
- Use Azure Firewall
- Use NVA
- Use application-layer controls
Private Endpoint vs NAT Gateway (common confusion)
This confusion happens because both touch networking and “private”, but they solve opposite problems.
Private Endpoint vs NAT Gateway — The Core Truth
Private Endpoint = control how traffic ENTERS a service
NAT Gateway = control how traffic LEAVES your VNet
They operate in different directions, different layers, and never replace each other.
1️⃣ What problem does each solve? (WHY)
🔹 Private Endpoint
Problem:
“My PaaS service should NOT be reachable over the internet.”
Solution:
Bring the service into your VNet using a private IP.
🔹 NAT Gateway
Problem:
“My VMs / pods need outbound internet access, but I want:
- predictable IP
- scale
- no SNAT exhaustion”
Solution:
Centralized, scalable outbound-only internet egress.
2️⃣ Direction of traffic (THIS is the key confusion)
Private Endpoint → INBOUND (to service)
NAT Gateway → OUTBOUND (from VNet)
ASCII mental model
INBOUND (to Azure service)
Client ───▶ Private Endpoint ───▶ PaaS
OUTBOUND (to internet)
VM / Pod ───▶ NAT Gateway ───▶ Internet
They do not overlap.
3️⃣ What exactly is a Private Endpoint? (WHAT)
- A private IP inside your VNet
- Maps to one specific Azure service
- Uses Azure Private Link
- No public exposure required
Think:
“This storage / ADX / SQL is now inside my network.”
4️⃣ What exactly is a NAT Gateway? (WHAT)
- A managed SNAT device
- Assigned to a subnet
- Handles outbound traffic only
- Provides static public IP(s)
Think:
“Everything leaving this subnet goes out using this IP.”
5️⃣ Can NAT Gateway make a service private? ❌
No. Never.
Why?
NAT Gateway:
- Does NOT accept inbound connections
- Does NOT change service exposure
- Does NOT hide public endpoints
If a service has a public endpoint:
- NAT Gateway does nothing to protect it
6️⃣ Can Private Endpoint replace NAT Gateway? ❌
Also no.
Private Endpoint:
- Only applies to Azure PaaS
- Does NOT provide internet egress
- Does NOT provide SNAT scale
Your VMs still need:
- NAT Gateway
- or Azure Firewall
- or Load Balancer SNAT
7️⃣ Side-by-side comparison (FACT-CHECKED)
| Aspect | Private Endpoint | NAT Gateway |
|---|---|---|
| Traffic direction | Inbound to service | Outbound to internet |
| Scope | Single PaaS resource | Entire subnet |
| Public IP involved | ❌ | ✅ |
| DNS dependency | Mandatory | None |
| Replaces firewall? | ❌ | ❌ |
| Solves SNAT exhaustion | ❌ | ✅ |
| Makes service private | ✅ | ❌ |
| Works for internet access | ❌ | ✅ |
8️⃣ Common wrong assumptions (and corrections)
❌ “If I use NAT Gateway, my service is private”
✔ Correction:
Your service is still public unless Private Endpoint is used.
❌ “Private Endpoint removes need for NAT Gateway”
✔ Correction:
Private Endpoint has nothing to do with outbound traffic.
❌ “Both are security features”
✔ Correction:
- Private Endpoint = network topology
- NAT Gateway = egress scaling
Security comes from how you use them, not from their existence.
9️⃣ Correct combined architecture (REAL WORLD)
Secure enterprise pattern
Inbound (private)
On-prem / VNet ─▶ Private Endpoint ─▶ PaaS
Outbound (controlled)
VM / AKS ─▶ NAT Gateway ─▶ Internet
Add:
- Public access = disabled
- Private DNS = correct
- Client-side NSG = enforced
- Identity (RBAC) = mandatory
This passes security audits.
🔟 IIoT / Factory example (practical)
Factory Edge → Cloud
Inbound:
- Edge uploads telemetry to Storage / ADX
- Uses Private Endpoint
- No internet exposure
Outbound:
- Edge pulls OS updates, NTP, container images
- Uses NAT Gateway
- Static IP whitelisting possible
Both are needed.
1️⃣1️⃣ One-page cheat sheet
Private Endpoint:
✔ Makes Azure services private
✔ Uses private IP + DNS
✖ No internet access
NAT Gateway:
✔ Scalable outbound internet
✔ Static public IP
✖ No inbound protection
✖ Does not privatize services
mental rule (memorize this)
Private Endpoint decides WHO can reach a service.
NAT Gateway decides HOW your workloads leave the network.
Private Endpoint vs Azure Firewall
This is one of the most misunderstood topics in Azure networking, because people expect firewall behavior from something that is not a firewall.
Let’s break it down from physics-of-packets → platform design → real architectures.
Private Endpoint vs Azure Firewall — The Real Difference
Private Endpoint changes where traffic flows
Azure Firewall controls whether traffic is allowed
They solve completely different problems, at different layers, and must often be used together.
1️⃣ WHY they exist
🔹 Private Endpoint exists because:
- PaaS services are public by default
- Compliance requires no internet exposure
- Customers want VNet-only access
👉 Goal: Remove the public network path entirely.
🔹 Azure Firewall exists because:
- VNets are flat by default
- Enterprises need central policy enforcement
- Packet-level + application-level inspection is required
👉 Goal: Decide allow / deny / log traffic.
2️⃣ The most important difference (memorize this)
Private Endpoint = TOPOLOGY CHANGE
Azure Firewall = POLICY ENFORCEMENT
One moves traffic, the other judges traffic.
3️⃣ What exactly is a Private Endpoint? (WHAT)
- A private IP address inside your VNet
- Represents one specific PaaS resource
- Uses Azure Private Link
- No packet inspection
- No deny rules
- No protocol filtering
Think of it as:
“This service now lives inside my network.”
4️⃣ What exactly is Azure Firewall? (WHAT)
- A stateful, L3–L7 firewall
- Centralized
- Fully inspectable
- Logs every decision
- Controls inbound, outbound, east-west
Think of it as:
“Nothing passes unless policy allows it.”
5️⃣ Packet flow comparison (HOW traffic really moves)
Private Endpoint flow
Client → VNet routing → Private Endpoint IP → Azure backbone → Service
- No inspection
- No blocking capability
- DNS decides everything
Azure Firewall flow
Client → UDR → Azure Firewall
├─ Allow
├─ Deny
└─ Log
Firewall sees:
- Source
- Destination
- Port
- FQDN
- Application protocol
6️⃣ The BIG misunderstanding (and correction)
❌ “Private Endpoint secures my service”
✔ Reality:
Private Endpoint only hides the service from the internet.
If an attacker is already inside your VNet:
- Private Endpoint does nothing
- Firewall is required
❌ “Azure Firewall makes Private Endpoint unnecessary”
✔ Reality:
Firewall cannot remove public exposure of a PaaS service.
Even with firewall:
- Public endpoint still exists
- DNS can still resolve public IP
- Compliance still fails
7️⃣ Side-by-side comparison (fact-checked)
| Aspect | Private Endpoint | Azure Firewall |
|---|---|---|
| Layer | Network topology | Network security |
| Blocks traffic | ❌ | ✅ |
| Inspects packets | ❌ | ✅ |
| Uses private IP | ✅ | ❌ |
| Removes public endpoint | ✅ | ❌ |
| Requires DNS | Mandatory | Optional |
| Enforces policy | ❌ | ✅ |
| Logs traffic | ❌ | ✅ |
| Compliance enabler | Yes | Yes (different control) |
8️⃣ Correct way to combine them (ENTERPRISE PATTERN)
Hub-Spoke Zero-Trust Design
Spoke (Apps)
|
| UDR
v
Azure Firewall (Hub)
|
| Allowed traffic only
v
Private Endpoint (Spoke or Hub)
|
Azure PaaS Service
Why this works:
- Firewall controls who can talk
- Private Endpoint controls where traffic goes
- Public access disabled
- DNS private-only
This is audit-proof.
9️⃣ NSG vs Firewall vs Private Endpoint (clear roles)
NSG → coarse subnet filtering
Firewall → deep inspection + policy
PE → remove internet exposure
If you mix responsibilities → design failure.
🔟 Real IIoT / Manufacturing example
Factory → Cloud Analytics
Without PE:
- Firewall allows traffic
- Service still public
- Compliance violation
Without Firewall:
- PE exists
- Any compromised workload can access service
- Lateral movement risk
Correct:
- Firewall → allow only factory subnets
- Private Endpoint → no public access
- Identity → RBAC enforced
1️⃣1️⃣ One-page cheat sheet
Private Endpoint:
✔ Makes service private
✔ No packet filtering
✔ DNS-driven
Azure Firewall:
✔ Blocks / allows traffic
✔ Inspects L3–L7
✔ Logs everything
They are COMPLEMENTARY, not alternatives
Final rule
Private Endpoint answers: “Can the internet see my service?”
Azure Firewall answers: “Should this traffic be allowed?”
Private Endpoint in air-gapped / offline factories
Below is the architecture for using Private Endpoint in air-gapped / offline factories — explained the way OT + IIoT + cloud auditors actually reason about it.
Private Endpoint in Air-Gapped / Offline Factories
Executive truth (read first)
Private Endpoint does NOT require the public internet —
but it DOES require a network path to Azure.
So the right question is not:
“Can Private Endpoint work offline?”
The right question is:
“What kind of ‘offline’ are we talking about?”
Let’s classify that properly.
1️⃣ Types of “offline” factories (CRITICAL distinction)
🔹 Type A — Internet-isolated, but cloud-connected
- No public internet
- Has private connectivity:
- ExpressRoute
- Site-to-Site VPN
- Very common in regulated manufacturing
✅ Private Endpoint works perfectly
🔹 Type B — Intermittently connected
- Normally isolated
- Periodic sync windows (daily / weekly)
- Controlled data transfer
⚠️ Private Endpoint works only during connectivity windows
🔹 Type C — Physically air-gapped
- No WAN
- No VPN
- No fiber
- Data moved via USB / disk
❌ Private Endpoint is impossible
(because there is no network path)
2️⃣ First-principles requirement for Private Endpoint
Private Endpoint requires exactly three things:
1. IP connectivity to Azure backbone
2. Private DNS resolution
3. Authentication (identity)
If any one is missing → it fails.
3️⃣ Reference architecture — Type A (MOST REALISTIC)
Internet-blocked but cloud-connected factory
[PLC / SCADA]
|
[OT Network]
|
[Industrial Edge Gateway]
|
======== FACTORY DMZ ========
|
[Firewall / Router]
|
== ExpressRoute / IPSec VPN ==
|
[Azure VNet]
|
[Private Endpoint]
|
[Azure PaaS (ADX / Storage / EH)]
Key properties
- ❌ No internet
- ✅ Azure reachable privately
- ✅ DNS resolves to private IP
- ✅ Public access disabled
This passes ISO / IEC 62443 audits.
4️⃣ DNS — the silent killer in offline factories
What usually goes wrong
Factories often use:
- Local Active Directory DNS
- OT-only DNS servers
- No Azure DNS forwarding
Required DNS pattern
Factory DNS
|
| Conditional forward
v
Azure Private DNS Zone
|
v
10.x.x.x (Private Endpoint IP)
Without this:
- Name resolves to public IP
- Traffic fails or violates policy
👉 DNS is more important than firewall here
5️⃣ Data flow models for offline tolerance
Model 1 — Continuous streaming (Type A)
Edge → Private Endpoint → Cloud
- Low latency
- Real-time analytics
- Requires stable private link
Model 2 — Store & Forward (Type B)
Edge stores data locally
|
(Connectivity window opens)
|
Edge → Private Endpoint → Cloud
- Designed for intermittent connectivity
- Very common in remote plants
Model 3 — Physical transfer (Type C)
Edge → Disk → Human → Cloud
- No Private Endpoint
- Manual ingestion
- Different security model entirely
6️⃣ What Private Endpoint actually protects in factories
It protects against:
- Internet-based attacks
- Accidental public exposure
- Data exfiltration via public paths
- Cloud misconfiguration risks
It does NOT protect against:
- Compromised edge device
- Malware inside OT network
- Insider threats
- Poor identity controls
👉 Zero Trust still applies inside the factory
7️⃣ Security layers that MUST exist (non-negotiable)
Layer 1: Physical isolation (OT)
Layer 2: Firewall segmentation (OT → IT)
Layer 3: Private connectivity (VPN / ER)
Layer 4: Private Endpoint (no public PaaS)
Layer 5: Identity (certs, managed identity)
Layer 6: Application validation
Private Endpoint is Layer 4, not the whole story.
8️⃣ Common wrong assumptions (very common in OT)
❌ “Private Endpoint works without any connectivity”
✔ Reality:
No packets → no Private Endpoint.
❌ “If factory is offline, PE gives security”
✔ Reality:
Security is irrelevant if no traffic exists.
❌ “NSG on PE subnet protects factory”
✔ Reality:
NSG is mostly ignored for PE traffic.
9️⃣ Real IIoT example (manufacturing)
Beverage plant (very realistic)
- PLC → Edge Gateway (OPC UA)
- Edge buffers 7 days of data
- Daily 30-minute VPN window
- Data pushed via Private Endpoint to ADX
- Public access disabled
- Audit logs retained
This is industry-grade and auditable.
🔟 One-page cheat sheet
Private Endpoint + Air-Gapped Factory
✔ Works with VPN / ExpressRoute
✔ Requires DNS forwarding
✔ No internet needed
✖ Impossible without any network path
Offline ≠ Disconnected
Private ≠ Secure by itself
mental model
Private Endpoint secures the PATH, not the PLANT.
Factories need:
- Network discipline
- Identity discipline
- Operational discipline
Private Endpoint is only one brick.
References
1️⃣ Azure Private Endpoint — Core Principles
Official Microsoft Docs
-
What is Azure Private Endpoint
-
Azure Private Link overview
-
Private Endpoint limitations
-
Disable public network access (PaaS)
2️⃣ Private Endpoint + DNS (Critical but often missed)
-
Azure Private DNS zones for Private Endpoint
-
Private Endpoint DNS integration explained
-
On-premises DNS forwarding for Private Endpoint
These directly support:
“Private Endpoint does not change the URL — it changes DNS resolution.”
3️⃣ Private Endpoint + NSG (The Reality)
Microsoft explicitly documents this (quietly)
-
NSG limitations with Private Endpoint
Quote (paraphrased):
Network policies like NSGs are not supported for Private Endpoint traffic.
This backs:
“NSGs are mostly ignored for Private Endpoint traffic — by design.”
4️⃣ Private Endpoint vs Service Endpoint
-
Service Endpoints vs Private Endpoints
These support:
Service Endpoint = still public
Private Endpoint = private IP inside VNet
5️⃣ NAT Gateway — What it actually does
-
Azure NAT Gateway overview
-
NAT Gateway is outbound only
This supports:
NAT Gateway = outbound SNAT only
No inbound protection, no service privatization
6️⃣ Azure Firewall — Packet inspection & policy
-
Azure Firewall overview
-
Azure Firewall traffic inspection (L3–L7)
-
Hub-Spoke architecture with Azure Firewall
These support:
Firewall = policy enforcement
Private Endpoint = topology change
7️⃣ Private Endpoint + Azure Firewall together
-
Securing Private Endpoint traffic using Azure Firewall
-
Private Endpoint in hub-spoke networks
8️⃣ Air-Gapped / Offline / Factory Connectivity
Microsoft + Industry-aligned guidance
-
Private Endpoint with VPN / ExpressRoute
-
ExpressRoute private connectivity
-
Azure for industrial & OT networks
-
Store-and-forward edge patterns
These support:
Offline ≠ disconnected
Private Endpoint requires IP connectivity, not internet
9️⃣ Compliance & Zero Trust Alignment
-
Zero Trust network architecture (Microsoft)
-
IEC 62443 & network segmentation concepts
🔟 Summary (for citation sections)
If you need just one sentence with references:
Azure Private Endpoint provides private IP–based access to PaaS services using Azure Private Link and relies on DNS resolution rather than firewall inspection, while NSGs are not supported for Private Endpoint traffic, making Azure Firewall necessary for policy enforcement. NAT Gateway remains an outbound-only SNAT service and does not privatize services.
(Refs: Microsoft Private Link, Private DNS, Azure Firewall, NAT Gateway docs above)