Understanding Azure Virtual Networks (VNet): Concepts, Best Practices, and Connectivity Options

Azure Virtual Network (VNet) is the fundamental building block of a private network in Azure, allowing resources such as virtual machines to communicate securely with the internet and internal networks while benefiting from Azure’s scalability, availability, and isolation.

VNet Concept

Address space : When creating a VNet you must specify a custom private IP address space using public and private (RFC 1918) ranges. Azure allocates private IPs to resources from this space, e.g., a VM in a 10.0.0.0/16 VNet may receive 10.0.0.4.

Subnets : Subnets divide the virtual network into one or more segments, each receiving a portion of the address space. Resources are deployed into specific subnets, and network security groups can protect them.

Region : A VNet’s scope is limited to a single Azure region, though VNet peering can connect VNets across regions.

Subscription : VNets are scoped to a subscription; multiple VNets can exist per subscription and per region.

Best Practices

Ensure address spaces do not overlap with other networks in your organization.

Do not let a subnet consume the entire VNet address space; reserve space for future growth.

Prefer fewer large VNets over many small ones to reduce management overhead.

Use Network Security Groups (NSGs) to protect your VNet.

Communicating with the Internet

By default, all resources in a VNet have outbound internet connectivity. Inbound communication requires a public IP address or a public load balancer, and outbound traffic can also be managed via a public IP or load balancer. See Azure documentation for outbound connections, public IPs, and load balancers.

When using only an internal load balancer, outbound connectivity is unavailable until you define how outbound traffic should use an instance‑level public IP or a public load balancer.

Communication Between Azure Resources

Secure communication between Azure resources can be achieved through:

Virtual network : Deploy VMs and other Azure services (App Service Environment, AKS, VM scale sets, etc.) into the same VNet.

Virtual network service endpoints : Extend the VNet’s private address space to Azure services such as Storage or SQL, allowing those services to be accessed only from the VNet.

VNet Peering : Connect two VNets (in the same or different regions) so resources in each can communicate directly.

Communicating with On‑Premises Resources

You can connect your on‑premises network to a VNet using any combination of the following:

Point‑to‑site VPN : Establishes a VPN tunnel from an individual computer to the VNet; ideal for developers or small‑scale scenarios.

Site‑to‑site VPN : Connects an on‑premises VPN device to an Azure VPN gateway, enabling access to the VNet from the entire on‑premises network.

Azure ExpressRoute : Provides a private, dedicated connection between your network and Azure through an ExpressRoute partner.

Filtering Network Traffic

You can filter traffic using one or both of the following options:

Security groups : Network security groups (NSGs) and application security groups (ASGs) contain inbound and outbound rules that filter traffic based on source/destination IP, port, and protocol.

Network virtual appliances : Virtual machines that act as firewalls, WAN optimizers, or other network functions, available through the Azure Marketplace.

Routing Options

By default, Azure routes traffic between subnets, peered VNets, on‑premises networks, and the internet. You can override these routes using one or both of the following:

Route tables : Custom route tables control where traffic from each subnet is sent.

BGP routes : When using an Azure VPN gateway or ExpressRoute, you can propagate your on‑premises BGP routes into the VNet.

Azure VNet Limits

Azure imposes quotas on the number of resources you can deploy in a VNet. Most networking limits are at their maximum values, but you can request increases via the Azure quota request page.

Original documentation: Azure Virtual Networks Overview

Article source: https://pub.intelligentx.net/node/819

Discussion: Join the Knowledge Planet "Chief Architect Circle" or the FeiLiao group "Chief Architect Think Tank".