Virtual networks, subnets, peering and Azure DNS

A virtual network is your private address space in Azure

A virtual network is a slice of private address space that you define and Azure routes inside. It belongs to one region and one subscription, resources placed in it get private IP addresses out of its ranges, and by default everything inside it can reach everything else. The address space is the one decision here that is genuinely hard to undo, because two networks with overlapping ranges can never be peered — so the ranges an organisation will use are worth agreeing before anybody deploys anything.

Subnets segment it, and Azure keeps five addresses in each

A subnet is a subdivision of the network's address space. Its range must fall inside that space and must not overlap another subnet in the same network, because two claimants for one address leave routing with no correct answer. Subnets exist so that segments can be treated differently: a network security group attached here and not there, a route table sending this segment somewhere specific, tiers placed apart so that reaching one does not mean reaching the next.

The arithmetic trap is worth memorising because questions do the sum for you and offer the wrong total. Azure reserves five addresses in every subnet — the first four and the last — so a /29 with eight addresses yields three you can use, not eight. Size subnets with that in mind, and remember that a subnet belongs to exactly one virtual network: joining networks together is what peering and gateways are for.

Peering: Azure to Azure, without a gateway

Peering connects two virtual networks directly across the Microsoft backbone. Resources address each other by private IP as though they shared one network, no gateway is deployed at either end, and it works between subscriptions and across regions — the cross-region case is called global peering, and it costs you distance in latency but never puts the traffic on the public internet. The single shortest way to hold the whole subject: Azure to Azure is peering, Azure to anywhere else is a gateway.

Two things peering withholds, and both are asked directly. It is not transitive, so if A is peered with B and B with C, A still cannot reach C — which is the standard surprise in hub-and-spoke designs, where spoke-to-spoke traffic needs a gateway or a network virtual appliance in the hub plus routing that sends it there. And it does not touch your security rules: each subnet keeps its own network security group, so peering provides the path while whether traffic is allowed along it stays an explicit decision at each end.

Azure DNS hosts zones; it does not sell names

Azure DNS answers name lookups for zones you host in it. A public zone answers the internet, and you connect it to a name you already own by delegation: you change the name server records at your registrar to point at Azure, while the registration itself stays exactly where it is. A private zone answers lookups inside the virtual networks you link it to, which is how resources reach each other by name without anything being published externally.

What Azure DNS does not do is register the name. Buying a domain is a separate transaction with a registrar or a domain product, and an option that describes Azure claiming a name — or worse, deleting the registration so Azure can take it — is describing something that would release the name to whoever wanted it. The reason to move a zone into Azure is that records become resources like any other, with role-based access control, activity logs and deployment templates covering them.