Azure Virtual Networks: A Complete Guide to VNets, Subnets, and Security

Virtual networks are the foundation of every Azure deployment that needs isolation, security or private connectivity. They are also the thing most people skip, going straight to deploying a VM or an App Service and then losing an afternoon to working out why two resources cannot reach each other.

This covers what you actually need: address planning, subnets, security groups, peering, private endpoints, load balancing and hybrid connectivity.

What a VNet is doing for you

Think of a VNet as your own section of the data centre. Resources inside it talk to each other freely. Nothing outside it, including the internet, gets in unless you allow it.

Every VNet has three properties that matter:

• An address space, the range of private addresses available. A /16 gives you 65,536.
• One or more subnets, dividing that space into groups of related resources.
• A region. VNets are regional. This is worth remembering if you have come from GCP, where they are not.

Without a VNet your resources sit in shared infrastructure. With one they sit inside a boundary you control, in the same way servers sat behind a firewall in a physical data centre, minus the hardware.

Address space, the decision you cannot easily undo

Most networking mistakes are recoverable. This one is not, or not cheaply.

Pick a range that overlaps your on premises network and VPN connectivity will not work. Pick one that overlaps another VNet and you can never peer them. Pick one too small and you will be rebuilding rather than resizing.

Azure reserves five addresses in every subnet, the first four and the last, which is why a /24 gives you 251 rather than 256. Small detail, and it matters when you size a subnet to exactly the number of machines you planned.

Separate subnets by function

Putting everything in one subnet works and gives you nothing to enforce policy against.

10.0.0.0/16 (VNet address space)
10.0.1.0/24   Web tier
10.0.2.0/24   Application tier
10.0.3.0/24   Data tier
10.0.4.0/24   Management, Bastion and jump hosts
10.0.10.0/24  AKS, which needs more room for pods

The separation is what lets you attach different rules to each tier. Web accepts 443 from the internet. Data accepts connections only from the application subnet. Management accepts nothing except Bastion.

Build a multi subnet VNet from scratch before you plan a real one, because address maths is much more memorable once you have watched a subnet refuse to accept a resource.

Network security groups

NSGs are stateful firewalls attached to a subnet or a NIC. Rules evaluate by priority, lowest number first, and the first match wins.

Every NSG ships with three inbound and three outbound rules you cannot delete. Inbound: allow traffic within the VNet, allow load balancer health probes, deny everything else. Outbound: allow within the VNet, allow everything to the internet, deny the rest.

The consequence worth internalising is that inbound internet traffic is denied by default and outbound is allowed by default. You open inbound deliberately. You restrict outbound deliberately. Most people do the first and forget the second.

The mistake everybody makes once

Opening 22 or 3389 to 0.0.0.0/0. Automated scanners find exposed management ports within minutes, and the login attempts start immediately.

Use Bastion instead. It gives you RDP and SSH through the portal without any management port being reachable from the internet, which removes the whole category of problem rather than mitigating it.

Configure NSGs and application security groups to see how rule precedence actually resolves, which is harder to predict than it looks on paper.

Then set up Bastion and delete the inbound SSH rule you were about to write.

Peering

Peering connects two VNets so resources address each other privately, as though they shared a network. Traffic stays on Azure's backbone.

Regional peering connects VNets in one region. Global peering spans regions and bills for the cross region transfer.

The main use is hub and spoke: a central VNet holding shared services, Bastion and firewalls, peered out to workload VNets. It is Azure's recommended enterprise pattern and it is worth adopting before you need it.

Two things catch people out.

Peering is not transitive. If A peers with B and B peers with C, A still cannot reach C. You either peer A to C directly or route through an appliance in B. People lose real time to this one.

Address spaces cannot overlap. Two VNets both on 10.0.0.0/16 can never be peered, which is why the address planning section above comes first.

Configure peering between two VNets and verify it.

Private endpoints

By default, PaaS services such as Storage, SQL and Key Vault are reachable over the internet on a public endpoint. A private endpoint gives that service a private address from your VNet, so traffic never leaves the backbone.

Before:

VM (10.0.1.4)  ->  internet  ->  Storage account (public endpoint)

After:

VM (10.0.1.4)  ->  private endpoint (10.0.3.5)  ->  Storage account

This matters for compliance regimes that forbid data crossing public networks, for removing the public attack surface of your data services entirely, and for the routing consistency of staying on Azure's own network.

Configure private network access for a web app covers the endpoint and the DNS behaviour that goes with it, which is the part people forget.

The complementary direction, letting an App Service reach into your VNet, is VNet integration. Inbound private access and outbound VNet access are different features and are regularly confused.

Load balancing, and picking the right one

There are four services and choosing wrongly is common.

The short decision: HTTP traffic in one region goes to Application Gateway, HTTP traffic across regions goes to Front Door, anything TCP or UDP or purely internal goes to Load Balancer.

Deploy an internal load balancer with a backend pool to see the L4 model.

Then do the public equivalent with health probes and NAT rules, where health probe configuration becomes the thing that decides whether failover actually works.

Connecting to on premises

Three options, in increasing order of commitment.

Site to site VPN runs over the internet, is quick to stand up, and is adequate for the large majority of hybrid scenarios. Start here.

Point to site VPN connects individual machines rather than networks, which suits remote access to Azure resources rather than site interconnect.

ExpressRoute is a dedicated circuit with predictable latency and much higher bandwidth ceilings, at a cost that reflects that. It is the right answer for high throughput, strict latency requirements, or regulations that forbid internet traversal. It is an expensive answer to a problem a VPN would have solved.

Pricing across all three varies enough by region, tier and bandwidth that any figure here would mislead. Model it in the calculator against your actual requirement.

Before production

• Address spaces do not overlap with on premises or with any VNet you might peer
• Subnets separated by function
• NSGs on every subnet with explicit rules rather than reliance on defaults
• No management ports open to the internet, Bastion instead
• Private endpoints on PaaS services holding anything sensitive
• DNS resolves correctly across peerings and hybrid links
• Network Watcher enabled, including flow logs, before you need them

Networking on AZ-104

Networking carries roughly 15 to 20 percent of the exam and is consistently the domain where candidates score worst. It covers VNet configuration, NSG rules, peering, load balancing, DNS and hybrid connectivity.

If your practice breakdown shows networking under 70, work the labs above before booking. It is also the domain where lab time converts to score fastest, because the questions are about behaviour rather than recall.

For the full study plan, see how to use practice exams to pass AZ-104.