Azure Networking

Microsoft Azure's networking follows a specific philosophy: give enterprises the controls they expect, integrate deeply with Azure services, and make hybrid connectivity a first-class concern. Understanding this philosophy makes the individual components click into place.

The Foundation: Virtual Networks

Azure Virtual Networks (VNets) are your private network space in Azure. Each VNet lives in a single region—this is non-negotiable. If you need presence in multiple regions, you need multiple VNets.

When you create a VNet, you commit to an address space upfront. You're not renting addresses dynamically; you're claiming territory. A VNet with address space 10.0.0.0/16 owns those 65,536 addresses whether you use them or not.

This upfront allocation matters because Azure needs to know your address space to route traffic correctly. It's a trade-off: less flexibility, but routing decisions happen faster.

Subnets and the Five Reserved Addresses

Subnets carve your VNet into segments. But here's what catches people: Azure reserves five IP addresses in every subnet.

Not one. Not three. Five:

• The network address (.0)
• Azure's default gateway (.1)
• Two addresses for Azure DNS (.2 and .3)
• The broadcast address (.255 in a /24)

A /24 subnet with 256 addresses gives you 251 usable IPs. A /29 subnet with 8 addresses gives you only 3 usable IPs. Plan accordingly.

Unlike AWS, Azure subnets can span availability zones. You don't pick a zone when creating a subnet—the resources you deploy into that subnet choose their zones. This is a fundamentally different model that simplifies some architectures and complicates others.

Two Layers of Security: NSGs and ASGs

Azure separates network security into two concepts that work together.

Network Security Groups (NSGs) are stateful firewalls. They contain rules that allow or deny traffic based on source, destination, port, and protocol. You attach NSGs to subnets or individual network interfaces.

Rules have priorities from 100 to 4096—lower numbers win. If rule 100 allows traffic and rule 200 denies it, the traffic flows. This priority system lets you build layered policies.

Azure includes a clever concept called service tags—predefined groups representing Azure services. Instead of maintaining lists of IP addresses for Azure Storage or Azure SQL, you reference the service tag. When Azure adds new IP ranges, your rules automatically cover them.

Application Security Groups (ASGs) solve a different problem. Instead of writing rules about IP addresses, you write rules about workloads.

Create ASGs named "WebServers" and "DatabaseServers." Assign VMs to these groups. Then write an NSG rule: "Allow traffic from WebServers to DatabaseServers on port 1433." When you add a new web server, assign it to the WebServers ASG—no rule changes needed.

NSGs define what traffic is allowed. ASGs define who the participants are. They're complementary, not competing.

Load Balancing: Layer 4 vs Layer 7

Azure Load Balancer operates at Layer 4 (TCP/UDP). It distributes connections based on source IP, source port, destination IP, destination port, and protocol. It doesn't inspect HTTP headers or URL paths—it just forwards packets.

There are two SKUs. Basic is free but has no SLA and limited features. Standard costs money but provides zone redundancy and a 99.99% SLA. For production, Standard is the only real choice.

Application Gateway operates at Layer 7 (HTTP/HTTPS). It understands web traffic. It can route requests to different backends based on URL path, terminate SSL, and run a Web Application Firewall.

The decision is straightforward: if you need to make routing decisions based on HTTP content, use Application Gateway. If you just need to distribute TCP connections, Load Balancer is simpler and cheaper.

Connecting to Azure: ExpressRoute vs VPN

Both ExpressRoute and VPN Gateway connect your on-premises network to Azure. They solve the same problem differently.

VPN Gateway creates encrypted tunnels over the public Internet. Site-to-site VPN connects your entire network; point-to-site VPN connects individual laptops. It's cost-effective and works anywhere with Internet access. But your traffic competes with everyone else's, and performance varies.

ExpressRoute is a private connection through a connectivity provider. Your traffic never touches the public Internet. You get predictable latency, consistent bandwidth, and higher security. You also get a monthly bill that makes VPN look free.

ExpressRoute makes sense when you're moving serious workloads—databases with terabytes of replication traffic, real-time applications that can't tolerate jitter, or compliance requirements that prohibit Internet transit.

ExpressRoute has a superpower called Global Reach: if you have ExpressRoute circuits in two different locations, they can talk to each other through Azure's backbone. Your London office can reach your Tokyo office through Azure without going over the public Internet.

VNet Peering: Non-Transitive by Design

