A virtual machine needs a way to exchange data with other resources. In Azure, a virtual network (VNet) provides that connection: without one, a VM is isolated, and you cannot create a VM without attaching it to a VNet. Think of the VNet as the road network that lets cloud resources reach one another. section 3.3 section 4.1
A VNet has its own local IP address range. Divide it into subnets to give groups of resources separate portions of that range; subnet ranges must not overlap. If the VNet is a city’s road network, each subnet is a suburb’s roads. Plan the address range before adding subnets, especially if the network may grow. section 4.2
Start with a VM, then plan for growth
When creating a VM in the Azure portal, choose an existing VNet or create one on the Networking tab. For a first VM, leaving the subnet at its default is a reasonable starting point. As an organization adds services, it can place them in separate subnets and apply network security rules where needed. A VNet supplies connectivity; a network security group (NSG) controls which traffic is allowed or denied. section 3.3 section 3.3.1 section 4.6
New-AzVirtualNetwork -Name AlpacaVNet -ResourceGroupName 'AlpacaRG' -Location 'Australia Southeast' -AddressPrefix '10.0.0.0/16'
This PowerShell listing creates a VNet in a resource group and gives it the address prefix 10.0.0.0/16. Choose the resource group, region, and range for your own deployment. section 4.1
A VNet can also be part of a wider network. Azure VNet peering connects VNets; VPN Gateways and ExpressRoute connect Azure VNets with on-premises networks. Pick the connection to match the networks that need to communicate. Keep traffic controls in the plan, too: connectivity is useful, but not every road needs to be open to everyone. section 4.4 section 4.6
