I'm building a small Azure environment from scratch with two domain controllers and a few application servers. I initially considered putting the domain controllers in a hub VNet and placing each application or application group in its own spoke, but there won't be an Azure Firewall or NVA in the hub.
Since Azure VNet peering is non-transitive, application spokes that need to communicate with one another—or reach shared services—could require additional direct peerings. That seems likely to grow into a full-mesh design with NSGs everywhere, which feels like a lot of complexity just to recreate one shared network.
For an environment this small, would it be more appropriate to use one VNet with separate subnets for domain controllers, applications, and management, then control traffic with subnet-level NSGs? When does hub-and-spoke provide enough value to justify the extra routing and management complexity—for example, separate production and development environments, independent administration, centralized security, or future growth? I'd like to understand the design reasons rather than adopt the pattern automatically.
3 Answers
Think of a single VNet with subnets as the simpler option when the workloads share administration and trust boundaries. Use NSGs to restrict application-to-domain-controller traffic, management access, and any other flows that should not be open by default.
Separate VNets become valuable when you need stronger isolation, independent ownership, separate lifecycles, hybrid connectivity, or centralized network services. Production and development are common examples, but they are not mandatory. The best starting point is the simplest design that satisfies the actual security and routing requirements, rather than adopting hub-and-spoke purely as a standard pattern.
A hub-and-spoke layout can be worth adopting early because Azure networking is not always easy to rearrange later. If the environment grows into multiple applications, subscriptions, or isolated production and development networks, having a network foundation already in place can avoid a disruptive redesign.
The hub should generally contain shared connectivity and networking components rather than ordinary workloads. Domain controllers can live in a dedicated spoke or workload VNet instead of the hub. If applications in separate spokes need to reach the domain controllers, you need an appropriate routing design—such as a firewall, NVA, Virtual WAN, or deliberately configured peerings.
That said, future growth alone is not a reason to accept unnecessary complexity. If the small-server model is expected to last, a single VNet with subnet-level controls may be the better operational choice.
Hub-and-spoke is mainly useful when the hub provides shared networking services or when you need clear boundaries between independently managed environments. Typical hub services include Azure Firewall or an NVA, VPN or ExpressRoute connectivity, centralized outbound traffic inspection, Bastion, shared DNS, and routing between subscriptions or workload networks.
Without a routing or security appliance in the hub, the non-transitive peering limitation is real. Directly peering spokes can eventually create the mesh you were trying to avoid. Also, a spoke usually represents a workload, environment, security boundary, subscription, or ownership boundary—not an individual VM.
For a small deployment with two domain controllers and a few related application servers, one VNet with carefully planned subnets and NSGs is completely reasonable. Hub-and-spoke becomes more compelling when you add separate teams or subscriptions, production-versus-development isolation, hybrid connectivity, centralized inspection, or enough growth that one VNet becomes difficult to manage. Plan the address space carefully so additional VNets can be introduced later if needed.
That helps clarify the distinction. I was treating every application group as a spoke, but it makes more sense to use a spoke for a meaningful workload or administrative boundary. Since this environment will probably remain small and there is no central firewall or router today, I’m leaning toward one VNet with separate subnets and a design that leaves room for future expansion.