Microsoft Azure — Virtual Network (VNet)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers virtual network (vnet) with production-ready configurations, best practices, and hands-on examples.

Azure VNet Fundamentals: Why You Need a Virtual Network

Azure Virtual Network (VNet) is the foundation of network isolation in Azure. Think of it as your own private network in the cloud, where you can launch resources like VMs, App Services, and databases. Without a VNet, your resources are exposed to the public internet by default — a recipe for disaster. A VNet provides IP address space (CIDR blocks), subnet segmentation, and DNS resolution. You control inbound and outbound traffic using Network Security Groups (NSGs) and route tables. In production, you never deploy resources outside a VNet. Even single-VM dev environments should be inside a VNet to enforce least-privilege access. The first decision is IP address planning: avoid overlapping with on-premises networks if you plan hybrid connectivity. Use RFC 1918 private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). For large enterprises, allocate a /16 or larger to accommodate growth.

#!/bin/bash
# Create a resource group and VNet with two subnets
az group create --name prod-rg --location eastus
az network vnet create \
  --name prod-vnet \
  --resource-group prod-rg \
  --address-prefix 10.0.0.0/16 \
  --subnet-name web-subnet \
  --subnet-prefix 10.0.1.0/24
az network vnet subnet create \
  --name db-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.2.0/24

Subnet Design: Segmentation for Security and Performance

Subnets divide your VNet into logical segments. Each subnet gets a contiguous IP range. Use subnets to isolate tiers: web, application, database, management. This enables granular NSG rules. For example, allow inbound HTTP only to the web subnet, and allow database traffic only from the app subnet to the DB subnet. Never put all resources in a single subnet — that's a flat network with no security boundaries. In production, use at least three subnets: public-facing (web), private (app), and data (DB). Consider service endpoints or Private Link for PaaS services like Azure SQL or Storage. Subnets also affect availability: Azure reserves five IPs per subnet (first four and last one). Plan your CIDR accordingly. For high availability, spread VMs across availability zones within the same subnet — Azure handles the routing.

#!/bin/bash
# Create additional subnets for app and management
az network vnet subnet create \
  --name app-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.3.0/24
az network vnet subnet create \
  --name mgmt-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.4.0/24
# List all subnets
az network vnet subnet list --resource-group prod-rg --vnet-name prod-vnet --output table

Network Security Groups: The First Line of Defense

NSGs filter traffic at the subnet or NIC level. They contain security rules that allow or deny inbound/outbound traffic based on source/destination IP, port, and protocol. Each rule has a priority (100-4096). Lower numbers are evaluated first. By default, all inbound traffic is denied, and all outbound is allowed. In production, you must lock down outbound traffic too — especially to the internet. Use service tags (e.g., AzureLoadBalancer, VirtualNetwork) to simplify rules. Never use broad rules like 'Allow all from Internet'. Instead, whitelist specific IP ranges. NSGs are stateful: if you allow inbound on port 80, the return traffic is automatically allowed. But beware: NSGs do not replace a firewall. For advanced inspection, use Azure Firewall or a NVA.

#!/bin/bash
# Create NSG and rules for web subnet
az network nsg create --name web-nsg --resource-group prod-rg
az network nsg rule create \
  --nsg-name web-nsg \
  --resource-group prod-rg \
  --name AllowHTTP \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80
az network nsg rule create \
  --nsg-name web-nsg \
  --resource-group prod-rg \
  --name DenyAllInbound \
  --priority 4096 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'
# Associate NSG with subnet
az network vnet subnet update \
  --name web-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --network-security-group web-nsg

VNet Peering: Connecting VNets for Multi-Tier Architectures

VNet peering connects two VNets in the same or different regions, enabling resources to communicate via the Microsoft backbone. Peering is non-transitive: if VNet A peers with B, and B peers with C, A does not automatically connect to C. You must create explicit peerings. Use peering for hub-and-spoke topologies: a central hub VNet (with shared services like firewall, VPN gateway) peers with multiple spoke VNets (each for a workload). This reduces management overhead and enforces traffic inspection. Peering has no bandwidth limit and low latency. But be aware of overlapping IPs — they break peering. Plan IP ranges carefully. For cross-region peering (global peering), there is no additional cost for data transfer between Azure regions, but egress to internet still applies.

