What is an Azure Virtual Network?

Azure Virtual Network (VNet) is the foundational building block for your private network in Azure. It enables Azure resources, such as Virtual Machines, to securely communicate with each other, with the internet, and with your on-premises environments. VNets provide:

Isolation: Your VNet is logically isolated from other Azure customers' VNets.
Segmentation: You can segment your VNet into subnets for better organization and security.
Connectivity: Enable communication between Azure resources, on-premises networks, and the internet.
Security: Control network traffic flow with Network Security Groups (NSGs) and User Defined Routes (UDRs).

A Virtual Network is a representation of your own network in the cloud.

Core Concepts

Understanding these core concepts is crucial for designing and managing your Azure network infrastructure:

Virtual Network (VNet): A logical representation of your network in Azure.
Subnet: A range of IP addresses within your VNet. Resources are deployed into subnets.
IP Address: Used to identify resources within a VNet. Supports IPv4 and IPv6.
Network Interface (NIC): Connects an Azure resource (like a VM) to a VNet.
Network Security Group (NSG): A stateful packet filtering firewall that allows or denies network traffic to resources.
Route Table: Used to define User Defined Routes (UDRs) to control traffic flow.
Gateway: Enables connectivity between your VNet and other networks (e.g., on-premises).

IP Addressing

Each Virtual Network is defined by a private IP address space in RFC 1918. You choose the address space when you create a VNet.

Address Space: A public or private IP address range. For private IP spaces, you can use ranges like 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
CIDR Notation: Address spaces are defined using Classless Inter-Domain Routing (CIDR) notation (e.g., 10.1.0.0/16).
Address Overlap: Ensure that the VNet address space does not overlap with any on-premises address spaces if you plan to connect them.
IPv6 Support: Azure VNets also support IPv6 address spaces.

Example of defining an address space:

AddressSpace:
  - 10.0.0.0/16

Subnets

Subnets allow you to divide your VNet's IP address space into smaller, manageable segments. This is crucial for:

Organization: Grouping resources with similar connectivity or security requirements.
Security: Applying Network Security Groups (NSGs) at the subnet level to control traffic.
Routing: Directing traffic between subnets or to external destinations.

Azure reserves the first four and the last IP address in each subnet for IP resolution.

Each subnet must have a unique name within the VNet.

Example of subnet configuration:

Subnets:
  - Name: FrontendSubnet
    AddressPrefix: 10.0.1.0/24
  - Name: BackendSubnet
    AddressPrefix: 10.0.2.0/24

Network Interfaces (NICs)

A Network Interface (NIC) connects an Azure resource, typically a Virtual Machine, to a Virtual Network. Each NIC can have one or more IP configurations:

Primary IP Configuration: The main IP address assigned to the NIC.
Secondary IP Configurations: Allows a VM to have multiple IP addresses, useful for hosting multiple websites or services on a single VM.
MAC Address: Each NIC has a unique MAC address.

You can associate NSGs and User Defined Routes (UDRs) with a NIC or a subnet. Applying them at the subnet level is generally recommended for easier management.

Routing

Azure automatically routes traffic between subnets within a VNet. However, you can customize routing behavior using User Defined Routes (UDRs) and Border Gateway Protocol (BGP) routes:

System Routes: Default routes managed by Azure.
User Defined Routes (UDRs): You can create custom route tables to override system routes for specific traffic. This is essential for implementing network virtual appliances (NVAs) like firewalls or VPN devices.
BGP: Enables dynamic routing between your VNet and on-premises networks via VPN gateways or ExpressRoute.

Common use cases for UDRs include:

Forcing all outbound internet traffic through a firewall appliance.
Directing traffic to a network virtual appliance for inspection.

Security

Security is paramount in VNet design. Azure provides several mechanisms to secure your network:

Network Security Groups (NSGs): Act as a distributed firewall. You define rules to allow or deny inbound and outbound traffic to resources based on source/destination IP address, port, and protocol.
Azure Firewall: A managed, cloud-based network security service that protects your Azure Virtual Network resources.
Network Security Zones (NSZs): A conceptual grouping of security services.
Private Endpoints: Allow secure access to Azure PaaS services from within your VNet without exposing them to the public internet.
Service Endpoints: Extend your VNet's private address space and identity to Azure services.

NSG rules are evaluated in order:

Priority: Rules are processed based on their priority number (lower numbers have higher priority).
Stateful: If an inbound packet is allowed, the corresponding outbound traffic is automatically allowed.
Allow/Deny: Rules can either allow or deny traffic.
Default Rules: Azure provides default rules for inbound and outbound traffic.

Connectivity Options

Virtual Networks are designed to connect various resources and networks:

Within Azure: Resources in different subnets of the same VNet can communicate freely (unless restricted by NSGs).
To the Internet: Outbound traffic to the internet is enabled by default. Inbound traffic is blocked unless explicitly allowed.
On-Premises Networks:
- VPN Gateway: Establishes encrypted tunnels over the public internet between your VNet and your on-premises network.
- ExpressRoute: Provides a dedicated, private connection from your premises to Azure, offering higher bandwidth and lower latency.
Between Azure VNets:
- VNet Peering: Connects two Azure VNets, allowing resources in each VNet to communicate as if they were on the same network. Supports global peering.

When connecting VNets or on-premises networks, carefully plan your IP addressing to avoid overlaps.

DNS Resolution

Azure provides built-in DNS services for resolving names within your VNet. You can also integrate your own DNS servers.

Azure-provided DNS: By default, resources within a VNet use Azure's DNS servers, which can resolve Azure resource names and internal hostnames.
Custom DNS Servers: You can specify custom DNS servers for your VNet. This is often used when connecting to on-premises networks that rely on specific internal DNS infrastructure.
Private DNS Zones: A DNS hosting service that provides a reliable, highly available domain name resolution for your virtual networks without requiring you to deploy and manage a custom DNS solution.

Management and Best Practices

Effective management of Virtual Networks involves planning, monitoring, and adhering to best practices:

Plan your IP addressing scheme carefully before creating VNets and subnets.
Use meaningful names for VNets, subnets, and NSGs.
Segment your network into smaller subnets based on security zones or application tiers.
Apply NSG rules at the subnet level whenever possible for consistent security policies.
Monitor network traffic using Azure Network Watcher and NSG flow logs.
Leverage VNet peering for secure and efficient inter-VNet communication.
Document your network architecture clearly.