user-guides

AMPLS Private Endpoint in Hub vs Spoke

This document summarizes the technical evaluation of placing AMPLS Private Endpoints (PEs) in the Hub VNet versus in a Spoke VNet, based on the dual‑region (CI/SI) hub‑and‑spoke model.

Recommended architecture diagram at bottom.

---

Table of Contents

• Context
• High Level Architectures
  • (A) Hub-PE Architecture (per region)
  • (B) Spoke-PE Architecture (per region)
• Comparison Table
• DNS Considerations
  • Hub-PE DNS Considerations
  • Spoke-PE DNS Considerations
• Hub-PE Architecture – Technically Possible but Not Preferred
  • Pros – Why a Hub-PE Can Be Attractive
  • Cons – Why a Monitoring Spoke PE Is Usually Preferred
• Recommended Pattern (Microsoft-Aligned, Lower Risk)
• Accessing a Spoke-PE from Multiple Spokes
• Final Advice
• Architecture Diagram of Spoke-PE

---

Context

Per region (CI, SI):

• 1 Hub VNet
  • Azure Firewall / NVA
  • No spoke‑to‑spoke peering – all spoke↔spoke flows are forced through the Hub Firewall
• Multiple Spokes
  • Application workloads and other services
  • Custom DNS VMs (per region)
• Requirement:
  • Use Private Endpoints (PEs) for AMPLS / Log Analytics
  • Treat the PEs as shared services for multiple spokes and on‑prem

We compare two options:

1. Hub‑PE architecture – PE in the Hub VNet, LAW in a spoke.
2. Spoke‑PE architecture – PE in a dedicated monitoring spoke, LAW in the same monitoring spoke.

---

High Level Architectures

(A) Hub-PE Architecture (per region)

• Hub VNet
  • Contains:
    • Firewall & NVA
    • AMPLS PE for LAW (shared service PE)
  • All spoke traffic to LAW:
    • App Spoke → Hub Firewall → Hub PE → AMPLS → LAW in Spoke‑Monitoring.
• Monitoring / LAW Spoke
  • Contains:
    • LAW
    • Possibly DNS VMs (if DNS is centralized there).

(B) Spoke-PE Architecture (per region)

• Monitoring Spoke VNet
  • Contains:
    • LAW
    • AMPLS PE for LAW
    • DNS VMs / Azure DNS Private Resolver
  • Acts as the monitoring spoke per region.
• App Spokes
  • Peered to Hub (traffic enforced via Hub Firewall).
  • Traffic to LAW:
    • App Spoke → Hub Firewall → Monitoring Spoke PE → AMPLS → LAW.

Because all spoke↔spoke flows must traverse the Hub Firewall, both designs have the same routing pattern via the Hub. The main difference is where the PE lives (Hub vs Monitoring Spoke) and how much complexity is concentrated in the Hub.

---

Comparison Table

