AZ-900 · Describe Azure Architecture and Services · Updated August 7, 2026
Azure Virtual Networks, Subnets, and DNS Fundamentals
An Azure virtual network (VNet) is a logically isolated network within Azure where resources communicate privately, and optionally reach the internet or an on-premises network. Subnets divide that VNet’s address space into smaller, independently securable segments, network security groups filter the traffic flowing in and out of them, and Azure DNS (public or private) handles name resolution for everything running inside.
The virtual network: your private space in Azure
A VNet is the fundamental building block for private networking in Azure. It doesn’t automatically patch operating systems, host web applications, or orchestrate containers — those are the jobs of VMs, App Service, and services like Azure Kubernetes Service respectively. What a VNet does is give resources a private address space to communicate over, one you control and can optionally connect outward: to the public internet, to another VNet through peering, or to an on-premises datacenter through a VPN Gateway or ExpressRoute. Resources inside a VNet still live inside a resource group for management purposes, a separate organizational layer covered in Azure Resource Groups: What They Are and How to Use Them. Those hybrid connectivity options are worth understanding in their own right — see Azure’s hybrid connectivity services for the details.
VNets are scoped to a single Azure region, which is one reason network design decisions are often made alongside region and resiliency planning; if you haven’t already, it’s worth reviewing how Azure regions and region pairs work before finalizing a network layout.
Why subnets exist — and how their addresses are counted
A subnet segments a VNet’s address space into smaller ranges, letting you organize resources into groups and apply different security rules to each group. The classic exam scenario is a three-tier application: web servers in one subnet, application servers in another, database servers in a third, each with its own set of network security rules — subnets are what make that separation possible within a single VNet, distinct from VNet peering, which connects two separate virtual networks together rather than segmenting one.
Subnet sizing follows standard CIDR math, but Azure adds a wrinkle: every subnet reserves five IP addresses for internal use, regardless of size. That’s the network address, the default gateway address, two addresses Azure reserves for mapping its internal DNS, and the broadcast address. A traditional network only reserves two (network and broadcast); Azure reserves three additional addresses beyond that convention. This matters directly for sizing: a /24 subnet has 256 total addresses, but only 251 are usable after Azure’s reservation — close enough to a “roughly 250 usable addresses” requirement that a /24 is the right call, while a /28 (16 total, 11 usable) is far too small for the same requirement.
| Subnet size | Total addresses | Usable addresses (after Azure’s 5 reserved) |
|---|---|---|
| /16 | 65,536 | 65,531 |
| /24 | 256 | 251 |
| /27 | 32 | 27 |
| /28 | 16 | 11 |
| /29 | 8 | 3 (Azure’s smallest supported subnet size) |
Network security groups: filtering traffic in and out
A network security group (NSG) filters inbound and outbound network traffic to and from resources in a virtual network, using allow or deny rules evaluated against source, destination, port, and protocol. An NSG doesn’t encrypt traffic between regions, doesn’t load-balance traffic across VMs, and doesn’t resolve domain names — it’s purely a traffic filter, attachable to a subnet or a network interface, and it’s the mechanism behind “apply different rules to the web, app, and database tiers” scenarios once those tiers are already split into separate subnets. NSGs are one layer of a broader pattern covered in Zero Trust, Defense in Depth, and Microsoft Defender for Cloud, which stacks multiple layers of controls rather than relying on network filtering alone.
Name resolution: Azure DNS vs. Azure Private DNS zones
Azure DNS is a hosting service for DNS domains, providing public name resolution across Microsoft’s global network of name servers — the service you’d use to host a domain’s DNS records the way you’d host them with any DNS registrar, just running on Azure infrastructure. Azure Private DNS zones solve a different problem: name resolution scoped to one or more virtual networks, with records that stay unreachable from the public internet. When a scenario describes VMs inside a VNet needing to resolve each other’s names using records that must not be internet-accessible, Private DNS zones are the answer — public DNS zones are resolvable from the internet by design, the opposite of what’s needed.
Neither service should be confused with Azure Front Door, a global, edge-based entry point that provides load balancing, SSL offload, and DDoS/WAF protection for web applications distributed across regions. Front Door operates at the application delivery edge, not as a DNS hosting or private name-resolution service — a distinction worth keeping straight, since both terms show up in the same networking domain.
How the AZ-900 exam tests this
- A scenario describes a three-tier (or multi-tier) application needing different security rules per tier within one VNet — the answer is subnets, not VNet peering or availability sets.
- A scenario gives a subnet size or a target usable-address count and asks you to pick or verify a CIDR block — remember Azure’s five reserved addresses per subnet before calculating what’s “usable.”
- A scenario describes VMs needing to resolve each other’s names with records that must stay off the public internet — that’s Azure Private DNS zones, not public Azure DNS.
- A scenario asks what filters traffic by source, destination, port, and protocol between resources in a VNet — that’s a network security group, not a load balancer or DNS service.
Quick reference
- A VNet is Azure’s logically isolated private network; it’s scoped to one region and can connect to the internet, other VNets (peering), or on-premises networks.
- Subnets divide a VNet’s address space so resource groups can be organized and secured independently — not the same thing as VNet peering.
- Azure reserves 5 addresses in every subnet (network, gateway, 2 for DNS, broadcast) — a /24 yields 251 usable addresses, a /27 yields 27.
- NSGs filter inbound/outbound traffic using allow/deny rules based on source, destination, port, and protocol.
- Azure DNS hosts public, internet-resolvable domains; Azure Private DNS zones resolve names privately within one or more VNets.
- Azure Front Door provides global edge load balancing and DDoS/WAF protection — a different service from DNS hosting.
Once these fundamentals click, try AZ-900 practice questions that test subnet sizing math and DNS scenario recognition the way the real exam does.