Azure Networking

Volume 4 — Azure Foundations

Volume 2 covered TCP/IP, DNS, and VPNs in general terms. This chapter is the Azure-specific layer on top — how VNets, NSGs, and endpoint types combine to control exactly what can reach an Azure resource, and from where.

1. VNets and Subnets, in Azure Terms

A Virtual Network (VNet) is a private, isolated network within Azure — the direct Azure implementation of the private address space concept from the TCP/IP Fundamentals chapter. A VNet is divided into subnets, each a CIDR block carved out of the VNet's overall address space.

VNet: traxs-vnet (10.0.0.0/16)
├── Subnet: app-subnet    (10.0.1.0/24)  — App Service VNet integration
├── Subnet: data-subnet   (10.0.2.0/24)  — private endpoints for SQL, Storage
└── Subnet: gateway-subnet (10.0.3.0/27) — reserved for a VPN Gateway, if one exists

Resources within the same VNet (or peered VNets) can reach each other over private IPs without touching the public internet at all — this is the foundation everything else in this chapter builds on.

2. Network Security Groups (NSGs)

An NSG is a set of allow/deny rules, applied at a subnet or individual network interface, controlling inbound and outbound traffic.

Priority  Direction  Source        Destination   Port   Action
100       Inbound    10.0.1.0/24   10.0.2.0/24   1433   Allow
200       Inbound    *             *             *      Deny

Field	Meaning
Priority	Lower number evaluated first; the first matching rule wins, evaluation stops there
Direction	Inbound (traffic arriving) or Outbound (traffic leaving)
Source / Destination	IP range, or an Azure-defined tag (like Internet, VirtualNetwork)
Action	Allow or Deny

A lower-priority (numerically smaller) rule always wins over a higher-priority number if both match — this trips people up constantly, since "priority 100" sounds like it should mean less important, when it actually means evaluated first, and wins if it matches.

az network nsg rule list --nsg-name app-subnet-nsg --resource-group traxs-prod --output table

3. Service Endpoints vs. Private Endpoints

Both extend a VNet's reach to an Azure PaaS service (like Azure SQL or Storage), but work fundamentally differently — this is one of the most consequential distinctions in Azure networking to get right.

	Service Endpoint	Private Endpoint
How it works	Traffic still goes over Azure's backbone to the service's public endpoint, but the service is configured to only accept traffic that's tagged as coming from the specific VNet/subnet	The service gets an actual private IP address inside your VNet — traffic never touches a public endpoint at all
Public exposure	The resource still technically has a public endpoint; it's restricted, not removed	The resource can be configured with no public endpoint whatsoever
DNS	Resolves to the service's normal public IP	Resolves to a private IP — requires an Azure Private DNS Zone (see the DNS Deep Dive chapter) to resolve correctly from within the VNet
Cross-VNet/on-prem access via VPN	Not reachable this way — a service endpoint only recognizes traffic originating from within Azure	Reachable via VPN/ExpressRoute, since it's a genuine private IP the VPN can route to

Private Endpoint is the stronger security posture — a resource with only a private endpoint genuinely cannot be reached from the public internet under any circumstance, whereas a service endpoint-restricted resource still has a public endpoint that, while restricted, remains a slightly larger attack surface in principle. Private Endpoint is also what makes a genuine site-to-site or point-to-site VPN scenario (from the VPN Fundamentals chapter) actually work for reaching a PaaS resource — a service endpoint alone won't route external traffic through a VPN gateway at all.

4. App Service VNet Integration (Outbound)

VNet Integration lets an App Service make outbound calls into a VNet — reaching a private endpoint, an internal service, or anything else only reachable from inside the VNet.

az webapp vnet-integration add \
  --name roundtrip-api \
  --resource-group traxs-prod \
  --vnet traxs-vnet \
  --subnet app-subnet