Aspect	Hub‑PE Architecture	Spoke‑PE Architecture (Monitoring Spoke)	Preferred
PE Location	Hub VNet (shared services zone)	Monitoring Spoke VNet (dedicated monitoring zone)	Depends
LAW Location	Monitoring Spoke VNet	Monitoring Spoke VNet	–
Routing Model	App Spoke → Hub FW → Hub PE → LAW Spoke	App Spoke → Hub FW → Monitoring Spoke PE → LAW (same VNet as PE)	–
Hub Role	Transit + Firewall + PE termination	Transit + Firewall (PE termination in spoke)	Spoke
Alignment with “spokes host workloads, hub is transit / shared infra”	Hub also terminates monitoring PEs	Closer to typical landing zone / monitoring‑spoke pattern	Spoke
PE as Shared Service	Natural – PE in Hub, shared by all spokes	Also shared – one PE in monitoring spoke, used by all spokes via Hub	Tie
Custom DNS Requirement	Yes (for private endpoint FQDN)	Yes (same reason – PE + AMPLS)	Tie
DNS Location (typical)	DNS VMs can be in monitoring spoke or dedicated DNS VNet; Hub uses custom DNS	DNS VMs in monitoring spoke or DNS VNet; Hub points to same custom DNS or Resolver	Slight Spoke
DNS Complexity	Hub depends on DNS VMs / Resolver, often in a spoke (inverted dependency)	DNS central in monitoring spoke; Hub + app spokes all use that; clear per‑region split	Spoke
Performance / Latency	App Spoke → Hub → LAW Spoke (PE in Hub, LAW in Spoke)	App Spoke → Hub → Monitoring Spoke (PE + LAW in same spoke)	Slight Spoke
Peering Bandwidth / Cost	Traffic terminates in Hub PE, then continues to LAW Spoke	Traffic terminates in Monitoring Spoke (Hub still in path due to policy)	Slight Spoke
Security Isolation	Larger blast radius – Hub PE serves all spokes	Smaller blast radius – monitoring spoke is compartmentalized	Spoke
Fault Domain Separation	Hub failure affects routing + firewall + PE	Monitoring spoke failure affects LAW/PE; Hub still handles transit	Spoke
Operational Coupling	Changes in Hub NSGs/Firewall/DNS impact monitoring flows directly	Changes in monitoring spoke affect LAW/PE; Hub changes mostly impact transit only	Spoke
Centralized Control	Strong – 1 PE per Hub/region, all traffic via Hub FW	Still centralized – typically 1 PE per monitoring spoke/region, still via Hub FW	Slight Hub
Number of PEs (per region)	1 PE per Hub	Typically 1 PE per monitoring spoke (usually 1 per region)	Tie
Scaling / Growth	Hub can become a concentration point for many shared services	Monitoring spoke scales monitoring; Hub scales transit/firewall	Spoke
Alignment with Microsoft docs	Less common example; valid with clear documentation and justification	Closer to “monitoring spoke per region” examples in CAF / landing zone guidance	Spoke
Fit to “Hub‑enforced” policy	Good – everything is already through Hub, including PE	Also good – Hub still inspects all flows; PE lives in monitoring spoke	Tie

---

DNS Considerations

Hub-PE DNS Considerations

• Private DNS zone A‑records point to Hub PE IP.
• All app spokes and Hub use custom DNS to resolve LAW workspace FQDNs.
• End‑to‑end flow (per region):
  On‑prem → regional DNS → Hub FW → Hub PE → AMPLS → LAW (Monitoring Spoke)

Pros

• Intuitive for a “shared services in Hub” mindset:
  • One visible PE per region in the Hub.
• Fits an operational model where teams look to the Hub for shared entry points.

Cons

• Hub now depends heavily on DNS (wherever DNS is hosted).
• If DNS VMs / Resolver are in a spoke, this creates an inverted dependency:
  • Hub (control plane) relies on spoke DNS.
• Hub’s role expands:
  • Transit + firewall + DNS consumer + PE host.
• Increases Hub blast radius and complexity of Hub change management.

Spoke-PE DNS Considerations

• Private DNS zone A‑records point to Monitoring Spoke PE IP.
• DNS typically sits in the Monitoring Spoke (or dedicated DNS VNet).
• End‑to‑end flow (per region):
  On‑prem → regional DNS → Hub FW → Monitoring Spoke PE → AMPLS → LAW

Pros

• Clear separation of responsibilities:
  • Hub: transit + firewall.
  • Monitoring spoke: LAW + PE + DNS + private zones.
• Regional DNS cleanly maps:
  • “Region X” → “Region X monitoring spoke PE”.
• Easier to reason about and isolate issues:
  • DNS/PE/LAW problems are localized to the monitoring spoke.

Cons

• Hub and all spokes must be able to reach DNS in the monitoring spoke (already true in your current design).
• Still requires per‑region forwarding from on‑prem, but the mapping is simpler (CI → CI monitoring spoke; SI → SI monitoring spoke).

---

Hub-PE Architecture – Technically Possible but Not Preferred

Yes, it is technically possible to place the AMPLS PE in the Hub and have all other VNets (and on‑prem) use it as a shared service.

However, operationally and architecturally it introduces several issues compared with placing the PE in a monitoring spoke.

Pros – Why a Hub-PE Can Be Attractive

1. Centralized, shared access
   • A PE in the Hub serves as a single, obvious entry point for all spokes and subscriptions.
   • Fits well with a “Hub hosts all shared services” mindset.
2. Reduced PE count
   • One PE per Hub/region instead of potentially multiple PEs if you ever introduced multiple monitoring spokes.
3. Perceived consistency
   • Hub already hosts Firewall, Gateways, NVAs; there can be an assumption that “all shared PEs live in the Hub as well”.

