The network is the part of the foundation you cannot quietly redo later. Management groups can be restructured with effort, policies can be rewritten, access can be re-granted, but an address plan is close to permanent the moment workloads depend on it, and a topology chosen badly is unwound only by moving live resources between virtual networks. So the network gets more forethought than anything else in this series, and the guiding instinct is to plan for where the organization is going rather than for the handful of machines it has today. Everything here is about making the expensive decisions once.
Hub and spoke, even when it is small
The topology is hub and spoke, and it is worth adopting even when the whole estate is one workload, because the shape is what lets the estate grow without redesign. The hub is a virtual network that holds everything shared: the gateway that terminates the connection to on-premises, the egress control point, the private DNS resolver, and reserved space for services that centralize by nature. The spokes are virtual networks that hold workloads, one per environment or per isolation boundary, each peered to the hub and none peered to each other. The hub belongs to the platform, specifically the Connectivity subscription the governance hierarchy already has a place for. The spokes belong to the landing zones. That division is not bureaucratic. It is what keeps the team that runs a workload from having to touch shared connectivity to do their job, and it is what keeps shared connectivity stable while workloads come and go around it.
The address plan is the decision you make once
Before a single virtual network exists, you allocate address space for the whole future estate, not for the first spoke. The discovery pass already produced the register of everything in use on both sides, so you choose a large private block that overlaps nothing. For Northfork that is 10.40.0.0/16 as the primary region, deliberately clear of the on-premises 172.16.0.0/16 and the accidental legacy network at 10.0.0.0/24. From that block you carve the hub a small, stable range, give each spoke its own range, and, crucially, leave large gaps between allocations rather than packing them tightly. The gaps are the point. A spoke that needs to grow, a new environment, a workload that wants its own network, all of these should fit into space you already reserved rather than forcing you to bolt on a disconnected range later. You also reserve a second, non-overlapping block for a disaster-recovery region, 10.50.0.0/16 here, even though nothing will deploy there for a long time, because the day you need a second region is not the day you want to discover your addressing cannot accommodate one. Addresses are free. Overlap is expensive. Plan generously.
Two connectivity problems, kept separate
The most common conceptual error in small-estate network design is treating connectivity as one problem when it is two, and the two age in opposite directions. The first is infrastructure connectivity: how the Azure networks reach on-premises and each other, server to server. That is the gateway in the hub, the site-to-site VPN or, at larger scale, ExpressRoute, and the peering between hub and spokes. The second is client connectivity: how users reach the resources they need. In the early phases those two ride the same VPN, because users are in the office and resources are reached through it. But as the estate tips toward Azure, the infrastructure link and the client link diverge, and continuing to backhaul every user through a tunnel to a shrinking datacenter becomes the thing that no longer makes sense. Designing the hub so that infrastructure connectivity and client connectivity are distinct concerns, rather than one VPN doing both jobs, is what lets client access move to cloud-delivered connectivity later without touching the server-to-server plumbing. You do not have to build that separation on day one. You have to design so it is not a rebuild when the time comes.
Name resolution, and the trap that waits months to spring
Private DNS is where an otherwise sound network quietly fails if it was not planned. Once workloads use private endpoints, the names of Azure services have to resolve to private addresses, and that means a private DNS resolver in the hub, private DNS zones for the relevant services, and, on the on-premises side, conditional forwarders that point the right Azure namespaces at that resolver. The discovery pass exists partly to catch the trap that breaks this: an existing broad forwarder or stub zone on an on-premises DNS server for a Microsoft domain will intercept these queries before your specific rules see them, and a private endpoint will resolve to a public address with no error anywhere, months after go-live. This is the single hardest problem to diagnose after the fact, which is exactly why it is found and cleared during discovery rather than debugged in production. The doctrine point here is simply that name resolution is a first-class part of the network design, not an afterthought, and the resolver has a reserved place in the hub from the start.
Egress, Bastion, and visibility: reserve first, deploy on need
Three services follow the same discipline of reserving their place without necessarily spending on them immediately. Egress control is a real decision rather than a default: Azure Firewall is the managed answer and the right one when the traffic and the compliance requirements justify it, but at the smallest scale routing egress through a smaller network appliance, or through the existing on-premises edge during the early phases, is a legitimate choice, and the article that builds this presents the decision rather than picking for you. Bastion has a reserved subnet in the hub from day one because the subnet cannot be added conveniently later, but you do not have to run a production Bastion to have reserved its space; a Developer-tier Bastion covers non-production access, and the production tier arrives when the need is real. Visibility follows the same logic, with one correction that matters in 2026: the old network security group flow logs are being retired and can no longer be created for new builds, so traffic visibility is designed on virtual network flow logs from the outset, not on the legacy mechanism a lot of older guidance still describes.
One last property of the topology is worth stating because it surprises people who expect networks to behave like switches. Peering is not transitive. A spoke reaches the hub, and the hub reaches on-premises, but two spokes do not reach each other simply because both are peered to the hub. If Production and Non-Production must communicate, that traffic is routed deliberately through the hub, typically through the egress control point, which is a feature rather than a limitation: it means cross-environment traffic is a decision you make and can inspect, not an accident of topology. A reader who has followed this article can now allocate their own address space with room to grow, place a hub and its spokes correctly, say which connectivity concern each link serves, and know where name resolution and egress live before deploying anything. The two build sheets that follow take this design and stand up the hub and its connectivity, then wire name resolution end to end including the on-premises side.
Azure Landing Zones
‹ Previous: [LZ 3.1] Standing Up the Governance Backbone
Next: [LZ 4.1] Standing Up the Hub and Connectivity ›
