Configure and manage virtual networks in Azure

VNets


VNETs allow you to securely connect Azure resources and enable communication between devices within the network. A VNet is defined using CIDR (Classless Inter-Domain Routing) notation, which specifies the IP address range of the network. It's important to ensure that address spaces do not overlap to avoid conflicts when connecting multiple networks.


To enable communication between devices, you place them within the same VNet. Consider the network on the right. The web servers are internet-facing servers that host a website front-end and deliver that to users. The app servers are running the back-end logic for the app. These servers need to communicate with each other, so we place them in the same VNet.


When adding Virtual Machines (VMs) to a VNet, you attach each VM’s Network Interface Card (NIC) to the VNet. This setup allows the devices to communicate securely with one another within the same network boundary.

App Servers

Web Servers

Application VNet

10.0.0.0/16

Subnets


We want to partition resources for security and performance so we group them in subnets. By dividing a VNet into isolated segments, you gain better control over network traffic and resource access.


In the example on the right, since we have public traffic on the internet facing web servers which we want to separate from our back-end app servers, we can place these servers in different subnets.


IP Address Rules for Subnets

  • Each subnet must have a unique IP address range within the VNet. and cannot overlap with another subnet in the same VNet

  • Address spaces are defined using CIDR (Classless Inter-Domain Routing) notation and occupies a portion of the VNet’s overall IP address space.


Reserved IP Addresses in Subnets

Azure automatically reserves five IP addresses per subnet for system functions.

The first address is the subnet address; the second is the default gateway for the subnet; third and fourth addresses are reserved for Azure DNS services; the last address is reserved for broadcast traffic.

Routes


Azure automatically configures system routes to allow traffic flow between subnets within the same VNet.


When we want to direct traffic through specific paths between subnets we can use User Defined Routes (UDRs) to override system routes. A UDR is attached to a routing table. Routing tables determine the "next hop" of any packet leaving a subnet.


For example, consider the route table attached to the Public subnet. It contains one User Defined Route. The route states that any packet with an address prefix (destination) within the range of 10.0.3.0/24 (which is the Private subnet) must first travel to the DMZ subnet to be inspected by the Network Virtual Appliance. In other words, its next hop is the IP address 10.0.2.4.


The NVA can then inspect and filter the traffic before routing the packet to its destination, filtering incoming traffic from a public-facing subnet before it reaches internal networks.


All UDRs contain three components: the address prefix (destination of the packet), next hop address (where the packet is being redirected to first) and next hope type (the type of appliance at the next hop address).


Note that a destination of 0.0.0.0/0, signifies that a packet is destined for the internet. The routing table attached to the private subnet has a UDR that forwards internet bound traffic via the NVA also.

Public IPs


Our web servers are running a web application that is accessible over the internet via a public IP address.

Static vs. Dynamic: Static IPs remain constant, while dynamic IPs can change. Static IPs are ideal for resources that require consistent addressing.

SKU Types: Basic and Standard SKUs. Standard SKUs offer improved security and performance features.

Assignment: Public IPs can be assigned to various resources, including VMs, load balancers, and application gateways.

DNS Configuration: Public IP addresses can be associated with custom DNS names for easier access.

Network Peering


When we need resources in different Virtual Networks (VNets) to communicate, we use VNet Peering. Peering enables direct, low-latency connectivity between VNets, making them function as if they are part of the same network.


By default, Azure routes traffic between VNets over the Microsoft backbone infrastructure, ensuring low latency, high bandwidth, and security. This is particularly useful when we need to control traffic to another VNet, such as one hosting a public-facing service, while ensuring that internal communication remains on Azure’s private network rather than traversing the public internet.

Key Considerations of Network Peering


Types of VNet Peering

Peering can be established within the same region or across different regions:

  • Virtual Network Peering connects VNets within the same Azure region.

  • Global Virtual Network Peering connects VNets across different Azure regions.


Peering is non-transitive

Meaning traffic does not automatically pass through multiple peered VNets. Each peering connection must be explicitly defined. Additionally, all traffic remains on Azure’s backbone network, ensuring high performance and security.

Gateway Transit


Gateway Transit allows a peered VNet to use the VPN or ExpressRoute gateway of another VNet without needing its own gateway. This is useful when multiple VNets need secure, on-premises connectivity but don’t require separate gateways for each network.


When enabled, traffic from a VNet without a gateway can flow through a peered VNet’s gateway to reach on-premises networks or external sites. This reduces costs and simplifies management by centralizing gateway resources. However, gateway transit only works with global VNet peering if the gateways are in the same Azure region.