CLOUD & DEVOPS / AZURE
Azure Networking Without the Mystery
A mental model for private endpoints, routing and boundaries.
Key Insight: Azure networking has a lot of individual moving pieces — VNets, subnets, NSGs, private endpoints, route tables, peering — and it becomes far less mysterious once you stop treating them as separate topics and see them as one consistent model: who can reach whom, and by what path.
Azure networking documentation tends to explain each feature in isolation, which is accurate and not especially helpful for building intuition. The mental model that actually makes it click is simpler: every networking decision in Azure answers one of two questions — what's the boundary (what can talk to what), and what's the path (how does traffic actually get there).
VNets and subnets: the boundary, not the path
A Virtual Network is an isolated network boundary — nothing outside it can reach inside by default, and nothing inside can reach the public internet or other networks except through explicit configuration. Subnets divide a VNet into smaller boundaries, useful for applying different rules to different tiers (a subnet for your application, a separate subnet for a database, a separate subnet for private endpoints). The subnet itself doesn't determine reachability on its own — that's the job of what sits at the boundary: Network Security Groups.
NSGs: the actual boundary enforcement
A Network Security Group is where "who can reach whom" actually gets enforced — inbound and outbound rules, evaluated by priority, applied at the subnet or the network interface level. The mental model worth internalizing: NSGs are stateful and default-deny for inbound traffic from outside the VNet, default-allow for traffic within the VNet unless you explicitly restrict it. That second half surprises people — by default, anything inside your VNet can talk to anything else inside it, which is often not what you want between, say, an application subnet and a database subnet, and needs an explicit NSG rule to lock down.
Private endpoints: bringing a PaaS service inside your boundary
This is the piece that trips up engineers coming from a purely on-premises networking background. By default, a PaaS service like Azure SQL or Storage has a public endpoint — it's reachable over the internet, secured by authentication and firewall rules, but still, technically, on the public internet path. A private endpoint creates a network interface for that service inside your VNet, giving it a private IP address, so traffic to it never leaves your network boundary at all. This is the difference between "authenticated over the internet" and "not reachable from the internet in the first place" — a meaningfully stronger posture, and increasingly the default expectation for anything handling sensitive data.
The practical implication: once you add a private endpoint, DNS resolution matters — you need Azure Private DNS zones configured correctly, or your application will resolve the service's public IP instead of its new private one, silently defeating the point.
Route tables and peering: the path, once the boundary is set
VNet peering connects two VNets so resources in each can reach the other directly, as if on the same network — useful for connecting a hub network (shared services like firewalls or DNS) to spoke networks (individual application environments) in a hub-and-spoke topology, which is the common enterprise pattern for a reason: it centralizes shared infrastructure and shared security controls instead of duplicating them per application.
Route tables (User Defined Routes) override Azure's default routing behavior — most commonly used to force traffic through a central firewall or network virtual appliance rather than taking the default direct path, which matters when you need centralized traffic inspection or logging.
Putting the model together
Internet → [ App Gateway / Firewall, public IP ] → VNet (boundary) → subnet: app (NSG: allow from Gateway only) → private endpoint → Azure SQL (no public exposure) → subnet: management (NSG: allow from bastion only)Every layer answers one of the two questions: the VNet and NSGs define the boundary; private endpoints pull PaaS services inside that boundary; peering and route tables define the path once the boundary is set. Reasoning about a new Azure networking requirement gets much easier once you're explicitly asking which of those two questions you're actually answering.
Key takeaways
Treat every Azure networking decision as answering either "what's the boundary" or "what's the path" — it collapses a lot of apparent complexity. Remember NSGs default-allow traffic within a VNet; lock down intra-VNet traffic explicitly where it matters, like between application and database subnets. Use private endpoints to bring PaaS services inside your network boundary, and get Private DNS configured correctly or the endpoint won't actually be used. Use hub-and-spoke peering and route tables to centralize shared infrastructure and enforce a deliberate traffic path, not the default one.