Implement and manage virtual networking

Virtual networks and subnets

• A virtual network (VNet) is a private network in one Region and one subscription. Define one or more address spaces (CIDR, such as 10.0.0.0/16) and divide into subnets.
• Azure reserves 5 addresses in each subnet: network address, default gateway (.1), two for Azure DNS (.2, .3) and broadcast (last). A /29 is the smallest subnet (3 usable) and a /2 the largest allowed; in practice /16 down to /29 are normal.
• Subnets can’t overlap, and a VNet address space can’t overlap with another VNet you want to peer or an on-premises network you want to connect.
• By default all subnets in a VNet can talk to each other, and outbound internet access is allowed (default outbound access is being retired for new subnets; use a NAT gateway or explicit public IP).
• Special subnets: GatewaySubnet (VPN/ExpressRoute gateway, /27 or larger recommended), AzureBastionSubnet (/26 or larger), AzureFirewallSubnet (/26), AzureFirewallManagementSubnet, and RouteServerSubnet. These names are exact.
• Resources need delegated subnets for some services (App Service VNet integration, SQL MI, ACI).
• Change an address space later by adding a range (not allowed to break a peering in a way that breaks overlap; the peering must be synced after address space changes).
• DNS: default is Azure-provided DNS (168.63.129.16). You can set custom DNS servers at VNet or NIC level. VMs need a restart or DHCP renew to pick up changes.

az network vnet create -g rg-net -n vnet1 --address-prefixes 10.0.0.0/16 --subnet-name snet-web --subnet-prefixes 10.0.1.0/24
az network vnet subnet create -g rg-net --vnet-name vnet1 -n snet-db --address-prefixes 10.0.2.0/24

$v = New-AzVirtualNetwork -Name vnet1 -ResourceGroupName rg-net -Location westeurope -AddressPrefix 10.0.0.0/16
Add-AzVirtualNetworkSubnetConfig -Name snet-web -VirtualNetwork $v -AddressPrefix 10.0.1.0/24 | Set-AzVirtualNetwork

Virtual network peering

• Peering connects two VNets over the Microsoft backbone with low latency and private IPs. It’s non-transitive and must be created in both directions (the portal can create both).
• Regional peering (same Region) and global peering (different Regions) both work. VNets can be in different subscriptions or tenants (with permission, such as Network Contributor).
• Address spaces can’t overlap.
• Peering is not transitive: A-B and B-C doesn’t give A-C. Options: peer A-C directly, hub-and-spoke with a firewall or NVA in the hub plus UDRs, gateway transit, or Azure Virtual WAN.
• Per-peering options: Allow virtual network access, Allow forwarded traffic (traffic not originating in the peer, needed for an NVA hub), Allow gateway transit (on the hub with the gateway) and Use remote gateways (on the spoke). A spoke can use only one gateway.
• Status: Initiated (one side), Connected (both). If you change an address space, sync the peering.
• Peering doesn’t carry name resolution between VNets by itself; use Private DNS zone links.

az network vnet peering create -g rg-net -n hub-to-spoke --vnet-name hub --remote-vnet spoke --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit

Public IP addresses

• SKU: Standard (static only, zone-redundant or zonal, secure by default: closed to inbound until an NSG allows it). The Basic SKU public IP and Basic load balancer are retired (September 2025), so Standard is the answer.
• Assignment: Static or Dynamic (dynamic was Basic only; Standard is always static). Reserved addresses survive deallocation.
• IPv4 and IPv6, DNS name label (name.region.cloudapp.azure.com) and public IP prefix (a contiguous block).
• Can attach to NIC, load balancer frontend, NAT gateway, Application Gateway, VPN gateway, Bastion, Firewall.
• A Standard public IP and a Standard load balancer require matching SKUs. You can’t mix Basic and Standard on one VM’s load balancing.

az network public-ip create -g rg-net -n pip1 --sku Standard --allocation-method Static --zone 1 2 3

User-defined routes (UDR)

• Azure creates system routes: VNet local, internet (0.0.0.0/0), and others on peering, gateways and endpoints. Override or add with a route table associated with subnets (not VNets or NICs).
• A route has an address prefix and a next hop type: Virtual appliance (an NVA or firewall IP), Virtual network gateway, Virtual network, Internet, None (drops traffic).
• Route selection: longest prefix match wins; for equal prefixes: user-defined > BGP > system.
• A common pattern: route 0.0.0.0/0 to a firewall (forced tunnelling). On the NVA, enable IP forwarding on the NIC and in the OS, and on peering allow forwarded traffic.
• A route table can be associated to many subnets, but each subnet has only one. Disable BGP route propagation stops learned routes from on-premises being added.
• Check what’s applied with Effective routes on a NIC (VM must be running).

