Azure Virtual Networks (VNets) are the fundamental building blocks of your private network in Azure, acting as a logical isolation boundary for your cloud resources.
Let’s see a VNet in action. Imagine you have a web application deployed across several Virtual Machines (VMs) in Azure. These VMs need to communicate with each other securely and also potentially with your on-premises network. Here’s a snippet of how that might look in Azure Resource Manager (ARM) templates, defining a VNet and a subnet:
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-11-01",
"name": "myProductionVNet",
"location": "eastus",
"properties": {
"addressSpace": {
"addressPrefixes": [
"10.1.0.0/16"
]
},
"subnets": [
{
"name": "webservers",
"properties": {
"addressPrefix": "10.1.1.0/24"
}
},
{
"name": "databases",
"properties": {
"addressPrefix": "10.1.2.0/24"
}
}
]
}
}
This JSON defines a VNet named myProductionVNet with an address space of 10.1.0.0/16. Within this VNet, we have two subnets: webservers (10.1.1.0/24) and databases (10.1.2.0/24). VMs assigned to the webservers subnet will get IP addresses from 10.1.1.0 to 10.1.1.255, and those in the databases subnet from 10.1.2.0 to 10.1.2.255. This segmentation is crucial for security and traffic management.
The core problem a VNet solves is providing a secure, private, and isolated network environment for your Azure resources, mimicking a traditional on-premises network but within the Azure cloud. It allows you to define your own IP address spaces, create subnets for logical segmentation, and control network traffic flow with routing and security rules. This isolation is fundamental for meeting compliance requirements and protecting sensitive data.
Internally, Azure VNets are built on a distributed system that manages IP address allocation, routing, and network policy enforcement. When you create a VNet, Azure provisions a virtual network infrastructure that ensures your resources can communicate with each other using private IP addresses. This infrastructure also handles the underlying connectivity to the Azure backbone network, enabling communication with other Azure services and the internet.
The key levers you control are:
- Address Space: This is the overall range of private IP addresses you allocate to your VNet (e.g.,
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16). Choosing an appropriate address space that doesn’t overlap with your on-premises networks is critical for hybrid cloud scenarios. - Subnets: You divide your VNet’s address space into smaller, manageable subnets. This allows for granular control over security, routing, and resource deployment. Resources within the same subnet can communicate freely by default, while traffic between subnets is subject to Network Security Groups (NSGs) and User Defined Routes (UDRs).
- Network Security Groups (NSGs): These are stateful packet filtering firewalls that you can associate with subnets or individual network interfaces. NSGs allow you to define inbound and outbound security rules to permit or deny traffic based on source/destination IP address, port, and protocol.
- User Defined Routes (UDRs): UDRs enable you to override Azure’s default system routing tables. This is essential for directing traffic through network virtual appliances (like firewalls or intrusion detection systems) or for implementing custom routing policies between subnets or to/from on-premises networks.
- Gateway Subnet: A special subnet dedicated to hosting your VPN gateway or ExpressRoute gateway, which is used to connect your VNet to your on-premises network or other VNets.
When designing for production, you’ll often need to connect your Azure VNet to your on-premises data center. This is typically achieved using a VPN Gateway for site-to-site VPN connections or Azure ExpressRoute for a dedicated, private connection. A common mistake is to place resources directly in the gateway subnet, which is reserved for the gateway infrastructure and will cause deployment failures.
The next logical step after establishing your VNet and its connectivity is to implement robust network security policies using Network Security Groups and potentially Azure Firewall.