Design and Implement Virtual Network IP Addressing Schemes
When you create a virtual network, you must define its address space using CIDR notation, like 10.0.0.0/16. This private IP range must not overlap with any other connected network, including on-premises or other Azure networks. You then divide this space into subnets, such as 10.0.1.0/24, to segment resources. Azure reserves the first four and the last IP in each subnet, so a small subnet like /29 provides only three usable addresses. For resources that need a fixed address, like domain controllers, you assign a static private IP; otherwise, Azure uses dynamic allocation, which can change when a virtual machine stops. A dedicated GatewaySubnet is required if you plan to deploy a VPN gateway, and you should always leave room in your address space for future expansion.
Virtual Network Peering connects two Azure virtual networks, allowing resources to communicate using private IPs over Microsoft's backbone. Peering can be regional (within the same Azure region) or global (across regions). A key requirement is that the address spaces of the peered networks must not overlap. Peering is non-transitive, meaning if Network A peers with B and B peers with C, A and C are not automatically connected. By default, Azure's built-in DNS does not resolve names across peered networks. To enable name resolution, you must implement Azure Private DNS zones or configure custom DNS servers, like domain controllers, and update the virtual network's DNS settings.
Each subnet requires a unique name and an address range within its parent virtual network. You can configure a subnet to be private, blocking default outbound internet access, or associate a NAT gateway with it for outbound connectivity. Network Security Groups (NSGs) are the primary tool for filtering traffic to and from subnets or individual network interfaces. An NSG contains rules that allow or deny traffic based on source/destination IP, port, and protocol. You can apply an NSG to an entire subnet, securing all resources within it, or directly to a virtual machine's network interface for granular control. For advanced traffic steering, you can create User-Defined Routes (UDRs) to override Azure's default system routes and direct traffic through a security appliance.
You create a peering connection directly in the Azure portal by navigating to a virtual network's settings. During configuration, you must ensure the address spaces do not overlap. Key settings include enabling virtual network access for direct communication and optionally allowing forwarded traffic, which permits traffic that originated elsewhere to pass through. You can also enable gateway transit, allowing a "spoke" virtual network to use a VPN or ExpressRoute gateway in a central "hub" network. After creation, you verify connectivity by testing communication between virtual machines and monitoring traffic flow.
Peering traffic stays on Microsoft's private network and never touches the public internet. Security is enforced using Network Security Groups (NSGs) applied to the subnets on either side of the peering link. Access to manage peerings is controlled by Azure role-based access control (RBAC), typically requiring the Network Contributor role. The non-transitive nature of peering is itself a security feature, as it prevents automatic connectivity through an intermediate network. For complex routing, you can use service chaining with User-Defined Routes (UDRs) to direct traffic through a Network Virtual Appliance (NVA) in a hub network for inspection.
Evaluate Peering Connectivity and Traffic Flow
Regional VNet Peering (same region) and Global VNet Peering (different regions) both provide low-latency, high-bandwidth connectivity. The available bandwidth is ultimately limited by the size of the virtual machines communicating. Because peering is non-transitive, connecting multiple networks often requires a hub-and-spoke topology, where each spoke peers only with the hub. In this design, enabling gateway transit on the peering allows all spokes to use the hub's gateway for on-premises connectivity. Important constraints include that Global Peering does not support communication with a Basic Load Balancer's frontend IP in the remote network, and data transfer over peering incurs nominal ingress and egress charges.
Manage Public IP Address Lifecycle and Resource Association
Public IP addresses are Azure resources that enable inbound internet connectivity and predictable outbound access. They can be associated with resources like virtual machines, load balancers, and Azure Firewall. You must choose between the Basic and Standard SKU when creating one. The Standard SKU is recommended for production as it is secure by default (closed to all traffic unless allowed by an NSG) and supports Availability Zones. The Basic SKU is open by default and scheduled for retirement. The allocation method can be static (the IP persists) or dynamic (the IP can change if a resource is stopped). For organizations needing multiple addresses, a Public IP Prefix reserves a contiguous range of IPs to simplify firewall rule management.
Evaluate Public IP SKUs and Associated Features
The Standard SKU public IP supports only static allocation and a secure-by-default model, requiring NSG rules to permit traffic. It can be configured as zone-redundant or zonal for high availability. The Basic SKU supports both static and dynamic allocation but does not support zones and is open by default. The SKU of a public IP must match the SKU of the load balancer it is associated with. You can also set a routing preference for a public IP, choosing between the high-performance Microsoft Global Network or the public Internet, which can reduce egress costs. Public IP Prefixes, which only work with Standard SKU static IPs, provide a reserved block of addresses for predictable scaling and security configurations.
Differentiate Between Static and Dynamic Public IP Addresses
Dynamic IP addresses are assigned by default from a pool unique to each Azure region and can change when a resource like a virtual machine is stopped and restarted. Static IP addresses are manually assigned from the same regional pool and remain fixed until the resource is deleted or the allocation method is changed. For private IPs within a subnet, dynamic assignment gives the next available address, while static assignment lets you pick a specific address from the subnet's range. Dynamic IPs are suitable for dev/test environments where IP consistency isn't critical. Static IPs are necessary for production workloads that depend on a fixed address for DNS records, SSL certificates, or firewall rules.
Evaluate Route Propagation and Override Behaviors
Azure uses system routes to manage default traffic flow between subnets and to the internet. To control this flow, you create User-Defined Routes (UDRs) within a route table and associate that table with a subnet. When multiple routes exist for a destination, Azure selects the most specific path using the Longest Prefix Match (LPM) algorithm. If prefixes are identical, a strict priority order applies: UDRs are evaluated first, then Border Gateway Protocol (BGP) routes (from on-premises), and finally system routes. This allows custom configurations to override default Azure behavior. A critical security use of UDRs is forced tunneling, where a route for 0.0.0.0/0 sends all internet-bound traffic to an on-premises gateway or a Network Virtual Appliance (NVA) for inspection.
Define and Implement Custom Routes
To implement custom routing, you first create a route table resource. You then define routes within it, specifying a destination address prefix (like 10.0.2.0/24) and a next hop type. Next hop types include Virtual Appliance (for an NVA), Virtual Network Gateway (for VPN/ExpressRoute), or Internet. Finally, you associate the route table with the target subnet. To complement routing, Network Security Groups (NSGs) filter traffic based on IP and port rules. You can verify the active paths for a resource by checking its effective routes, which combine system routes, BGP routes, and UDRs to show the actual routing table in use.
Implement and Associate Route Tables for Targeted Traffic Control
A common scenario is directing traffic through an NVA for security. This requires enabling IP forwarding on the NVA's network interface so it can process transit traffic. You then create a UDR with the NVA's private IP as the next hop and associate the route table with the source subnet. For hybrid connectivity, forced tunneling uses a UDR to send all outbound internet traffic back to an on-premises network via a virtual network gateway. For large-scale management, Azure Virtual Network Manager can automate the deployment and consistency of routing policies across many virtual networks, handling up to 1,000 routes per configuration.
Troubleshoot network connectivity
Standard tools like ping are often blocked in Azure. Instead, use tools like nameresolver.exe within an App Service to test DNS resolution. Failures can stem from incorrect Azure Private DNS zone configurations or blocked access to the Azure platform's essential virtual IP 168.63.129.16. For hybrid connections using VPN Gateway or ExpressRoute, verify the gateway is in a Succeeded state, check that BGP routes are propagating, and ensure shared keys or certificates match exactly. The Sync Network feature can sometimes resolve tunnel issues. Tools like tcpping and PowerShell's Test-NetConnection help determine if a specific port is reachable, isolating network-layer problems.
Network Security Groups (NSGs) filter traffic based on a 5-tuple rule (source/destination IP, port, protocol). For inbound traffic, subnet-level NSG rules are evaluated before NIC-level rules; for outbound, the order is reversed. A single Deny rule at either level will drop traffic, so you must check Effective Security Rules for both. Azure Firewall provides centralized, stateful inspection and can filter by FQDN. Rule priority within the firewall is critical, as a network rule can override an application rule. Misconfigured User-Defined Routes (UDRs) can cause issues like asymmetric routing, where traffic takes different paths out and back. Enable IP forwarding on an NVA's NIC for it to correctly forward transit traffic.
Utilize Azure Network Watcher for Diagnostics
Azure Network Watcher provides specialized tools for troubleshooting. Connection Monitor tests connectivity and performance between endpoints over time, helping identify intermittent issues. IP Flow Verify checks if a specific packet would be allowed or denied by current NSG rules. Next Hop shows where traffic is routed next, revealing misconfigured UDRs. Packet Capture collects raw network traffic from a VM's NIC for deep analysis with tools like Wireshark. Monitoring network performance metrics like latency and packet loss helps identify bottlenecks before they cause outages, guiding optimization efforts like resizing gateways.