VNet peering connects two VNets so their resources can communicate using private IP addresses. Traffic stays on Microsoft's backbone—no Internet involved.

Here's the catch that trips people up: peering is non-transitive.

If VNet A peers with VNet B, and VNet B peers with VNet C, VNet A cannot talk to VNet C. The "friend of a friend" relationship doesn't exist. You must explicitly peer every VNet pair that needs to communicate.

This is intentional. It forces you to be explicit about network boundaries. It also means your peering topology can get complex fast. For many-to-many connectivity, look at Virtual WAN instead.

Peering requires non-overlapping address spaces. If VNet A uses 10.0.0.0/16 and VNet C also uses 10.0.0.0/16, they can never peer. Plan your address spaces before you need to connect them.

Private Connectivity to Azure Services: Service Endpoints vs Private Link

Both let you access Azure services (Storage, SQL Database, etc.) without going over the public Internet. But they work differently.

Service Endpoints add a route to your subnet. Traffic to Azure Storage takes a direct path through Azure's backbone instead of going out to the Internet and back. The storage account still has a public IP—you're just taking a faster path to it.

Private Link creates a private endpoint in your VNet with a private IP address. The storage account appears to be inside your VNet. Traffic never sees a public IP at all.

Private Link provides stronger isolation but costs more. Service Endpoints are free but provide less isolation. For most internal applications, Service Endpoints are sufficient. For sensitive workloads or regulatory requirements, Private Link is worth the cost.

Azure Firewall: Centralized Control

Azure Firewall is a managed firewall service that sits in your VNet and controls traffic flow. Unlike NSGs, which filter at the edge of subnets, Azure Firewall can be your central point of control for multiple VNets.

It supports application rules based on fully qualified domain names—you can allow traffic to *.microsoft.com without knowing every IP address Microsoft uses. It integrates with Microsoft's threat intelligence to block known malicious addresses.

Azure Firewall makes sense when you need centralized logging, consistent policies across VNets, or FQDN-based rules. If your needs are simpler, NSGs cost nothing.

Virtual WAN: Simplifying Complexity

Virtual WAN exists because enterprises got tired of managing hub-and-spoke topologies manually.

If you have 50 branch offices, each with a VPN to Azure, plus ExpressRoute circuits, plus VNets that need to talk to each other—the topology becomes a nightmare. Virtual WAN aggregates all these connections into a managed hub.

It provides transitive routing automatically. Branch A can reach Branch B through the hub. VNets connected to the hub can reach each other. You describe what should connect; Azure figures out the routing.

Virtual WAN is overkill for simple deployments. It's transformative for complex ones.

Azure Bastion: Eliminating Jump Boxes

Azure Bastion provides browser-based RDP and SSH access to VMs. You don't need public IPs on your VMs. You don't need to manage jump boxes. You connect through the Azure portal using HTML5.

The VM never exposes management ports to the Internet. Port scanners find nothing. Attackers can't target what they can't see.

Bastion deploys into a dedicated subnet (named AzureBastionSubnet, exactly). It's not free, but it's cheaper than a security incident.

Traffic Manager: DNS-Based Global Routing

Traffic Manager routes users to the best endpoint using DNS. It doesn't proxy traffic—it just returns the right IP address.

If you have deployments in East US and West Europe, Traffic Manager can send European users to West Europe (performance routing) or send everyone to East US unless it fails (priority routing). It monitors health and removes unhealthy endpoints from rotation.

Traffic Manager works at the DNS level, so it works with any endpoint that has a DNS name—Azure resources, other clouds, on-premises servers.

The Mental Model

Azure networking makes more sense when you see the patterns:

Regional isolation: VNets are regional. Cross-region requires explicit connections (peering, VPN, ExpressRoute).

Explicit relationships: Peering is non-transitive. Connections exist only where you create them.

Layered security: NSGs filter at network boundaries. ASGs group by workload. Azure Firewall centralizes control.

Private paths to services: Service Endpoints optimize the route. Private Link brings services inside your network.

Managed complexity: Virtual WAN, Azure Firewall, and Bastion exist because managing these things yourself is error-prone.

Azure didn't invent these networking concepts. But the way Azure implements them—the five reserved IPs, the non-transitive peering, the separation of NSGs and ASGs—reflects specific design decisions. Understanding why those decisions were made helps you use Azure networking effectively.