Cons – Why a Monitoring Spoke PE Is Usually Preferred

1. Hub may need to move to Custom DNS (if Hub components must resolve PEs)
   • If Hub resources (Firewall, gateways, management VMs) must resolve the PE FQDNs:
     • Hub VNet DNS must typically be switched from Azure‑provided to custom DNS.
   • This affects:
     • Azure Firewall (FQDN rules, outbound dependencies),
     • VPN/ER gateways,
     • Any future Hub‑hosted services relying on DNS.
   • DNS failure in the region becomes a high‑impact event for Hub and transit, not just for monitoring.
2. Weaker separation of Hub and workloads
   • Hub is intended primarily for:
     • Transit, gateways, firewalls, and shared infrastructure.
   • PEs are data‑plane endpoints for workloads/monitoring.
   • Hosting PEs in the Hub mixes control and data planes and increases the cognitive and operational load on Hub changes.
3. Private DNS zone linking and dependency chain
   • Private DNS zones must be linked so that the Hub can resolve PE names.
   • Combined with forced Hub routing, the dependency chain becomes:
     • App → Hub FW → DNS → PE → AMPLS → LAW.
   • Any problem in this chain (DNS VMs, zone links, Hub NSGs/UDRs) can break ingestion.
   • Hub becomes a single, complex failure domain for the region.
4. Limited architectural benefit specifically for AMPLS
   • AMPLS and LAW do not inherently benefit from the PE being hosted in the Hub.
   • In both designs, traffic eventually terminates at the same LAW/AMPLS resources.
   • You add Hub complexity and risk without meaningful gains for AMPLS itself.

---

Recommended Pattern (Microsoft-Aligned, Lower Risk)

Recommended:
Place AMPLS Private Endpoints in regional monitoring spokes (CI‑Monitoring, SI‑Monitoring), not in the Hubs.

Design pattern:

• Hubs (CI‑Hub, SI‑Hub)
  • Azure Firewall / NVAs
  • VPN/ExpressRoute gateways
  • DNS setting can remain Azure‑provided, or point to a central Resolver if required.
• Monitoring Spokes (CI‑Monitoring, SI‑Monitoring)
  • LAW (per region)
  • AMPLS PE(s) for LAW
  • DNS VMs / Azure DNS Private Resolver
  • Private DNS zones linked here and to any VNets that must resolve AMPLS/LAW FQDNs.
• On‑prem
  • Uses precise conditional forwarding to CI/SI DNS VMs or Resolver.
• App Spokes
  • Use the regional DNS VMs / Resolver.
  • Reach the PE in Monitoring Spoke via Hub Firewall (per your policy).

This approach preserves:

• Clean Hub boundaries (transit and security focused),
• Lower‑risk DNS architecture,
• Clear per‑region routing and DNS behavior,
• Better isolation and scaling as you add more workspaces and App Insights resources.

---

Accessing a Spoke-PE from Multiple Spokes

Even though there is no spoke‑to‑spoke peering, you can still share a single PE in the Monitoring Spoke:

• Each App Spoke is peered with the Hub.
• Monitoring Spoke is peered with the Hub.
• Hub Firewall allows traffic from App Spokes to the PE subnet in Monitoring Spoke.
• All App Spokes use the same regional DNS, which resolves the workspace FQDN to the same PE IP in the Monitoring Spoke.

Flow:

App Spoke → Hub FW → Monitoring Spoke PE → AMPLS → LAW

So:

You can keep a single PE in the Monitoring Spoke and have all present and future spokes (and subscriptions) access it via the Hub firewall. No spoke‑to‑spoke peering is required; the Hub remains the only transit point.

---

Final Advice

• Hub‑PE is technically possible and, in your forced‑hub routing design, has the same performance and cost profile as Spoke‑PE.
• The main differences are in:
  • DNS design and dependency chains,
  • Hub complexity and blast radius,
  • Alignment with standard hub‑and‑spoke and monitoring‑spoke patterns.

In most cases, placing AMPLS PEs in regional monitoring spokes provides:

• Lower operational risk,
• Simpler Hub responsibilities,
• Easier explanation to operations and auditors,
• A more future‑proof and extensible monitoring architecture.

---

Architecture Diagram of Spoke-PE

Click to view full size