Core networking infrastructure

IP addressing and subnets

Address spaces and segmentation

• A virtual network (VNet) is regional and holds one or more address spaces. Use RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or other private ranges. You can also use public ranges you own, but avoid it.
• Plan for no overlap. Peering, VPN, ExpressRoute and Virtual WAN all fail or misroute with overlapping prefixes. Plan one non-overlapping range per VNet and per on-premises site up front. Address spaces can be added later, but resizing a peered VNet needs the peering to be synced.
• Segment by role: one subnet per tier (web, app, data) or per trust zone, then use NSGs and firewalls between subnets. Subnets inside a VNet route to each other by default with no extra configuration.
• Azure supports dual-stack (IPv4 + IPv6). IPv6 subnets are /64.
• Reserved addresses: Azure reserves five addresses in every subnet (network address, default gateway, two for Azure DNS, and broadcast). A /29 is the smallest IPv4 subnet (3 usable). A /24 gives 251 usable.

Subnet requirements by service

This table is tested heavily. Know the name rule (fixed name or any name) and the minimum size.

Subnet delegation

Delegation gives a specific PaaS service permission to create its own resources and network policies in a subnet. You pick the service (for example Microsoft.Web/serverFarms for App Service VNet integration, Microsoft.Sql/managedInstances, Microsoft.ContainerInstance/containerGroups). A subnet is usually delegated to one service. A delegated subnet is not a place for other VMs.

Shared or dedicated subnets

• Dedicated is required for gateways, firewalls, Bastion, Application Gateway, Route Server and most delegated services.
• Shared is fine for VMs, private endpoints and anything that just needs a NIC. Put private endpoints in a dedicated subnet when you want to apply one NSG and UDR policy to them without affecting workloads.
• Size subnets for growth. A subnet that can’t hold the scaled-out service (for example Application Gateway at 125 instances, or Azure Firewall scaling) is a recurring scenario.

Default outbound access

Historically VMs without a public IP got implicit outbound internet access from a shared, unpredictable IP. This is being retired: new VNets created after 31 March 2026 default to “private subnets” with no default outbound access. For outbound internet you now need an explicit method: NAT Gateway (preferred), an Azure Firewall/NVA UDR, a load balancer outbound rule, or a public IP on the NIC. Don’t rely on default outbound in any design answer.

Public IP addresses and prefixes

• SKU: use Standard (static allocation, zone-redundant by default in zone regions, secure by default, so inbound is closed until an NSG allows it). The Basic public IP SKU was retired on 30 September 2025.
• Tier: Regional (default) or Global (the frontend of a cross-region Load Balancer).
• Associate a public IP with a VM NIC, load balancer frontend, VPN/ExpressRoute gateway (VPN needs a Standard IP), Azure Firewall, Application Gateway frontend, Bastion, NAT gateway, and so on. A public IP can only be attached to one resource at a time. Dissociate it first to move it.
• IPv6 public IPs are supported (Standard SKU).
• Public IP prefix: a contiguous block you reserve in a region (/28 up to /24 for IPv4, so 16 to 256 addresses). Use one when partners must allowlist a single range for your outbound or inbound addresses. Individual public IPs created from the prefix come out of that block. Prefixes work with NAT Gateway, Firewall, Load Balancer and VMs. A prefix is regional or global.
• Custom IP prefix (bring your own IP, BYOIP): you bring a range you own. Minimum /24 for IPv4 and /48 for IPv6. You prove ownership with a signed message and a ROA (route origin authorization) at the regional internet registry. The prefix then moves through provisioned (validated) and commissioned (advertised by Microsoft) stages. Use BYOIP to keep IPs your customers already allowlisted when migrating to Azure. Global custom prefixes can be advertised from multiple regions.

Name resolution

Inside a VNet

168.63.129.16 is also the source of load balancer health probes and the host’s DHCP/DNS. NSG rules and UDRs shouldn’t block it.

Public DNS zones

• Azure DNS hosts public zones on Azure’s anycast name servers (four name servers per zone, in different TLDs). You must delegate by updating the NS records at your registrar.
• Record types include A, AAAA, CNAME, MX, NS, SOA, SRV, TXT, CAA, PTR. A zone apex can’t hold a CNAME.
• Alias records point an A/AAAA/CNAME record at an Azure resource (public IP, Traffic Manager profile, Front Door endpoint, CDN endpoint). They track IP changes automatically and let you put an Azure resource at the zone apex.
• DNSSEC signing is supported for public zones.
• Azure DNS isn’t a registrar and doesn’t proxy traffic.

Private DNS zones