#!/bin/bash
# Create a second VNet and peer with the first
az network vnet create \
  --name spoke-vnet \
  --resource-group prod-rg \
  --address-prefix 10.1.0.0/16 \
  --subnet-name workload-subnet \
  --subnet-prefix 10.1.1.0/24
# Peer hub to spoke
az network vnet peering create \
  --name hub-to-spoke \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --remote-vnet spoke-vnet \
  --allow-vnet-access
# Peer spoke to hub
az network vnet peering create \
  --name spoke-to-hub \
  --resource-group prod-rg \
  --vnet-name spoke-vnet \
  --remote-vnet prod-vnet \
  --allow-vnet-access
# Verify peering
az network vnet peering list --resource-group prod-rg --vnet-name prod-vnet --output table

Route Tables and Custom Routes: Steering Traffic Your Way

Azure automatically creates system routes for each subnet: local VNet traffic, internet-bound traffic, and traffic to peered VNets. But sometimes you need custom routes — for example, to force all internet traffic through a firewall or to route traffic between spokes via the hub. Use route tables (UDRs) to override system routes. Each route table contains routes with an address prefix and next hop type (VirtualAppliance, VirtualNetworkGateway, Internet, None). The most specific prefix wins. In production, you often create a route table for each subnet. For forced tunneling (all internet traffic goes through a firewall), set the default route (0.0.0.0/0) to a virtual appliance. Be careful: if the firewall goes down, you lose all internet access. Implement high availability for the NVA.

#!/bin/bash
# Create route table and add default route to NVA
az network route-table create --name web-rt --resource-group prod-rg
az network route-table route create \
  --route-table-name web-rt \
  --resource-group prod-rg \
  --name DefaultToFirewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.4.4
# Associate with subnet
az network vnet subnet update \
  --name web-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --route-table web-rt

Service Endpoints and Private Link: Securing PaaS Services

By default, PaaS services like Azure Storage, SQL Database, and Key Vault are accessible over the public internet. To secure them, you have two options: service endpoints and Private Link. Service endpoints extend your VNet identity to the PaaS service, allowing you to restrict access to your VNet only. They are free and easy to configure, but traffic still traverses the Microsoft backbone over the public endpoint. Private Link creates a private IP in your VNet that maps to the PaaS service. Traffic never leaves the Microsoft network. Private Link is more secure but costs extra. In production, use Private Link for sensitive data (e.g., databases, key vaults). Use service endpoints for less critical services or when cost is a concern. Both require DNS configuration to resolve the private endpoint.

#!/bin/bash
# Create a Private Endpoint for Storage Account
# First, create a storage account
az storage account create \
  --name prodstorage123 \
  --resource-group prod-rg \
  --location eastus \
  --sku Standard_LRS
# Create Private Endpoint
az network private-endpoint create \
  --name storage-pe \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --subnet db-subnet \
  --private-connection-resource-id $(az storage account show --name prodstorage123 --resource-group prod-rg --query id -o tsv) \
  --group-id blob \
  --connection-name storage-connection
# Create Private DNS Zone
az network private-dns zone create \
  --name privatelink.blob.core.windows.net \
  --resource-group prod-rg
# Link zone to VNet
az network private-dns link vnet create \
  --name storage-dns-link \
  --resource-group prod-rg \
  --zone-name privatelink.blob.core.windows.net \
  --virtual-network prod-vnet \
  --registration-enabled false
# Get private endpoint IP
az network private-endpoint show --name storage-pe --resource-group prod-rg --query 'customDnsConfigs[0].ipAddresses[0]' -o tsv

Azure DNS and Custom DNS: Name Resolution in VNets

