Virtual Network
An Azure Virtual Network (VNet) is your isolated private network within Azure, providing the address space, subnets, and routing that resources like VMs, App Services, and databases use to communicate securely with each other, the internet, and on-premises networks. Resources in separate VNets cannot communicate by default unless connected via peering or a gateway.
Virtual Network
A VNet is your private slice of the Azure network — subnets, IP ranges, and routing all get defined within it, and it's the boundary NSGs and peering operate on.
Why It Matters in Production
Hotstar runs a dedicated VNet per environment (hotstar-prod-vnet, hotstar-staging-vnet) with non-overlapping CIDR ranges, so peering or connecting to on-prem systems never causes IP conflicts.
az network vnet create --resource-group hotstar-prod-rg
--name hotstar-prod-vnet --address-prefix 10.20.0.0/16
--subnet-name app-subnet --subnet-prefix 10.20.1.0/24
RememberVNet address space cannot be changed after resources are deployed into its subnets without significant rework — plan CIDR ranges carefully upfront.
Frequently Asked Questions
What's actually inside a VNet beyond just an IP range?
A VNet defines the address space (CIDR block), one or more subnets carving that space up, route tables controlling traffic flow between subnets and outward, network security groups filtering traffic at the subnet or NIC level, and optionally DNS settings and peering/gateway connections to other networks. Resources like VMs and App Service (via VNet integration) attach to a specific subnet and inherit its routing and security posture.
What's a common VNet mistake that blocks connectivity between resources later?
Choosing overlapping CIDR ranges across VNets that will eventually need to peer or connect via VPN/ExpressRoute — Azure VNet peering, like most cloud peering, fails outright on overlapping address spaces, and re-addressing a live VNet is disruptive. Plan distinct, non-overlapping ranges across all VNets in an organization from the start, even ones with no immediate plan to connect, since peering needs frequently emerge later (e.g. shared services, hub-and-spoke topology).