Azure networking design is where application architecture, operations, and security meet. The notes below focus on the core building blocks: virtual networks, subnets, address planning, routing, network security groups, load balancing, and connectivity back to existing environments.
Start here: Azure Virtual Network overview
2026 context: the basics below are still useful, but a real Azure network design should also consider hub-and-spoke topology, Azure Virtual Network Manager, Private Link/private endpoints, Azure Firewall or third-party NVA placement, DNS resolution across hybrid networks, and whether outbound Internet should be centralized instead of left to default platform behavior.
Design questions to answer first
Before clicking around in the portal, write down a few things:
- What address ranges are available and guaranteed not to overlap with on-premises, partner, or future cloud networks?
- Which subnets represent trust boundaries, and which are just application tiers?
- Which services need private endpoints, service endpoints, or public access?
- Where should DNS resolution happen for Azure, on-premises, and private-link names?
- Is outbound Internet allowed directly, via NAT Gateway, through Azure Firewall, or through an NVA?
- How will flow logs, route tables, and NSG changes be monitored?
The point of the exercise is to avoid treating a VNet like a flat VLAN. Azure gives you easy defaults, but most production networks should be deliberately segmented and observable.
VNet
Primary networking technology, like the VPC in AWS.
Internet access is on by default.
Cloud services can go in to the VNET as well.
Can connect VNET’s to each other, or connect them to on premise.
Can bring own DNS, or use Azure DNS.
Subnets can communicate with each other by default. When I create subnet-a and subnet-b, then stick a vm in each, they will be able to freely communicate by default.
That default subnet-to-subnet reachability is the first thing to keep in mind for security design. A VNet is not automatically segmented just because you created multiple subnets. Use NSGs, route tables, Azure Firewall/NVAs, and application controls to define the communication you actually want.
Basics with PowerShell:
#Resource Group
$rg = "Test-NET-RG"
#Location
$location = "WestUS"
#VNET Name
$VNETName = "SL-VNET-PShell"
#Address Space
$VNETAddressSpace = "10.0.0.0/22"
#Subnets
$webSN = New-AzVirtualNetworkSubnetConfig -Name "Duff-Web" -AddressPrefix "10.0.0.0/24"
$appSN = New-AzVirtualNetworkSubnetConfig -Name "Duff-App" -AddressPrefix "10.0.1.0/24"
$dbSN = New-AzVirtualNetworkSubnetConfig -Name "Duff-Data" -AddressPrefix "10.0.2.0/24"
#Create Resource Group
New-AzResourceGroup -Name $rg -Location $location
#Go ahead and create the VNET & Subnets
$virtualNetwork = New-AzVirtualNetwork -Name $VNETName -ResourceGroupName $rg `
-Location $location -AddressPrefix $VNETAddressSpace -Subnet $webSN,$appSN
#-------------
#Add one more subnet separately
$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name "ExtraSubnet" `
-AddressPrefix "10.0.3.0/24" `
-VirtualNetwork $virtualNetwork
#Write changes
$virtualNetwork | Set-AzVirtualNetwork
Routes in VNet
Local VNET - Route for local addresses. On-Prem - Route to connect to on-prem resources where VNet Gateway will be next hop. Internet - Route for all traffic to Internet. Internet Gateway is the next hop.
Then, we add user defined routes on top.
Route tables are also where designs start to get messy. If you force tunnel outbound traffic to a firewall or on-premises network, make sure you understand the impact on platform dependencies, package updates, identity endpoints, and any PaaS service that still needs egress. A route table that looks clean in a diagram can create painful asymmetric-routing or DNS problems later.
NSGs: Network Security Groups
Traffic filtering.
Can be associated with a subnet or a network interface card (but not the virtual machine itself; just the vNIC)
The direction of the flow dictates the ordering when traversing multiple NSG’s. For example, if there is a NSG on the subnet and a NSG on the vNIC, the vNIC rules will apply first outbound - if we block 80 on the vNIC it would never hit the NSG on the subnet.
In each NSG though, lower rule numbers have priority (10 is a high priority rule, 400 is lower).
A flow record is created for existing connections. Communication is allowed or denied based on the connection state of the flow record. The flow record allows a network security group to be stateful
Existing connections might not be interrupted when you remove a security rule that enabled the flow. Traffic flows are interrupted when connections are stopped and no traffic is flowing in either direction, for at least a few minutes.
For production, I prefer subnet-level NSGs for broad tier policy and NIC-level NSGs only when there is a strong reason. Too many NIC-specific exceptions become hard to review. Also remember that NSGs are not a replacement for host firewall policy or application authorization; they are one layer of network filtering.
Practical baseline
For a small production-ish deployment, a respectable starting point would be:
- A documented address plan with room for future subnets and peering.
- Separate subnets for ingress, application, data, private endpoints, and gateway/firewall resources where needed.
- NSGs that deny lateral movement by default between tiers, then allow specific required flows.
- A clear outbound pattern: NAT Gateway, Azure Firewall, or NVA rather than accidental public egress.
- Private endpoints for sensitive PaaS services where practical, with DNS tested from every relevant subnet.
- Flow logging and diagnostic settings enabled early, before troubleshooting forces the issue.
Diagram
There’s a diagram function that makes your configuration easy to understand, and changes easier to follow. I deployed two subnets inside a /23 and a machine in each. The diagram below the output azure gives me and helps to figure out how all the pieces fit together - from vNIC to external IP and the NSG’s.
