CH03-05: VNet Peering and Hub-Spoke Design

Goal

The previous sections explained network placement, segmentation, and routing. This section explains how virtual networks connect to each other and why many Azure environments use hub-spoke design.

The goal is to understand connected-but-separated networks. A strong Azure design often needs workload networks to communicate with shared services without turning the environment into one flat network.

The Short Version

VNet peering connects virtual networks using private Azure connectivity.

Hub-spoke design uses that connectivity to centralize shared network services while keeping workload networks separated.

The durable idea is:

VNet peering connects private network boundaries, but architecture still decides which traffic should be allowed, inspected, and owned.

Peering creates a possible path. It does not automatically mean every workload should be able to talk to every other workload.

What VNet Peering Does

VNet peering connects two Azure virtual networks so resources in those networks can communicate privately, subject to routing and security rules.

For example:

VNet A: finance-prod-vnet
        |
        | VNet peering
        |
VNet B: shared-connectivity-vnet

After peering, resources may be able to communicate using private IP addresses if the routes and security controls allow it.

Peering is useful because Azure environments often have multiple VNets. Workloads may be separated by team, application, environment, region, risk, or subscription. Shared network services may live in a platform or connectivity subscription. Peering lets those boundaries connect without putting everything into one VNet.

Peering Is Not Merging

A common misunderstanding is to treat peering as if it turns two VNets into one network.

It does not.

Each VNet keeps its own:

Address space.
Subnets.
Network security groups.
Route tables.
Ownership model.
Resource placement.
Operational responsibilities.

This distinction matters. Peering gives networks a way to communicate. It does not remove the need for segmentation, routing, DNS, firewall rules, access control, monitoring, or ownership clarity.

A useful way to say it is:

Peering creates reachability. Architecture decides whether that reachability should be used.

Why Not One Giant VNet?

For a very small environment, one VNet may be enough. But in larger environments, one giant VNet can create problems:

Too many unrelated workloads share one network boundary.
Ownership becomes unclear.
Production and non-production may become too close.
Security rules become broad or complicated.
Routing changes can affect many teams.
Troubleshooting becomes harder.
Address planning becomes less flexible.

Separate VNets help express real boundaries. A finance production workload, a retail non-production workload, and a shared connectivity platform may have different owners, risk levels, routing needs, and governance requirements.

The goal is not separation for its own sake. The goal is a network model that matches the operating model.

Hub-Spoke Design

Hub-spoke design is a common Azure network pattern.

A hub VNet holds shared network services. Spoke VNets hold workloads.

                  Spoke VNet: Finance Prod
                         |
                         |
Spoke VNet: Retail Prod -- Hub VNet: Shared Connectivity -- On-premises
                         |
                         |
                  Spoke VNet: Analytics Non-Prod

The hub may contain shared network components such as:

Hybrid gateways for VPN or ExpressRoute.
Azure Firewall or network virtual appliances.
DNS forwarding or resolver services.
Shared inspection paths.
Bastion or controlled management access.
Other network platform services.

Spokes usually contain workload resources, such as application subnets, private endpoint subnets, and workload-specific network controls.

The hub is commonly owned by a platform or network team. Spokes are commonly owned by workload, application, product, or business-unit teams within the guardrails of the landing zone.

This connects directly to Chapter 2. Governance separated platform services from workload subscriptions. Hub-spoke networking gives that separation a network shape.

How Traffic Flows in Hub-Spoke Design

In a simple hub-spoke model, a spoke may use the hub for shared paths:

Spoke workload subnet
        |
        | VNet peering
        v
Hub VNet
        |
        +-- Firewall or inspection
        +-- VPN or ExpressRoute gateway
        +-- DNS services
        +-- Shared platform services

A workload spoke might send traffic to the hub when it needs to:

Reach on-premises systems.
Use central internet egress inspection.
Resolve private or hybrid names.
Reach shared platform services.
Use a central management path.

But not every spoke-to-spoke path should exist automatically. For example, finance production and analytics non-production may both connect to the hub, but that does not mean they should directly communicate with each other.

