Overview
Azure networking is built around the Virtual Network (VNet) as the isolation boundary, with subnets dividing it into segments that Network Security Groups and route tables actually attach to. Connecting networks together, VNet to VNet, or Azure to on-premises, has two distinct mechanisms with different trade-offs: peering for fast, direct Azure-to-Azure connectivity over Microsoft's backbone, and VPN gateways for encrypted tunnels to networks outside Azure. Most real-world Azure networking mistakes come from NSG rule ordering (evaluation stops at the first match) or assuming peering transits automatically, neither of which is true.
Quick Reference
| Concept | Purpose | Key trait |
|---|---|---|
| VNet | Isolated network within a region | Defined by an address space (CIDR) |
| Subnet | Segment of a VNet's address space | Where NSGs and route tables attach |
| NSG | Stateful traffic filtering | Rules evaluated in priority order, first match wins |
| VNet peering | Direct VNet-to-VNet connectivity | Fast, no gateway, doesn't transit by default |
| VPN gateway | Encrypted tunnel to non-Azure networks | Used for on-premises or cross-cloud connectivity |
Syntax
resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
name: 'vnet-app'
location: resourceGroup().location
properties: {
addressSpace: { addressPrefixes: ['10.0.0.0/16'] }
subnets: [
{ name: 'app-subnet', properties: { addressPrefix: '10.0.1.0/24' } }
]
}
}Examples
# NSG rules are evaluated in priority order, lowest number first,
# first match wins. A broad rule placed too early can shadow a
# more specific one that comes after it.
az network nsg rule create \
--nsg-name nsg-app --resource-group rg-app \
--name allow-https --priority 100 \
--destination-port-ranges 443 --access AllowPeering does not transit by default
If VNet A peers with B, and B peers with C, A cannot reach C through B unless you explicitly enable gateway transit or set up a hub-and-spoke topology with a network virtual appliance. Peering is point-to-point, not automatically routable across hops.
Visual Diagram
Common Mistakes
- Placing a broad allow rule at a lower priority number (evaluated first) than a more specific deny rule, silently making the deny unreachable.
- Assuming VNet peering transits automatically between more than two peered networks, then being confused when a hub-and-spoke setup doesn't route as expected without additional configuration.
- Overlapping address spaces between VNets that later need to be peered, requiring a disruptive re-addressing to fix.
- Attaching NSGs only at the subnet level or only at the network-interface level inconsistently across an environment, making the effective rule set hard to reason about.
Performance
- VNet peering traffic travels over Microsoft's backbone network, typically with lower latency and higher throughput than a VPN gateway tunnel over the public internet.
- VPN gateways have their own throughput SKU tiers, undersizing one for actual cross-network traffic volume creates a real bottleneck distinct from anything happening inside Azure itself.
- NSG rule evaluation is effectively free at the packet level; the performance concern is entirely about correctness of rule ordering, not runtime cost.
Best Practices
- Design non-overlapping address spaces across all VNets from the start, anticipating future peering needs rather than retrofitting them.
- Order NSG rules deliberately from most specific to most general, and document why, since evaluation order is the actual logic.
- Use a hub-and-spoke topology with a central VNet for shared services when more than a couple of VNets need to communicate, rather than a full peering mesh.
- Reserve VPN gateways for genuinely external connectivity (on-premises, other clouds) and use peering for all Azure-to-Azure connectivity.