Important distinction: VNet Integration is about outbound traffic from the App Service — it does not restrict or change how inbound traffic reaches the App Service itself. Locking down inbound access to an App Service is a separate concern (access restrictions, or Private Endpoint on the App Service's own inbound side), not something VNet Integration provides on its own.

5. A Concrete Example: Securing Azure SQL Access

Putting the pieces together — how a private, VNet-only Azure SQL setup for RoundTrip/Waypoint would actually be assembled:

1. Azure SQL Server configured with a Private Endpoint in data-subnet — no public endpoint at all.
2. An Azure Private DNS Zone linked to traxs-vnet, so roundtrip-sql.database.windows.net resolves to the private IP for anything inside the VNet, and doesn't resolve (or resolves publicly, unreachable) for anything outside it.
3. App Service configured with VNet Integration into app-subnet, giving it a path to reach the private endpoint in data-subnet.
4. An NSG on data-subnet allowing inbound 1433 only from app-subnet's address range — denying everything else by default.

The result: the database has zero public exposure, is only reachable from the specific App Service that legitimately needs it, and a developer's laptop would need a VPN connection (VPN Fundamentals chapter) specifically to reach it directly for something like ad hoc DataGrip access.

6. NAT Gateway

Covered conceptually in TCP/IP Fundamentals — in Azure specifically, resources without individual public IPs get outbound internet access either through Azure's default outbound access (not recommended for production, and being deprecated in favor of explicit configuration) or an explicit NAT Gateway resource, which gives predictable, dedicated outbound public IPs for a subnet.

az network nat gateway create \
  --resource-group traxs-prod \
  --name traxs-nat \
  --public-ip-addresses traxs-nat-ip

This matters directly for the outbound-IP-changing scenario noted in TCP/IP Fundamentals — a NAT Gateway gives a subnet a fixed, known outbound IP, which is exactly what an external firewall allow-list (like a third-party API restricting by IP) needs to stay stable across scaling events.

7. Troubleshooting Playbook

Symptom	Likely cause	What to check
Resource unreachable despite a seemingly correct NSG allow rule	A lower-priority-number rule elsewhere is denying it first	List all NSG rules by priority, not just the one you expect to apply
Private endpoint set up, but hostname still resolves to a public IP	Private DNS Zone not linked to the VNet, or the linked zone doesn't contain the expected record	dig from inside the VNet; check the Private DNS Zone's VNet links and records directly
App Service can't reach a resource in the VNet	VNet Integration not configured, or NSG on the target subnet blocking the app subnet's range	Confirm VNet Integration is actually enabled; check NSG rules on the destination subnet specifically
Works from inside Azure, not from a developer's laptop	Resource has a private endpoint only, correctly — direct laptop access requires a VPN	Confirm this is expected; set up Point-to-Site VPN if direct access is genuinely needed (see VPN Fundamentals)
Outbound IP allow-list breaks after a scaling event	No NAT Gateway — using Azure's variable default outbound IPs	Assign a NAT Gateway to the subnet for a fixed outbound IP
Service endpoint configured, but VPN-connected on-prem clients still can't reach the resource	Service endpoints don't route through VPN/ExpressRoute at all — only Private Endpoints do	Switch to a Private Endpoint if VPN-based access is required

8. Quick Reference

Category	Item	Detail
Concept	NSG priority	Lower number evaluated first, first match wins
Concept	Service Endpoint	Restricts a still-public endpoint to specific VNet traffic
Concept	Private Endpoint	Gives the resource an actual private IP, no public endpoint needed
App Service	VNet Integration	Outbound only — lets the app reach into the VNet
DNS	Private DNS Zone	Required for a private endpoint's hostname to resolve correctly inside the VNet
Outbound	NAT Gateway	Fixed, predictable outbound IP for a subnet
Command	az network nsg rule list	List NSG rules by priority
Command	az webapp vnet-integration add	Enable outbound VNet access for an App Service
Command	az network nat gateway create	Create a NAT Gateway for stable outbound IPs

---

Part of the Traxs Engineering Handbook — Volume 4: Azure Foundations. Companion chapters in this volume: Azure CLI, Azure RBAC, Azure Storage, Azure Key Vault, Microsoft Entra ID.