Azure networking

Question

I’m learning Azure networking and understand the basics of NSGs and route tables, but I’m unclear when custom routes are preferred over NSG rules in real deployments. Could someone explain common use cases?

Answer 1

Hello @ Ash B

Thank you for reaching out to Microsoft Q&A.

In Azure networking, NSGs and user-defined (custom) routes (UDRs) both shape your traffic—but they do very different jobs:

1. What NSGs do
   • Think of NSGs as your L3/L4 “traffic filters.”
   • They let you allow or deny traffic by source/dest IP, port, and protocol on a subnet or NIC.
   • Common use cases: • Locking down SSH/RDP to a jumpbox subnet • Blocking SQL access except from your app servers • Segmenting east-west traffic between tiers (web vs. database)
2. What custom routes do
   • UDRs let you override Azure’s built-in routing and pick a “next hop” for packets leaving a subnet.
   • You use them any time you need to steer traffic somewhere special—beyond just “allow/deny.”
   • Common scenarios: • Forcing outbound internet traffic through a network virtual appliance (NVA) firewall or proxy (forced tunneling) • Directing VNet-to-VNet or on-prem traffic through a hub NVA in a hub-spoke topology • Sending traffic for certain prefixes (e.g. 10.0.0.0/16) over your VPN or ExpressRoute gateway • Isolating test/dev VNets by dropping or blackholing specific prefixes
3. Putting it together
   • Use an NSG any time you just need to block or allow flows based on IP/port.
   • Use a UDR when you need to change the path packets take (to hit a firewall, route through on-prem, point at a NAT gateway, etc.).
   • Often you’ll combine both: UDRs force traffic to your NVAs, then NSGs on those NVAs tighten down the ports/services you actually allow.

References

• Azure Virtual Network overview, filtering & routing sections:
  https://learn.microsoft.com/azure/virtual-network/virtual-networks-overview#why-use-an-azure-virtual-network
  https://learn.microsoft.com/azure/virtual-network/virtual-networks-overview#route-network-traffic
• Network security groups: https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Custom routes (user-defined routes/UDRs) and NSGs solve different problems:

• NSGs: Allow/deny traffic based on 5‑tuple (source/destination, port, protocol, direction). They do not change where traffic goes, only whether it’s permitted.
• Custom routes: Change the path traffic takes (next hop). They do not inherently allow/deny; they steer packets to another device or service that then inspects/filters them.

Common real‑world use cases where custom routes are preferred or required over NSG rules:

1. Sending traffic through a firewall or NVA (centralized security)
   • Goal: All traffic from spoke VNets must pass through a firewall in the hub before reaching the internet or other networks.
   • How: Attach a route table to spoke subnets with a 0.0.0.0/0 route (or specific prefixes) pointing to the firewall’s private IP as next hop.
   • Why UDRs, not NSGs: NSGs can’t redirect traffic; they can only block or allow. To force inspection, traffic must be routed to the firewall. NSGs are then used on subnets/NICs or on the firewall’s subnet for additional allow/deny logic.
   • This is also a core pattern in hub‑and‑spoke and network security scenarios described for Azure Route Server, where centralized NVAs handle routing and inspection.
2. Hub‑and‑spoke and NVA‑based routing control
   • Goal: Centralize routing decisions in a hub, often with NVAs or Azure Route Server, and simplify spoke connectivity.
   • How: Use route tables on spoke subnets to send specific prefixes (other spokes, on‑premises, internet) to the hub NVA or gateway.
   • Why UDRs: Only routes can direct traffic via the hub. NSGs cannot make one spoke reach another via a specific path; they only filter after the route is chosen.
3. Hybrid connectivity and path selection (ExpressRoute/VPN/SD‑WAN)
   • Goal: Choose which on‑premises path to use (ExpressRoute vs VPN), or implement failover between them.
   • How: Use UDRs (and/or BGP via Azure Route Server) to prefer one next hop and fall back to another.
   • Why UDRs: Path selection is a routing decision. NSGs can’t say “send this prefix over ExpressRoute”; they can only allow/deny after the route is picked.
4. Forcing all outbound traffic into a virtual network for inspection
   • Example: Azure Functions or App Service with regional virtual network integration and Route All enabled.
   • Goal: Ensure all outbound traffic from the app goes into the VNet (to a firewall, gateway, or on‑premises) instead of directly to the internet.
   • How: Apply a route table to the integration subnet with 0.0.0.0/0 or specific prefixes pointing to a firewall or ExpressRoute gateway.
   • Why UDRs: Only routes can force the app’s outbound traffic into the VNet path. NSGs then control which destinations are allowed once traffic is on that path.
5. Routing to on‑premises via ExpressRoute/VPN instead of internet
   • Goal: Make certain prefixes (or all traffic) go to on‑premises networks via a gateway instead of using Azure’s default internet route.
   • How: UDRs on subnets sending those prefixes to the virtual network gateway as next hop.
   • Why UDRs: This is a pure routing decision; NSGs can’t “prefer on‑premises” vs internet.
6. Overriding system routes or fixing misroutes
   • Goal: Correct or override default/system routes that send traffic somewhere unintended (for example, accidentally sending Azure Storage or other PaaS traffic over a VPN gateway).
   • How: Add UDRs with more specific prefixes or different next hops to steer traffic correctly (for example, back to internet or to a firewall).
   • Why UDRs: When traffic is being sent to the wrong next hop, the fix is routing, not filtering. NSGs can only block the misrouted traffic; they cannot send it to the right place.
7. Controlling traffic between VNets and peered networks
   • Goal: Decide whether traffic between peered VNets goes directly, via a hub, or via an NVA.
   • How: Use UDRs on subnets to send peer prefixes to a hub NVA or gateway.
   • Why UDRs: Peering itself provides connectivity; UDRs change the path. NSGs can then restrict which flows are allowed over that path.

How NSGs and UDRs typically work together:

• UDRs decide where traffic goes (internet, NVA, gateway, on‑premises, other VNets).
• NSGs decide whether traffic is allowed once a path exists.
• Effective routes and effective NSG rules can be inspected on a NIC to verify the combined behavior.

In practice, custom routes are chosen whenever the requirement is “send this traffic via X” or “avoid path Y,” while NSGs are chosen when the requirement is “allow/deny this traffic” without changing the path.

---

References:

• Azure for network engineers
• Azure Functions networking options (flex-consumption-plan)
• Azure Functions networking options (premium-plan)
• Azure Functions networking options (dedicated-plan)
• Azure Functions networking options (container-apps)
• What is Azure Route Server?