Azure provides default DNS for VNets (168.63.129.16). It resolves Azure internal names and public DNS. But in production, you often need custom DNS — for example, to resolve on-premises hostnames or use private DNS zones. You can configure custom DNS servers at the VNet level. All VMs in that VNet will use those servers. For hybrid scenarios, use Azure DNS Private Resolver or forwarders to on-premises DNS. Azure Private DNS Zones allow you to create custom zones (e.g., contoso.com) that are resolvable only within your VNets. Link zones to VNets for automatic registration of VM hostnames. In production, avoid using the default Azure DNS for anything beyond basic needs. Implement a proper DNS strategy with conditional forwarding.

#!/bin/bash
# Update VNet to use custom DNS servers
az network vnet update \
  --name prod-vnet \
  --resource-group prod-rg \
  --dns-servers 10.0.4.4 10.0.4.5
# Create a Private DNS Zone and link
az network private-dns zone create \
  --name internal.contoso.com \
  --resource-group prod-rg
az network private-dns link vnet create \
  --name internal-link \
  --resource-group prod-rg \
  --zone-name internal.contoso.com \
  --virtual-network prod-vnet \
  --registration-enabled true
# Add an A record
az network private-dns record-set a create \
  --name appserver \
  --zone-name internal.contoso.com \
  --resource-group prod-rg
az network private-dns record-set a add-record \
  --record-set-name appserver \
  --zone-name internal.contoso.com \
  --resource-group prod-rg \
  --ipv4-address 10.0.3.10

Monitoring and Troubleshooting VNet Connectivity

Azure provides several tools to monitor and troubleshoot VNet connectivity. Network Watcher is the Swiss Army knife: it includes IP flow verify (check if traffic is allowed/denied), next hop (show routing path), connection troubleshoot (test TCP connectivity), and packet capture. Use Azure Monitor for metrics (packets in/out, dropped packets) and logs (NSG flow logs). In production, enable NSG flow logs and send them to Log Analytics for analysis. Set up alerts for unusual traffic patterns. For performance issues, use Azure Monitor for VMs or Network Performance Monitor. Common issues: misconfigured NSGs, missing routes, DNS resolution failures, and peering misconfigurations. Always start with IP flow verify to rule out NSG issues.

#!/bin/bash
# Use Network Watcher to verify IP flow
az network watcher test-ip-flow \
  --direction inbound \
  --protocol tcp \
  --local 10.0.1.4:80 \
  --remote 203.0.113.5:12345 \
  --vm vm-web-01 \
  --resource-group prod-rg
# Check next hop
az network watcher show-next-hop \
  --vm vm-web-01 \
  --resource-group prod-rg \
  --source-ip 10.0.1.4 \
  --dest-ip 10.0.2.10
# Enable NSG flow logs
az network watcher flow-log create \
  --resource-group prod-rg \
  --nsg web-nsg \
  --storage-account prodstoragelogs \
  --retention 30

Hybrid Connectivity: VPN Gateway and ExpressRoute

To connect on-premises networks to Azure VNets, use VPN Gateway (site-to-site) or ExpressRoute (dedicated private connection). VPN Gateway uses IPsec/IKE tunnels over the internet. It's cost-effective but limited by internet reliability and bandwidth (up to 10 Gbps aggregated). ExpressRoute provides a private, dedicated connection with higher bandwidth (up to 100 Gbps) and lower latency. In production, use ExpressRoute for critical workloads and VPN as a backup. Both require a gateway subnet in the VNet (named GatewaySubnet). Plan IP addresses: the gateway subnet must be /27 or larger. For high availability, deploy active-active VPN gateways or ExpressRoute circuits with redundant connections. Use Azure Virtual WAN for large-scale hybrid networks.

#!/bin/bash
# Create a gateway subnet
az network vnet subnet create \
  --name GatewaySubnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.0.0/27
# Create a VPN gateway (takes 30-45 minutes)
az network vpn-gateway create \
  --name prod-vpngw \
  --resource-group prod-rg \
  --location eastus \
  --vnet prod-vnet \
  --gateway-type Vpn \
  --sku VpnGw2 \
  --vpn-type RouteBased