az network route-table create -g rg-net -n rt1
az network route-table route create -g rg-net --route-table-name rt1 -n to-fw --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.100.4
az network vnet subnet update -g rg-net --vnet-name vnet1 -n snet-web --route-table rt1

Network security groups and application security groups

NSG rules

• An NSG filters traffic with ordered rules. It’s stateful (return traffic is automatic).
• Rule properties: priority (100-4096), name, source, source port, destination, destination port, protocol (TCP, UDP, ICMP, Any), direction, action (Allow or Deny). Lowest number is evaluated first, and processing stops at the first match.
• Default rules (can’t be deleted, only overridden by lower numbers):

• Source/destination can be an IP, CIDR, service tag (Internet, VirtualNetwork, AzureLoadBalancer, Storage.WestEurope, Sql), or an application security group (ASG).
• Association: to a subnet and/or a NIC. If both: inbound traffic is checked by the subnet NSG first, then the NIC NSG; outbound is NIC first, then subnet. Both must allow it.
• Evaluating effective security rules: the NIC’s Effective security rules blade merges all NSGs; Network Watcher IP flow verify tests a specific five-tuple and names the rule that allows or denies.
• Traps: RDP/SSH rule at a higher number than a deny loses. ICMP (ping) is blocked by DenyAllInBound between subnets only if a deny exists; within a VNet AllowVNetInBound allows it. Azure load balancer probes come from 168.63.129.16, covered by the AzureLoadBalancer tag, so don’t deny it. An inbound Allow isn’t enough to reach a Standard public IP unless an NSG allows it.
• Augmented rules allow multiple IPs, ports and tags in one rule.

Application security groups

• An ASG is a named group of NICs. Use it as source or destination so rules follow workloads rather than IPs (for example web tier to app tier on 8080). All NICs in an ASG must be in the same VNet, and a rule that references ASGs needs them in the same VNet.

az network nsg create -g rg-net -n nsg-web
az network nsg rule create -g rg-net --nsg-name nsg-web -n allow-https --priority 100 --access Allow --protocol Tcp --direction Inbound --destination-port-ranges 443 --source-address-prefixes Internet
az network asg create -g rg-net -n asg-web
az network nic ip-config update -g rg-net --nic-name nic1 -n ipconfig1 --application-security-groups asg-web

Azure Bastion

• Managed RDP/SSH over TLS (443) to VMs through the portal or native client, without public IPs on the VMs and without exposing 3389/22.
• Deploy into a subnet named exactly AzureBastionSubnet (/26 or larger) with a Standard SKU public IP on the Bastion. SKUs: Developer (free, shared, one VM at a time), Basic, Standard (scalable instances, native client, file transfer, IP-based connection) and Premium (session recording, private-only).
• Works with peered VNets (Standard) so one Bastion can serve a hub-and-spoke. The VM NSG must allow RDP/SSH from the Bastion subnet (NSG on AzureBastionSubnet needs specific rules).
• Better than JIT access or public IPs for admin access; alternatives: Just-in-time VM access (Defender for Cloud).

az network bastion create -g rg-net -n bastion1 --vnet-name vnet1 --public-ip-address pip-bastion --sku Standard

Service endpoints and private endpoints

• Service endpoints: enable on a subnet (Microsoft.Storage, Microsoft.Sql, Microsoft.KeyVault…), then add that subnet to the PaaS service’s firewall. Traffic stays on the Azure backbone.
• Private endpoints: create a NIC with a private IP linked to the resource, approve the connection (auto if same owner), integrate with a private DNS zone linked to the VNet so FQDN acct.blob.core.windows.net resolves to the private IP via a CNAME to privatelink. For on-premises, forward DNS through Azure DNS Private Resolver or a forwarder. NSG rules on private endpoints are supported through a subnet setting (network policies).
• Pick: need on-premises access or isolation of a single resource -> private endpoint; need a quick free restriction to subnets -> service endpoint.

az network vnet subnet update -g rg-net --vnet-name vnet1 -n snet-web --service-endpoints Microsoft.Storage
az network private-endpoint create -g rg-net -n pe-st --vnet-name vnet1 --subnet snet-pe \
  --private-connection-resource-id <storage-id> --group-id blob --connection-name conn1
az network private-dns zone create -g rg-net -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g rg-net -z privatelink.blob.core.windows.net -n link1 -v vnet1 -e false

Azure DNS

