Microsoft Azure
Intermediate 15 min read Microsoft Azure

Azure Virtual Network & Networking

Virtual networks segment and connect Azure resources. A VNet is a private address space divided into subnets; network security groups filter traffic, and the public load balancer and Application Gateway distribute inbound requests to backends. Learn to design subnets, lock down traffic with NSGs, and expose services through a load balancer.

VNetsubnetCIDRprivate IPpublic IPNSGload balancerApplication GatewayDNSnetwork security group
Prerequisites: Azure Platform Overview VMs, Scale Sets & Identity
Introduction

What is this?

Azure Virtual Network (VNet) is a logically isolated private network in Azure, defined by a CIDR address range that you split into subnets. Network security groups (NSGs) apply allow/deny rules to traffic on each NIC or subnet, and Azure DNS resolves names. The public load balancer spreads inbound traffic across VM backends in a pool, while Application Gateway does L7 routing with path-based rules and TLS termination.

Motivation

Why do you need it?

  • Subnets let you organize resources and control traffic between them without punching holes in the perimeter.
  • NSGs are the primary way to lock down Azure workloads — misconfigured NSGs are the root of most breaches.
  • A load balancer makes the backend resilient: it health-checks VMs and routes only to healthy ones.
  • Understanding CIDR and address design prevents the nightmare of running out of IP space.
  • Every cloud platform interview asks how to segment, secure and load-balance a network.
Think about it

Mental model

Imagine

A secure building with offices

Think of

Azure Virtual Network and subnets

The building is the VNet and each floor a subnet. The reception desk (load balancer) sends visitors only to floors that are staffed, and a security guard (NSG) decides who may enter each floor. Rooms on the same floor talk freely; getting to other floors requires passing a checkpoint with explicit rules. The building's mailroom (DNS) keeps the directory of who works where.

Mechanics

How it works

  • You define a VNet with a CIDR range and split it into subnets, each with its own address space.
  • NICs attached to a subnet receive private IPs from the subnet range.
  • NSGs attach to a NIC or subnet and evaluate prioritized allow/deny rules on source, destination, and port.
  • A public load balancer takes inbound traffic on its frontend IP and forwards it to a healthy backend pool of VMs.
  • Azure DNS and private DNS zones resolve names for resources, while VPN Gateway or ExpressRoute connect on-premises networks.

Segmented VNet behind a public load balancer.

Define the VNet range
Create subnets
Attach NICs
Public load balancer
NSG rules filter traffic
Healthy backend only
Reference

Key commands

az network vnet create --name app-vnet --resource-group rg-dev --address-prefix 10.0.0.0/16 --subnet-name app-subnet --subnet-prefix 10.0.1.0/24

Create a VNet with one app subnet.

az network nsg create --name app-nsg --resource-group rg-dev --location eastus

Create a network security group.

az network nsg rule create --nsg-name app-nsg --resource-group rg-dev --name AllowHTTPS --priority 100 --destination-port-ranges 443 --access Allow

Allow inbound HTTPS on the NSG.

az network vnet subnet update --name app-subnet --vnet-name app-vnet --resource-group rg-dev --network-security-group app-nsg

Bind the NSG to the app subnet.

az network lb create --name app-lb --resource-group rg-dev --backend-pool-name app-pool --public-ip-address app-lb-ip

Create a public load balancer with a backend pool.

az network lb probe create --lb-name app-lb --resource-group rg-dev --name health-probe --protocol Tcp --port 80

Add a TCP health probe to the load balancer.

Hands-on

Examples

Create a VNet, subnet, NSG and load balancer

Create a VNet, subnet, NSG and load balancer
$ az network vnet create --name app-vnet --resource-group rg-dev \
    --address-prefix 10.0.0.0/16 --subnet-name app-subnet --subnet-prefix 10.0.1.0/24
{
  "newVNet": {
    "name": "app-vnet",
    "addressSpace": { "addressPrefixes": [ "10.0.0.0/16" ] }
  }
}
 
$ az network nsg create --name app-nsg --resource-group rg-dev \
    --location eastus
{
  "NewNSG": { "name": "app-nsg" }
}
 
$ az network lb create --name app-lb --resource-group rg-dev \
    --backend-pool-name app-pool --public-ip-address app-lb-ip
{
  "loadBalancer": { "name": "app-lb" }
}

