I'm building a small Azure environment from scratch with two domain controllers and a few application servers. I initially planned to put the domain controllers in a hub VNet and create a separate spoke for each application or group of applications.
However, we won't initially have an Azure Firewall, NVA, or other central routing device. Since VNet peering is non-transitive, application spokes that need to communicate with one another would require direct peering. That seems like it could eventually turn into a full mesh with NSGs everywhere, effectively recreating a single VNet through a much more complicated design.
For an environment this small, would it be more sensible to use one VNet with separate subnets for domain controllers, applications, and management, then control traffic with subnet-level NSGs? I'd like to understand the practical reasons to choose hub-and-spoke rather than adopting it simply because it is a common Azure pattern.
Does hub-and-spoke become worthwhile mainly when there are separate production and development environments, multiple teams or subscriptions, centralized management requirements, hybrid connectivity, or shared security services? I also expect this environment to remain small for quite a while, although I'd like to preserve the option to expand later.
3 Answers
There is an argument for deploying the larger pattern early because reorganizing Azure networking later can be disruptive. Moving workloads between VNets is not as simple as changing a subnet, and it may involve downtime or rebuilding network interfaces and related resources.
However, future-proofing does not mean creating unnecessary spokes today. If you expect the environment to remain a small group of related internal servers, use one VNet with dedicated subnets for domain controllers, applications, management, and possibly private endpoints. Apply NSGs and workload-level controls based on the actual traffic requirements.
If the environment later grows into multiple applications, subscriptions, teams, or isolated production and development environments, you can introduce a hub and add spokes at that point. The key is to reserve a sensible IP range and avoid treating the current simple design as a permanent limitation.
Your concern about creating a mesh is valid. VNet peering is non-transitive, so traffic cannot automatically travel from one spoke through the hub to another spoke. If spokes need to communicate and there is no routing appliance or managed connectivity service in the hub, you may end up adding direct peerings and managing increasingly complex rules.
A hub becomes much more useful when it contains something that centralizes connectivity or inspection, such as Azure Firewall, an NVA, VPN or ExpressRoute gateways, or another routing solution. Without one of those services, the hub can become mostly an empty network that adds complexity without solving a real problem.
Production and development isolation, separate administrative ownership, hybrid connectivity, and stronger workload boundaries are all valid reasons to use separate VNets. They are not requirements for every small Azure environment, though.
Hub-and-spoke is mainly useful when the hub provides shared services or a clear organizational boundary. Common examples include Azure Firewall or another NVA, VPN or ExpressRoute connectivity, centralized internet egress, Bastion, shared DNS, or networking managed separately from application workloads.
It also helps when you have multiple subscriptions, teams, environments, or applications that need independent ownership and lifecycle management. A new workload can be added as a spoke without changing the existing workloads, and it can later be removed without disturbing the core environment.
That said, a spoke should normally represent a workload, environment, security boundary, or ownership boundary—not an individual VM. Creating one spoke per application server would probably be excessive.
For a small deployment with only a few closely related servers and no central routing or inspection service, one VNet with separate subnets and carefully designed NSGs is perfectly reasonable. Just plan the address space carefully so additional VNets can be introduced later if the requirements change.
That helps clarify the distinction. I was thinking of the hub as a traditional core or transit network, but without a firewall, NVA, or similar service it doesn’t really provide much routing value. A single VNet now, with enough IP space reserved for future expansion, may be the more sensible starting point.