• A private DNS zone (for example contoso.internal) is resolvable only from VNets linked to it.
• Virtual network link: attach each VNet. A link can enable auto-registration, which creates and removes A records for VMs as they come and go. A VNet can be linked to many zones but auto-registered with only one. A zone can have many links but a limited number with auto-registration (100).
• Links work across regions, subscriptions and peered or unpeered VNets. Peering alone doesn’t share a zone, so you link each VNet (or use Private Resolver for centralized resolution).
• Records are created manually or by auto-registration. Reverse (PTR) lookups work only for auto-registered records in the linked zone.
• Split-horizon: the same name can exist as a public zone and a private zone. Linked VNets see the private answer.
• Private zones can’t be resolved from on-premises directly. You need a DNS forwarder or Private Resolver inbound endpoint.

Azure DNS Private Resolver

A managed service that removes forwarder VMs. It lives in a VNet and has:

Typical hub design: the resolver sits in the hub, the ruleset is linked to hub and spokes, spokes keep default Azure DNS, and the private DNS zones are linked to the hub VNet. A DNS security policy can filter or log queries by domain. Resolver doesn’t do recursion for the internet by itself. Azure DNS does the public lookups.

VNet connectivity and routing

Peering

• VNet peering connects two VNets over the Microsoft backbone with private IPs. Low latency, no gateway, no encryption by default (traffic stays on the backbone).
• Regional and global (cross-region) peering are both supported.
• Peering is non-transitive. If A peers with B and B peers with C, A can’t reach C unless you add a peering, a UDR through a hub NVA/firewall, or use gateway transit / Virtual WAN.
• Each direction has options: Allow access to remote VNet, Allow forwarded traffic (needed when an NVA forwards traffic that originated elsewhere), Allow gateway transit (on the hub with the gateway), Use remote gateways (on the spoke).
• The address spaces must not overlap. Peered VNets can be in different subscriptions and tenants (with permissions).

Service chaining and gateway transit

Service chaining steers spoke traffic through a hub appliance with a UDR (next hop = virtual appliance) and peering with Allow forwarded traffic.

Gateway transit lets spokes use the hub’s VPN or ExpressRoute gateway. On the hub peering, tick Allow gateway transit. On each spoke peering, tick Use remote gateways. The spoke then learns on-premises routes automatically. A spoke can use only one remote gateway, and can’t use remote gateways if it has its own gateway. If you add an on-premises prefix later, re-sync peerings. Gateway transit doesn’t make spokes reach each other. Add a firewall + UDR (or Virtual WAN, or AVNM connectivity with direct connectivity) for spoke-to-spoke.

Azure Virtual Network Manager (AVNM)

AVNM manages many VNets centrally, at management group or subscription scope.

Pick AVNM when “dozens or hundreds of VNets”, “enforce a rule no NSG owner can override” or “avoid creating peerings one by one”. Using AVNM, peering for hub-and-spoke is created and removed for you. AVNM doesn’t replace Azure Policy for governance or Azure Firewall for inspection.

System routes and UDRs

Every subnet has system routes: the VNet’s own prefixes (next hop Virtual network), 0.0.0.0/0 to Internet, RFC 1918 ranges not in the VNet to None, and routes added by peering, service endpoints and gateways. BGP-learned routes come from VPN and ExpressRoute gateways.

Route selection: longest prefix match first. For equal prefixes the priority is UDR > BGP > system.

User-defined routes (UDRs) live in a route table that you associate with a subnet (not with a NIC or VNet). One route table can serve many subnets in the same region and subscription. Each route has a prefix and a next hop type:

The route table has Propagate gateway routes (default yes). Turn it off to stop BGP routes from the gateway being added to the subnet, which is useful when you want a default route to a firewall with no override from on-premises BGP.

Forced tunneling

Forced tunneling sends all internet-bound traffic (0.0.0.0/0) to on-premises for inspection instead of straight to the internet.

• With VPN Gateway: on-premises advertises 0.0.0.0/0 over BGP, or you set a UDR with next hop Virtual network gateway for 0.0.0.0/0. Needs a route-based VPN. Don’t apply this to the GatewaySubnet.
• With Azure Firewall: the firewall needs an AzureFirewallManagementSubnet and management public IP so its own platform traffic still reaches Azure. Firewall subnet’s default route goes to the on-premises/NVA.
• Trap: a 0.0.0.0/0 UDR to a firewall breaks the firewall’s own return path if the firewall subnet also has the same UDR pointing at itself. The firewall subnet needs a route to the internet (or the management subnet in forced tunneling).

Diagnosing routing problems

Use Network Watcher:

• Next hop: which hop a VM’s packet to a given destination takes, and which route table it came from.
• Effective routes on a NIC (VM > Networking > Effective routes) show the merged system, UDR and BGP routes and which are active.
• Connection troubleshoot tests reachability and shows the hop path.
• IP flow verify tells you if an NSG allows or blocks a flow.
• Common causes: missing UDR on the return path (asymmetric routing through a firewall), IP forwarding disabled on the NVA NIC, NVA OS forwarding off, peering missing “allow forwarded traffic”, overlapping prefixes, a BGP route overriding the system route.

Azure Route Server

Route Server lets NVAs and Azure exchange routes by BGP, so you don’t maintain UDRs by hand.

• Deploy in a dedicated RouteServerSubnet (/27 or larger) with a Standard public IP. It’s a managed pair of instances, ASN 65515.
• The NVA (SD-WAN, firewall) peers with both Route Server IPs. The NVA’s ASN can’t be 65515-65520 or 8074, 8075, 12076 (reserved).
• Route Server injects the NVA’s routes into the VNet’s route tables (and peered VNets that use the hub as a gateway) and learns the VNet routes for the NVA. It doesn’t forward data traffic. Traffic goes direct to the NVA.
• Branch-to-branch enabled lets Route Server advertise routes between an ExpressRoute gateway and a VPN gateway (or an NVA) so on-premises sites reach each other through Azure when both gateways are in the VNet.
• Use it for: SD-WAN/NVA integration, dynamic failover between NVAs, ER + VPN coexistence with transit.
• It doesn’t replace Virtual WAN. In Virtual WAN, the hub router does this job itself.

NAT Gateway

Azure NAT Gateway gives a subnet a fixed outbound identity: SNAT for all outbound flows from the subnet.

• Use it for: outbound to the internet at scale, a predictable IP set (with public IPs or a public IP prefix), avoiding SNAT port exhaustion from load balancer default outbound, and the replacement for default outbound access.
• Outbound only. It doesn’t allow inbound connections. Return traffic to flows the VM started works.
• Standard SKU (zonal, or “no zone” regional) and the newer StandardV2 (zone-redundant, IPv6 supported). Up to 16 public IP addresses (or prefixes) per gateway, each providing 64,512 SNAT ports. Idle timeout default 4 minutes (up to 120).
• It takes precedence over a load balancer’s outbound rules, over a public IP on the NIC for outbound, and over default outbound access.
• Attach it to one or more subnets (not GatewaySubnet). A subnet has at most one NAT gateway. A VNet can have several.
• With Azure Firewall: put a NAT gateway on the AzureFirewallSubnet to add SNAT ports for the firewall.

Monitoring networks

Network Watcher

Enabled automatically per region (resource group NetworkWatcherRG) when you create a VNet. Tools:

Flow logs: Virtual network flow logs replace NSG flow logs. Creation of new NSG flow logs ended on 30 June 2025, and NSG flow logs retire on 30 September 2027. VNet flow logs record traffic whether or not an NSG is involved, include traffic evaluated by Virtual Network Manager security admin rules, and show encryption status of flows. Logs are JSON in a storage account. Traffic Analytics (Log Analytics) summarizes them into top talkers, malicious flows and geography.

Azure Monitor for networks

Azure Monitor Network insights gives a topology view and health metrics for load balancers, gateways, ExpressRoute, Application Gateway, Front Door, Firewall and so on. Combine with metrics, diagnostic settings (send resource logs to Log Analytics, storage or Event Hubs), alerts and workbooks. Connection monitor and flow logs feed Log Analytics for KQL queries.

DDoS protection

Enable protection by linking the VNet to a DDoS protection plan (Network) or enabling it on the public IP (IP Protection). Monitor with metrics such as Under DDoS attack or not, Inbound packets dropped DDoS, and diagnostic logs (DDoSProtectionNotifications, DDoSMitigationFlowLogs, DDoSMitigationReports). Set alerts on Under DDoS attack. Protection covers L3/L4. For L7 add WAF.

Microsoft Defender for Cloud

• Secure Score is a percentage from the recommendations you’ve fixed. Network recommendations include restricting management ports, enabling NSGs on subnets, enabling DDoS protection, applying Azure Firewall and WAF, and removing public IPs.
• Attack path analysis (Defender CSPM plan) shows chains of risk, such as an internet-exposed VM with a high-privilege identity and reachable sensitive data. It prioritizes by exploitability.
• Cloud security explorer lets you query the security graph, for example “VMs exposed to the internet with a vulnerability”, to identify network resources by relationship.
• Network security recommendations come mostly from the Defender CSPM and Defender for Servers plans. Attack path and the explorer need Defender CSPM.