The VNet claims the 10.0.0.0/16 range and splits off a /24 subnet for the app tier. The NSG will later carry allow/deny rules for that subnet, and the load balancer exposes a public frontend IP, fronting a backend pool of VMs. Address space is created first so every resource has somewhere to live.

Real world

In production

  • Design subnets for tiers (web, app, db) so NSGs can isolate them with minimal rules.
  • Use Azure Firewall or an NSG-per-subnet strategy to enforce east-west traffic rules.
  • Put a public load balancer or Application Gateway in front of stateless web tiers so you can scale out.
  • Use Azure Private DNS zones so VMs resolve each other by name without custom hosts files.
  • Connect hybrid sites with VPN Gateway or ExpressRoute rather than exposing VMs on public IPs.
Guidelines

Best practices

  • Reserve a wide enough VNet range up front — you cannot change it after resources attach.
  • Avoid overlapping CIDR ranges if you will peer VNets or connect on-premises.
  • Prefer NSGs with explicit allow rules and deny-all-by-default, scoped to the smallest subnet.
  • Load-balance only on health-checked backends and put the probe on the application's real health endpoint.
  • Use at least two backend VMs across availability zones so a single VM or zone failure is absorbed.
Watch out

Common mistakes

  • Creating overlapping VNet ranges and then failing to peer or connect them.
  • Forgetting that NSG default rules deny all inbound by default, then debugging silent timeouts.
  • Opening ports like 22 and 3389 to 0.0.0.0/0 for convenience.
  • Putting a public load balancer in front of a single VM instead of a scale set.
  • Running the database tier in the same subnet as the web tier, so one NSG governs both.
Root cause analysis

Common issues

Error
Connection timeout when reaching a VM on port 443
Root cause

The NSG has no inbound allow rule for 443, or the rule is blocked by a deny with higher priority.

Fix

List rules with az network nsg rule list, ensure AllowHTTPS is priority 100, and confirm it is bound to the NIC or subnet.

Error
Load balancer health probe fails and backend shows 'degraded'
Root cause

The probe hits a port the application does not listen on, or the backend VM is out of the pool subnet.

Fix

Point the probe at a real health endpoint, and confirm backend VMs have the correct NIC NSG rules for the probe port.

Error
Cannot peer two VNets
Root cause

The address spaces overlap, or the peer was only created on one side.

Fix

Check CIDR overlap with az network vnet list, then create the peer on both VNets.

When things break

Debugging tips

  • Use az network nsg rule list to audit rules before assuming traffic is being dropped.
  • Test connectivity with a VM in the subnet — a timeout is usually an NSG, a reset is usually an app crash.
  • Check whether the issue is DNS, routing, or NSG by tracing with name, then private IP, then public IP.
  • Verify the load balancer probe — an unhealthy probe sends traffic to no one.
  • Use Network Watcher's IP flow verify to test a single source, port and destination against NSG rules.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Subnets, Firewall Rules and Load Balancing
25 min · intermediate
In progress
Objectives
  • Carve a virtual address space into subnets
  • Apply a firewall policy to the app subnet
  • Round-robin requests across backend nodes
  • Remove an unhealthy node from the pool and prove traffic shifts

Simulate Subnets, Firewall Rules and Load Balancing

25 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which Azure service applies allow/deny rules to traffic on a subnet or NIC?

2

By default, an NSG denies all inbound traffic unless an allow rule matches.

3

Two VNets with ranges 10.0.0.0/16 and 10.0.0.0/24 cannot be peered. Why?

Quick reference

Cheat sheet

Addressing
VNet rangeCIDR block, e.g. 10.0.0.0/16
Subnet prefixSlice of the VNet, e.g. 10.0.1.0/24
Private IPAssigned from the subnet range
Public IPRoutable from the internet
Security & L7
NSGPrioritized allow/deny on subnet or NIC
Azure FirewallCentralized L3/L7 firewall
Load balancerL4 distribution + health probes
Application GatewayL7 routing, TLS termination, WAF
Go deeper

Official documentation

What is Azure Virtual Network?
docs
Subnets and address spaces
docs
Network security groups
docs
What is Azure Load Balancer?
docs
Azure Application Gateway overview
docs
Azure DNS overview
docs