• Azure DNS hosts DNS zones on Azure’s global anycast name servers. It does not register domains; buy the domain elsewhere, then delegate by setting the registrar’s NS records to the four Azure name servers listed on your zone.
• Public zone: internet-resolvable. Record types: A, AAAA, CNAME, MX, NS, SOA, SRV, TXT, CAA, PTR. The zone apex can’t hold a CNAME; use an alias record (A or AAAA alias) pointing to a public IP, Traffic Manager profile, Front Door or CDN endpoint. Alias records update automatically when the IP changes.
• Private zone: name resolution inside VNets, for example corp.internal. Link a VNet as a registration link (VMs auto-register A records; a zone allows up to 100 registration links and a VNet can have a registration link to only one zone) or resolution link (resolve only; up to 1,000). Not resolvable from the internet. Works across peered VNets only if you link each VNet.
• TTL (default 3,600 seconds) controls caching. Record sets are the unit of management (a name plus type with several values). Azure DNS supports DNSSEC for public zones.
• Azure DNS Private Resolver provides inbound and outbound endpoints and forwarding rules for hybrid name resolution (replaces forwarder VMs).
• RBAC: DNS Zone Contributor, Private DNS Zone Contributor. A resource lock protects zones and record sets from deletion.

az network dns zone create -g rg-dns -n contoso.com
az network dns record-set a add-record -g rg-dns -z contoso.com -n www -a 203.0.113.10
az network private-dns zone create -g rg-dns -n corp.internal
az network private-dns link vnet create -g rg-dns -z corp.internal -n link1 -v vnet1 -e true

Load balancing

Azure Load Balancer

• Layer 4 (TCP/UDP), very high throughput, low latency. The Standard SKU is the current choice (Basic retired September 2025). It’s zone-redundant by default with a Standard public IP, is secure by default (needs NSG allow), has a 99.99% SLA and supports cross-region (global tier) and Gateway variants.
• Public load balancer: frontend is a public IP (internet inbound and outbound). Internal load balancer: frontend is a private IP in a subnet (tiers inside a VNet).
• Components:
  • Frontend IP configuration
  • Backend pool (VM NICs, VMSS, IPs)
  • Health probe (TCP, HTTP or HTTPS; interval default 5 seconds, unhealthy threshold of 2 failures) decides which instances receive traffic
  • Load-balancing rule (frontend IP:port to backend pool:port; HA ports rule balances all ports for internal NVA scenarios)
  • Inbound NAT rule (map frontend port to one VM port for RDP/SSH)
  • Outbound rules (SNAT for backend VMs; or use a NAT gateway which is preferred)
• Distribution mode: 5-tuple hash default (source IP/port, destination IP/port, protocol). Session persistence (source IP affinity): 2-tuple or 3-tuple, so one client sticks to a VM. Floating IP (direct server return) for SQL Always On listeners.
• Backend VMs must be in the same VNet (public LB) and should be in the same availability set, scale set or zones.

az network lb create -g rg-lb -n lb1 --sku Standard --frontend-ip-name fe1 --public-ip-address pip-lb --backend-pool-name be1
az network lb probe create -g rg-lb --lb-name lb1 -n hp1 --protocol tcp --port 80
az network lb rule create -g rg-lb --lb-name lb1 -n r80 --protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name fe1 --backend-pool-name be1 --probe-name hp1

Choosing the load-balancing service

• “Route by URL path”, “WAF”, “TLS termination” -> Application Gateway. “Any TCP port, VMs behind one IP” -> Load Balancer. “Fail over between regions via DNS” -> Traffic Manager. “Global web app acceleration” -> Front Door.

Troubleshooting load balancing

• Backend marked unhealthy: probe port isn’t listening, host firewall blocks 168.63.129.16, or an NSG denies the AzureLoadBalancer tag. Check Insights/Metrics (Health Probe Status, Data Path Availability).
• Can’t reach the frontend: no matching rule, Standard LB with no NSG allow, backend not in pool, or the VM’s guest firewall blocks.
• Internal LB hairpin: a backend VM can’t reach the load balancer’s own frontend and be sent back to itself; use a different client.
• Outbound failing: SNAT port exhaustion; add outbound rules, more frontend IPs or a NAT gateway.
• Mixing SKUs, VMs in the pool without a Standard public IP, or wrong probe protocol (HTTP probe needs a 200 response).

Troubleshooting connectivity

• Start with Network Watcher: IP flow verify (which NSG rule), Next hop (which route), Effective security rules and Effective routes, Connection troubleshoot (end-to-end test with hop view), Packet capture, VPN diagnostics, Topology.
• Checklist: Is the VM running and the app listening? Guest firewall? NSG at NIC and subnet (both directions)? Route table sending traffic somewhere else (for example an NVA without IP forwarding)? Peering connected both ways and forwarded traffic allowed? DNS resolving to the right address? Overlapping address ranges? A lock or Policy blocking an operation?