Azure Virtual Network
Overview
Azure Virtual Network (VNet) is the foundation of private networking in Azure.
It allows Azure resources (like VMs, databases, containers, etc.) to communicate securely with each other, the internet, and on-premises networks.
Think of it as the Azure equivalent of an on-premises network, complete with subnets, IP address ranges, routing, and security.
What It Does
- Creates isolated, secure network environments in the Azure cloud.
- Enables resource communication within and across subnets or VNets.
- Allows connectivity to the internet, VPNs, or on-premises infrastructure.
- Supports network security, traffic filtering, and routing control.
Key Components
Component | Description |
---|---|
Address Space | IP range for the VNet (e.g. 10.0.0.0/16 ) |
Subnet | Division within a VNet (e.g. 10.0.1.0/24 ) — isolates workloads |
NIC | Network Interface Cards attached to VMs or services |
NSG (Network Security Group) | Firewall rules to allow/deny traffic |
UDR (User-Defined Routes) | Custom routing for advanced control |
Public/Private IPs | Control access to resources from outside the network |
Peering | Connect VNets in the same or different regions |
DNS | Name resolution, custom or Azure-provided |
Typical Use Cases
- Host VMs or services in private subnets with fine-grained control
- Secure communication between Azure services (e.g., VMs, databases, app services)
- Extend on-premises networks to the cloud via VPN or ExpressRoute
- Segregate environments (Dev, Test, Prod) using VNets or subnets
- Enable hybrid cloud architecture
Example VNet Configuration
- Address space:
10.0.0.0/16
-
Subnets:
10.0.1.0/24
(Web)10.0.2.0/24
(App)10.0.3.0/24
(Data)
Each subnet can have NSGs, route tables, and private IPs — isolating workloads and enforcing security boundaries.
Advantages
- Isolation – Full control over traffic within and across subnets
- Security – Use NSGs, firewalls, and private endpoints
- Hybrid ready – Seamless integration with on-prem networks
- Scalable – Support for thousands of IPs and peered VNets
- Private access to Azure services – Via Private Link
Drawbacks / Considerations
- Requires network planning (IP ranges, subnets, routes)
- Misconfigured NSGs or routes can cause connectivity issues
- Peering and VPNs may incur cost and limits (e.g., transitive routing not allowed by default)
- Overhead if PaaS alternatives are suitable (e.g., App Service with public IP)
Example: Create VNet via Azure CLI
az network vnet create \
--resource-group MyResourceGroup \
--name MyVNet \
--address-prefix 10.0.0.0/16 \
--subnet-name WebSubnet \
--subnet-prefix 10.0.1.0/24
Security Features
- NSGs: Control inbound/outbound traffic at subnet/NIC level
- Private Endpoints: Access Azure services via private IP
- Azure Firewall: Centralised, stateful packet inspection
- DDoS Protection: Basic (free) or Standard (paid)
- Service Endpoints: Connect securely to services like Azure Storage
Connectivity Options
Type | Use Case |
---|---|
Public IP | Expose a resource to the internet |
VPN Gateway | Site-to-site connection to on-prem |
ExpressRoute | Private, high-speed dedicated link |
VNet Peering | Low-latency private VNet-to-VNet traffic |
Azure Bastion | Secure RDP/SSH without public IPs |
When to Use VNet
Scenario | Use VNet? |
---|---|
Hosting VMs | Yes |
Need private, secure service access | Yes |
Integrating Azure with on-prem systems | Yes |
Simple web app with public access | No (not always) |
Using Functions or App Service in isolation | No (by default) — but can integrate with VNet if needed |
Further Reading
Summary
Feature | Azure VNet Provides |
---|---|
Network Isolation | Separate subnets, resources, and access |
Secure Communication | NSGs, private IPs, service endpoints |
Hybrid Connectivity | VPN, ExpressRoute, peering |
Service Integration | Azure services within private networks |