...because there are hundreds of sites covering the topic of VNETs, all full of neat diagrams, but 0 that illustrate it using footwear...😅
VNETs in a nutshell
- Isolation boundary by design - resources in one VNET cannot communicate with resource in other VNETs unless they are peered
- has to have at least one defined subnet inside (but can contain multiple)
- if resources in different VNETs need to communicate you can either peer them, or use routing if your Azure environment has been appropriately designed for that
- you can peer VNETs in the same region or globally
- traffic b/n VNETs is private, low latency and traverses the Azure backbone
- cannot be renamed
Look at the picture at the beginning of the post. Each shoe is fully peered to the other two, creating a full mesh. I bet you didn't expect to ever read such a sentence.
In case the shoe visual is insufficient and you prefer to see what that looks like in Azure:
...or not to peer
If you outgrow the peering option or would like to create a more scalable solution, Microsoft has a great reference architecture for you. Essentially, you are looking at creating a hub and spoke topology - one VNET, in the heart of which an NVA (network virtual appliance, i.e. a firewall) routes traffic to the spokes.
That gives you:
- the ability to inspect and control traffic from one place - the NVA
- lowers the admin overhead - since VNETs by design don't support transitive traffic (i.e. just because A is peered to B, which is peered to C does not mean that A can "talk" to C) if you need to connect all VNETs, you'd have to create a full mesh design. NVA reduces that need and saves you some clicks.
- you can deploy resources shared by all VNETs into the hub instead of individually to each of the VNETs
Things to watch out for:
In addition to the VNET best practice and advice from Microsoft, below are some additional tips to avoid future regret 😉.
Can't rename VNETs so spend some time contemplating a sensible and coherent naming convention. In case you already have a VNET with resources in it, and you decide that you absolutely cant live with its name, the only option is to create a new VNET and move resources into it.
Host firewall on by default
Windows VMs in Azure are spun up with the host firewall on. If you are wondering why you can RDP, or even better, use Bastion to connect from a VM in one VNET to a VM in another, but can't ping it, this is why. Ask me how long it took me to figure that out and how many NSGs I've looked at before it dawned on me to check the hosts...
Although VNETs are free, ingress/egress VNET traffic isn't. It is cheaper if the VNETs are in the same region and more expensive if they are in different ones.