After Training 500+ People, Here's the Azure Networking Mental Model That Finally Clicks

After training 500+ cloud professionals, the pattern I keep seeing is this: people don't struggle with Azure networking because it's too complex. They struggle because they try to learn everything at once without a mental model to anchor the concepts.

They open the docs, see VNets, subnets, NSGs, route tables, peering, service endpoints, private endpoints, Azure Firewall, Application Gateway, and their brain just shuts down. Too many layers. No framework for how they connect.

I've been there. And after years of teaching this in workshops, I've found an analogy that finally makes it click.

Why Networking Confuses Everyone

Honestly, Azure networking documentation is written for people who already understand networking. That's a problem if you're coming from an IT admin background, a dev background, or you're studying for AZ-104 and networking is the section that keeps tripping you up.

The issue isn't intelligence. The issue is sequence. People try to learn the details before they understand the structure. That's like trying to memorize every room number in a building before you even know how many floors it has.

So let's fix that. Let's build the structure first.

The Building Analogy

Think of Azure networking as a physical building. Seriously. Walk through this with me.

That's the entire foundation. Five concepts. One building.

The Building in Numbers

Let's make it concrete:

The Building: VNet (10.0.0.0/16) — 65,536 addresses

Floor 3 (Web Subnet):    10.0.1.0/24 — 251 usable addresses
Floor 2 (App Subnet):    10.0.2.0/24 — 251 usable addresses
Floor 1 (DB Subnet):     10.0.3.0/24 — 251 usable addresses

Security Guard at Floor 3: NSG-Web (allow HTTP/HTTPS inbound)
Security Guard at Floor 2: NSG-App (allow traffic only from Web Subnet)
Security Guard at Floor 1: NSG-DB  (allow traffic only from App Subnet)

Elevator System: Route Tables (default system routes + custom routes)
Bridge to Another Building: VNet Peering

Why 251 and not 256? Azure reserves 5 addresses in every subnet — the network address, the gateway, two DNS-related addresses, and the broadcast address. This trips people up on the AZ-104 exam constantly.

The 3-Question Framework

In every single workshop, I teach this framework. For any resource you deploy in Azure, ask these three questions in order:

Question 1: Where is this resource?

Which VNet? Which subnet? Which region? If you can't answer this, stop. Everything else depends on placement.

# Check where a VM lives
az vm show \
  --resource-group myResourceGroup \
  --name myVM \
  --query "networkProfile.networkInterfaces[0].id" \
  --output tsv
 
# Then check the NIC to find the subnet
az network nic show \
  --ids <nic-id-from-above> \
  --query "ipConfigurations[0].subnet.id" \
  --output tsv

Question 2: Who can talk to it?

What NSG rules are in place? Is traffic allowed from the internet? From other subnets? From other VNets?

# List effective NSG rules for a VM's NIC
az network nic list-effective-nsg \
  --resource-group myResourceGroup \
  --name myVMNic \
  --output table

Question 3: How does traffic get there?

What routes exist? Are there custom routes overriding the defaults? Is traffic going through a firewall or NVA?

# Show effective routes for a NIC
az network nic show-effective-route-table \
  --resource-group myResourceGroup \
  --name myVMNic \
  --output table

If you can answer all three questions for every resource in your network, you understand the network. That's it.

Building Your First Network — CLI Walkthrough

Let's build the building from scratch. I'm using Azure CLI because that's what you'll use in real life and on the exam.

Step 1: Create the Resource Group

# Every Azure resource needs a home
az group create \
  --name rg-networking-lab \
  --location eastus

Step 2: Create the VNet (The Building)

# Create the building with address space 10.0.0.0/16
az network vnet create \
  --resource-group rg-networking-lab \
  --name vnet-main \
  --address-prefix 10.0.0.0/16 \
  --location eastus

That's it. You have a building. It has 65,536 possible addresses. Nothing lives in it yet.

Step 3: Create the Subnets (The Floors)

# Floor 3: Web tier
az network vnet subnet create \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-web \
  --address-prefix 10.0.1.0/24
 
# Floor 2: Application tier
az network vnet subnet create \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-app \
  --address-prefix 10.0.2.0/24
 
# Floor 1: Database tier
az network vnet subnet create \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-db \
  --address-prefix 10.0.3.0/24

Step 4: Create the NSGs (The Security Guards)

# Security guard for the web floor
az network nsg create \
  --resource-group rg-networking-lab \
  --name nsg-web
 
# Security guard for the app floor
az network nsg create \
  --resource-group rg-networking-lab \
  --name nsg-app
 
# Security guard for the database floor
az network nsg create \
  --resource-group rg-networking-lab \
  --name nsg-db

Every NSG comes with default rules you cannot delete:

• AllowVNetInBound (priority 65000) — allows traffic from within the VNet
• AllowAzureLoadBalancerInBound (priority 65001) — allows Azure health probes
• DenyAllInBound (priority 65500) — denies everything else

For outbound:

• AllowVNetOutBound (priority 65000) — allows traffic within the VNet
• AllowInternetOutBound (priority 65001) — allows outbound internet access
• DenyAllOutBound (priority 65500) — denies everything else

Super important: NSGs are stateful. If you allow inbound traffic on port 443, the return traffic is automatically allowed. You don't need a matching outbound rule.

Step 5: Add NSG Rules

# Allow HTTP/HTTPS into the web subnet from the internet
az network nsg rule create \
  --resource-group rg-networking-lab \
  --nsg-name nsg-web \
  --name AllowHTTP \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80 443
 
# Allow the app subnet to receive traffic ONLY from the web subnet
az network nsg rule create \
  --resource-group rg-networking-lab \
  --nsg-name nsg-app \
  --name AllowFromWeb \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.0.1.0/24 \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 8080
 
# Block everything else into the app subnet
az network nsg rule create \
  --resource-group rg-networking-lab \
  --nsg-name nsg-app \
  --name DenyAllOther \
  --priority 200 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'
 
# Allow the DB subnet to receive traffic ONLY from the app subnet
az network nsg rule create \
  --resource-group rg-networking-lab \
  --nsg-name nsg-db \
  --name AllowFromApp \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.0.2.0/24 \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 1433
 
# Block everything else into the DB subnet
az network nsg rule create \
  --resource-group rg-networking-lab \
  --nsg-name nsg-db \
  --name DenyAllOther \
  --priority 200 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

Step 6: Associate NSGs with Subnets

# Assign the security guards to their floors
az network vnet subnet update \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-web \
  --network-security-group nsg-web
 
az network vnet subnet update \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-app \
  --network-security-group nsg-app
 
az network vnet subnet update \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --name snet-db \
  --network-security-group nsg-db

Step 7: Verify the Architecture

# See the full VNet with all subnets and their NSG associations
az network vnet show \
  --resource-group rg-networking-lab \
  --name vnet-main \
  --output table
 
# List all subnets and their associated NSGs
az network vnet subnet list \
  --resource-group rg-networking-lab \
  --vnet-name vnet-main \
  --query "[].{Subnet:name, AddressPrefix:addressPrefix, NSG:networkSecurityGroup.id}" \
  --output table

You now have a three-tier network architecture. Web traffic comes in from the internet, hits the web subnet, flows to the app subnet, and then to the database. Each tier only talks to the tier directly next to it. That's the building with security guards on every floor.

The Architecture: What You Just Built

                    Internet
                       |
                       v
    +------------------------------------------+
    |          VNet: vnet-main                  |
    |          10.0.0.0/16                      |
    |                                           |
    |  +------------------------------------+   |
    |  |  [NSG-Web] --> snet-web            |   |
    |  |  10.0.1.0/24                       |   |
    |  |  Allows: HTTP/HTTPS from Internet  |   |
    |  +------------------------------------+   |
    |                  |                        |
    |                  v                        |
    |  +------------------------------------+   |
    |  |  [NSG-App] --> snet-app            |   |
    |  |  10.0.2.0/24                       |   |
    |  |  Allows: 8080 from Web Subnet only |   |
    |  +------------------------------------+   |
    |                  |                        |
    |                  v                        |
    |  +------------------------------------+   |
    |  |  [NSG-DB] --> snet-db              |   |
    |  |  10.0.3.0/24                       |   |
    |  |  Allows: 1433 from App Subnet only |   |
    |  +------------------------------------+   |
    +------------------------------------------+

The 5 Mistakes I See in Every Workshop

After hundreds of workshops, these are the mistakes that come up every single time. I've anonymized them, but I promise you — someone makes each of these in every class.

Mistake 1: Configuring NSG Rules Before Knowing the Subnet

"I added an allow rule for SSH but I still can't connect."

The fix: they deployed their VM into the wrong subnet, so the NSG rule they wrote was applied to a different subnet entirely. Always confirm where the resource is before troubleshooting security rules.

# First question: WHERE is the VM?
az vm show \
  --resource-group myRG \
  --name myVM \
  --query "networkProfile.networkInterfaces[0].id" \
  --output tsv

Mistake 2: Forgetting That NSGs Are Evaluated by Priority

"I created an allow rule but traffic is still blocked."

NSG rules are evaluated in priority order, lowest number first. If there's a deny rule at priority 100 and your allow rule is at priority 200, the deny wins. The allow rule never gets evaluated.

# List all rules in order — check for priority conflicts
az network nsg rule list \
  --resource-group myRG \
  --nsg-name myNSG \
  --output table \
  --query "sort_by([], &priority)"