This is where VNet peering, route tables, NSGs, firewalls, and DNS all work together. The topology gives possible paths. The controls decide which paths are allowed and how they are operated.

Transitive Connectivity Caution

When learning hub-spoke design, you may hear that VNet peering is not transitive by default.

In plain language, this means that if Spoke A is peered to the Hub, and the Hub is peered to Spoke B, Spoke A does not automatically get direct network connectivity to Spoke B just because both are connected to the Hub.

That is usually a good thing. It prevents accidental flat networking. If spoke-to-spoke communication is needed, it should be designed intentionally through routing, firewall inspection, direct peering, or another approved pattern.

You do not need to memorize every peering setting yet. Remember the architecture lesson: connected to the same hub does not mean free communication everywhere.

Example: Shared Connectivity Without Shared Ownership

Imagine an enterprise with three workload teams:

Finance production.
Retail production.
Analytics non-production.

All three need access to on-premises systems. All three need outbound traffic inspection. But they should not share one workload VNet because they have different owners, environments, risks, and cost models.

A hub-spoke model can support this:

Connectivity subscription
  |
  +-- Hub VNet
      +-- ExpressRoute or VPN gateway
      +-- Azure Firewall
      +-- DNS resolver or forwarding pattern

Finance production subscription
  |
  +-- Finance prod spoke VNet

Retail production subscription
  |
  +-- Retail prod spoke VNet

Analytics non-production subscription
  |
  +-- Analytics non-prod spoke VNet

The platform team owns the hub and shared connectivity. Workload teams own their application resources in spokes. Policies and access controls from Chapter 2 can reinforce those boundaries.

This gives the organization a shared network foundation without asking every workload team to build hybrid connectivity from scratch.

Trade-Offs

Hub-spoke design is powerful, but it is not free.

Decision	Benefit	Trade-Off
Central hub	Shared connectivity and inspection are consistent.	The hub becomes a critical dependency.
Separate spokes	Workload ownership and blast radius are clearer.	More networks, peerings, and routes to operate.
Central firewall	Better visibility and policy consistency.	Cost, latency, and scaling must be planned.
Shared DNS pattern	Private and hybrid name resolution can be standardized.	DNS mistakes can affect many workloads.
Platform-owned connectivity	Workload teams do not rebuild foundations.	Platform team can become a bottleneck if processes are unclear.

A strong design makes these trade-offs explicit. Hub-spoke is an operating model, not only a diagram.

Common Early Mistakes

Peering every VNet to every other VNet without a clear model. A mesh of peerings can become hard to reason about and operate.
Assuming peering solves routing, DNS, inspection, and security. Peering is connectivity. The rest still needs design.
Putting workload-specific services in the hub because it is convenient. The hub should not become a dumping ground.
Forgetting ownership. Platform teams and workload teams need clear responsibilities.
Treating the hub as a magic security boundary. The hub must be configured, monitored, secured, and scaled.
Ignoring cost and limits. Centralized inspection and large peering models have operational and financial impact.

If Someone Asks You

If someone asks, "Why do Azure architectures often use hub-spoke networking?" a clear answer is:

Hub-spoke networking lets an organization centralize shared network services such as hybrid connectivity, firewall inspection, DNS, and management paths in a hub VNet, while keeping workload environments in separate spoke VNets. VNet peering connects the hub and spokes privately. This supports shared platform ownership and workload separation, but routing, security rules, DNS, monitoring, and ownership still need to be designed intentionally.

This answer shows that hub-spoke is both a topology and an operating model.

What You Should Remember

VNet peering gives network boundaries a private connection. Hub-spoke design gives those connections a structure.

The most important idea is this:

Hub-spoke design centralizes shared paths without turning every workload into one network.

Use the hub for shared network responsibilities. Use spokes for workload boundaries. Then use routing, NSGs, firewalls, DNS, and governance to make the intended paths clear.

Questions to Check Your Understanding

What does VNet peering connect?
Why might separate workload VNets be better than one large VNet?
What kinds of services commonly live in a hub VNet?
Why is peering not the same as broad permission to communicate?
How does hub-spoke networking support landing zones?