# Create local network gateway for on-premises
az network local-gateway create \
  --name onprem-gw \
  --resource-group prod-rg \
  --gateway-ip-address 203.0.113.1 \
  --local-address-prefixes 192.168.0.0/16
# Create connection
az network vpn-connection create \
  --name onprem-conn \
  --resource-group prod-rg \
  --vnet-gateway1 prod-vpngw \
  --local-gateway2 onprem-gw \
  --shared-key MySecretKey123

Azure Firewall: Centralized Traffic Inspection and Logging

Azure Firewall is a managed, cloud-native firewall service. It provides stateful inspection, application rules (FQDN filtering), network rules, and threat intelligence. Unlike NSGs, it can inspect outbound traffic and log all flows. In production, deploy Azure Firewall in a hub VNet and route all spoke traffic through it. This gives you a single point for policy enforcement and logging. Azure Firewall supports SNAT for outbound traffic and DNAT for inbound. It integrates with Azure Monitor for logs and metrics. For high availability, Azure Firewall is automatically HA within an availability zone. Use Azure Firewall Manager to manage policies across multiple firewalls. Cost is a consideration: it's more expensive than NVAs but saves operational overhead.

#!/bin/bash
# Create a subnet for Azure Firewall (must be named AzureFirewallSubnet)
az network vnet subnet create \
  --name AzureFirewallSubnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.5.0/26
# Create public IP for firewall
az network public-ip create \
  --name fw-pip \
  --resource-group prod-rg \
  --sku Standard \
  --allocation-method Static
# Create firewall
az network firewall create \
  --name prod-fw \
  --resource-group prod-rg \
  --location eastus \
  --sku AZFW_VNet \
  --tier Standard
# Configure firewall IP config
az network firewall ip-config create \
  --firewall-name prod-fw \
  --name fw-config \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --public-ip-address fw-pip
# Add a network rule to allow outbound HTTPS
az network firewall network-rule create \
  --firewall-name prod-fw \
  --resource-group prod-rg \
  --collection-name outbound \
  --destination-addresses '*' \
  --destination-ports 443 \
  --name AllowHTTPS \
  --protocols TCP \
  --source-addresses '*' \
  --action Allow \
  --priority 100

Network Policies for AKS: Micro-Segmentation at the Pod Level

When running AKS (Azure Kubernetes Service) inside a VNet, you need network policies to control traffic between pods. Azure provides two options: Azure Network Policy Manager (using Azure NSGs) and Calico (open-source). Azure NPM integrates with NSGs but has limitations (e.g., no support for egress policies). Calico is more feature-rich and widely used in production. Network policies are Kubernetes resources that define ingress/egress rules based on pod labels, namespaces, and IP blocks. In production, use Calico for fine-grained control. Always enable network policy enforcement on your AKS cluster. Without it, all pods can communicate freely — a security risk. Combine network policies with Azure Firewall for egress traffic to the internet.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

Cost Optimization for VNet Resources

VNet itself is free, but associated resources incur costs: VPN Gateway, Azure Firewall, Public IPs, Private Link, and data transfer. To optimize: use VNet peering instead of VPN for cross-region connectivity (peering is free for data transfer within region, small cost for cross-region). Use Azure Firewall only when needed; for simple filtering, NSGs suffice. Use Basic public IPs for dev/test (Standard has hourly cost). For VPN Gateway, choose the right SKU: VpnGw1 for small sites, VpnGw2 for production. Use ExpressRoute with metered billing for low-bandwidth needs. Monitor costs with Azure Cost Management. Set budgets and alerts. In production, right-size gateways and firewalls based on actual throughput. Consider using Azure Reserved Instances for VPN Gateway and ExpressRoute to save up to 40%.

#!/bin/bash
# Use Azure Pricing Calculator CLI (az pricing) to estimate costs
# This is a conceptual example; actual command may vary
az pricing estimate \
  --service vpn-gateway \
  --sku VpnGw2 \
  --region eastus \
  --hours 730
az pricing estimate \
  --service azure-firewall \
  --tier Standard \
  --region eastus \
  --data-processed 1000