Mistake 3: Not Understanding the 5 Reserved Addresses

"I created a /24 subnet and expected 256 addresses but I can only use 251."

Azure reserves 5 IP addresses in every subnet:

• .0 — Network address
• .1 — Default gateway
• .2, .3 — Azure DNS mapping
• .255 — Broadcast address

This matters when you're sizing subnets. A /28 gives you 16 addresses minus 5 = 11 usable. Plan accordingly.

Mistake 4: Overlapping Address Spaces

"I'm trying to peer two VNets but it keeps failing."

VNet peering requires non-overlapping address spaces. If VNet A is 10.0.0.0/16 and VNet B is 10.0.0.0/16, peering will fail. And peering is bidirectional — you need to create the link from both sides.

# Create peering from VNet A to VNet B
az network vnet peering create \
  --resource-group rg-a \
  --name peer-a-to-b \
  --vnet-name vnet-a \
  --remote-vnet /subscriptions/<sub-id>/resourceGroups/rg-b/providers/Microsoft.Network/virtualNetworks/vnet-b \
  --allow-vnet-access
 
# Create peering from VNet B to VNet A (both sides required)
az network vnet peering create \
  --resource-group rg-b \
  --name peer-b-to-a \
  --vnet-name vnet-b \
  --remote-vnet /subscriptions/<sub-id>/resourceGroups/rg-a/providers/Microsoft.Network/virtualNetworks/vnet-a \
  --allow-vnet-access

Mistake 5: Using Wide-Open NSG Rules and Forgetting About Them

"I opened 0.0.0.0/0 for testing and left it in production."

I've seen this one cause real incidents. During a lab or proof of concept, people allow all inbound traffic for convenience. Then they promote to production without cleaning up. That Allow * rule at priority 100 is now your biggest security hole.

# Audit: find any NSG rules that allow all inbound traffic
az network nsg rule list \
  --resource-group myRG \
  --nsg-name myNSG \
  --query "[?access=='Allow' && direction=='Inbound' && sourceAddressPrefix=='*']" \
  --output table

The fix: always use specific source IP ranges. Always. Even in dev environments.

From Mental Model to Real Architecture: Hub-and-Spoke

The building analogy scales. Once you have one building (VNet) working, production architecture is just multiple buildings connected by bridges.

That's the Hub-and-Spoke topology — the most common Azure network architecture:

                    +------------------+
                    |   Hub VNet       |
                    |   10.0.0.0/16    |
                    |                  |
                    |  Azure Firewall  |
                    |  VPN Gateway     |
                    |  Bastion Host    |
                    +--------+---------+
                       /     |     \
                      /      |      \
            Peering  /  Peering  \  Peering
                    /        |        \
    +--------------+  +--------------+  +--------------+
    | Spoke VNet 1 |  | Spoke VNet 2 |  | Spoke VNet 3 |
    | 10.1.0.0/16  |  | 10.2.0.0/16  |  | 10.3.0.0/16  |
    | (Web Apps)   |  | (APIs)       |  | (Databases)  |
    +--------------+  +--------------+  +--------------+

• The Hub is the main building with shared services — firewall, VPN gateway, bastion host
• Each Spoke is a separate building for a specific workload
• Peering connects each spoke to the hub (the bridges)
• Traffic between spokes goes through the hub's firewall (the elevator system with a security checkpoint)

This is the same mental model. Just more buildings connected by more bridges, with a central security checkpoint.

What to Learn Next

Now that you have the mental model, here's the progression path I recommend to my workshop students:

1. You are here — VNets, Subnets, NSGs, Route Tables, Peering
2. Next step — Azure Private Endpoints and Service Endpoints (how PaaS services connect to your VNet)
3. Then — Azure Firewall and Network Virtual Appliances (centralized traffic inspection)
4. Then — Azure Bastion and Just-in-Time VM access (secure remote access)
5. Then — ExpressRoute and VPN Gateway (hybrid connectivity)
6. Then — Azure Front Door and Application Gateway (L7 load balancing and WAF)

Each step builds on the mental model. Private endpoints are like a private entrance from an external service directly into your building. Azure Firewall is a security checkpoint in the lobby. ExpressRoute is a private tunnel connecting your building to your on-premises data center.

The analogy keeps working because networking itself is layered. Once you have the foundation, every new concept is just a new room in the building.

Clean Up

If you followed along with the CLI walkthrough, clean up the resources to avoid charges:

az group delete \
  --name rg-networking-lab \
  --yes \
  --no-wait

The truth is, Azure networking isn't that hard once you have the right mental model. Stop memorizing CLI flags and start understanding the structure. The building analogy has worked for 500+ people in my workshops. Build the mental model first. The commands will make sense after.