Hub-and-Spoke Atlas Networking
Parent: MongoDB Atlas on Azure · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-fb5f4021932f
↓ Facts as markdownall context files
Source-anchored research for Hub-and-Spoke Atlas Networking. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- For classic hub-and-spoke networks, Microsoft recommends hub placement when several applications or on-premises clients share private endpoints; an endpoint used by one application can live in its spoke. Apply this general placement guidance to Atlas as an architectural inference. (medium confidence) [source]
- For centralized inspection, Microsoft recommends a dedicated hub endpoint subnet with explicit NVA routing and SNAT configuration. Endpoint /32 routes propagate across configured peering, so check effective routes when validating the intended inspection path. (low confidence) [source]
- OneUptime's March 31, 2026 comparison table labels private-endpoint transitive routing unsupported. MongoDB explicitly documents access from peered Azure VNets and ExpressRoute-connected networks, so that table should not rule out a shared Atlas endpoint topology. (high confidence) [source]
Problems, failure modes and limitations
- Atlas implements Azure Private Link with a private endpoint in the customer network and a load-balanced service in the Atlas VNet. Connections originate from the customer side; Atlas cannot initiate connections back through that endpoint. (high confidence) [source]
Comparisons and alternatives
- Atlas Private Link connections are one-way: Atlas cannot initiate connections back into customer VNets. This narrows the network trust boundary compared with VNet peering. (high confidence) [source]
- Ordinary Azure VNet peering is nontransitive. Peering an application spoke to a hub and the hub to an Atlas VNet does not alone provide an application-to-Atlas path; additional routing or direct connectivity is required. This limitation differs from accessing an endpoint located inside the directly peered hub. (high confidence) [source]
Facts and statements
- Azure Private Link lets an application in a VNet peered to the endpoint's VNet reach Atlas through that private endpoint. In a traditional hub-and-spoke design, placing the endpoint in the hub therefore allows directly peered spokes to share Atlas access; this placement is an architectural inference from the documented reachability. (high confidence) [source]
- An on-premises data center connected by ExpressRoute to the private-endpoint VNet can reach Atlas through the endpoint without adding public IP addresses to the Atlas IP access list. (high confidence) [source]
- Azure Virtual WAN does not allow private endpoints inside its virtual or secured hub; deploy them in connected spoke VNets. (low confidence) (verified as of 2025-07-23) [source]
- For Atlas VNet peering on Azure, use the Private IP for Peering connection string, allow the peer CIDR in Atlas, and configure cloud-side routing. The standard Azure connection string must not be assumed to select the private peering path. (low confidence) [source]
- An Atlas private endpoint in a hub VNet can serve clients in directly peered spoke VNets and an ExpressRoute-connected on-premises network. MongoDB explicitly supports these access paths; this does not make ordinary VNet peering transitive. (high confidence) [source]
- A default route of 0.0.0.0/0 to the hub firewall does not override a private endpoint route. Enable route-table network policies on the endpoint subnet and configure an eligible, sufficiently specific UDR to steer requests through inspection. (high confidence) [source]
- Endpoint-subnet NSG enforcement requires private-endpoint network policies for NSGs. Merely putting an NSG on the subnet does not establish that its rules filter private-endpoint traffic. (high confidence) [source]
- For a peering-based Atlas design, plan non-overlapping CIDRs, allow the peer CIDR in Atlas, and configure cloud-side routing. These are separate requirements from connecting application spokes to a shared private endpoint. (low confidence) [source]
- Palo Alto Networks documents Virtual WAN private-traffic routing intent for inspection of spoke-to-spoke VM flows through Cloud NGFW. Its documented absence of east-west SNAT concerns VM examples; it does not establish that an Atlas private endpoint needs no SNAT. (low confidence) [source]
- Microsoft documents /32 private-endpoint routes that propagate across configured VNet peerings. A first-hand Azure hub-and-spoke report describes a Storage private-endpoint return path bypassing the hub firewall, and commenters discuss asymmetric inspection and SNAT. Use this as general Azure troubleshooting evidence; it does not establish Atlas-specific behavior or universal cross-spoke connectivity. (low confidence) [source]
Children
- No children recorded.