Hub-and-Spoke Network Topology: Azure and AWS Diagrams

The first cloud network is easy. By the tenth, there is a web of peering connections, three VPN tunnels to the office configured slightly differently, a firewall copied into every network, and nobody can say with confidence what can reach what. Hub-and-spoke is the standard way out: one central network for shared connectivity and inspection, and workloads in isolated spokes that connect only through it.

This post explains the topology and then builds it twice, with diagrams: in Azure with a hub virtual network and peering, and in AWS with Transit Gateway. It covers routing and segmentation, traffic inspection, centralized egress, the costs that surprise teams, and when a managed hub is the better choice.

Why a mesh stops working

Connecting every network directly to every other needs n(n−1)/2 connections. Ten networks need 45; fifty need 1,225, each with its own routes and security rules. Peering is also non-transitive in both clouds: if A peers with B and B peers with C, A still cannot reach C through B. A hub-and-spoke design needs one connection per spoke, and the hub becomes the single place where routing and security policy live.

What belongs in the hub

Workloads do not belong in the hub. Spokes hold applications, usually one per application, team or environment, so a mistake in one cannot spread to others.

Hub-and-spoke in Azure

Microsoft's hub-spoke reference architecture puts Azure Firewall, a VPN or ExpressRoute gateway and Azure Bastion in a hub virtual network, each in its own dedicated subnet. Azure Firewall needs a subnet of at least /26. Spokes connect to the hub with virtual network peering, which Microsoft describes as nontransitive: peered networks talk to each other, not through each other.

That has two consequences:

• Gateway sharing is explicit. The hub peering allows gateway transit and each spoke uses the remote gateway, so spokes reach on-premises through the hub's gateway.
• Spoke-to-spoke traffic needs routes. User-defined routes in each spoke send traffic for other spokes, and usually the default route, to the firewall's private IP. The firewall forwards what policy allows. Alternatively, Azure Virtual Network Manager can manage peerings and connected groups at scale, and direct peering between two spokes remains an option for special cases.

For a Microsoft-managed hub, Azure Virtual WAN provides hubs with built-in routing, gateways and optional firewalls, in exchange for less control over the details.

Hub-and-spoke in AWS

In AWS the hub is usually a Transit Gateway, a regional router that VPCs, VPN connections and Direct Connect gateways attach to:

• Spokes are VPC attachments. A Transit Gateway supports 5,000 attachments by default, according to the Transit Gateway quotas, so it scales far beyond peering meshes.
• Segmentation comes from Transit Gateway route tables. Production attachments associate with one route table and development with another, so the two never learn each other's routes, while both can reach a shared-services VPC.
• Inspection happens in a dedicated inspection VPC running AWS Network Firewall, or third-party appliances behind a Gateway Load Balancer. Spoke route tables point at the Transit Gateway, and Transit Gateway routes send traffic through the inspection VPC.
• Appliance mode on the inspection VPC's attachment keeps both directions of a flow in the same Availability Zone, which stateful firewalls require.
• Centralized egress: an egress VPC with NAT gateways serves all spokes, instead of NAT gateways in every VPC.

For global networks spanning many regions, AWS Cloud WAN plays the role Virtual WAN plays in Azure: a managed core network with policy-based segments.

The two clouds side by side

Routing, segmentation and symmetry

Three rules keep a hub-and-spoke network predictable:

1. Default routes point to the hub. Spokes send everything that is not local to the hub, so nothing bypasses inspection by accident.
2. Segments are explicit. Decide which spokes may talk to which: production and development usually may not, shared services usually may be reached from everywhere, and on-premises access goes through the firewall.
3. Return traffic must take the same path. A stateful firewall drops replies it did not see leave. Asymmetric routes are the most common cause of "the firewall rule is there but nothing works".

Write the address plan down before the first spoke exists. Overlapping CIDR ranges between spokes, or with on-premises, cannot be routed through a hub and are painful to fix later.

What it costs

Every byte that crosses the hub is billed somewhere. In AWS, at the time of writing (November 2026), Transit Gateway pricing in US East (N. Virginia) is $0.05 per attachment per hour and $0.02 per GB of data processed. Ten spoke attachments cost about 10 × $0.05 × 730 hours, roughly $365 a month, before any traffic. Ten TB of spoke-to-spoke traffic adds about 10,240 GB × $0.02, roughly $205 in processing, plus the firewall's own processing charges. In Azure, peered traffic is charged per GB at both ends of the peering, and Azure Firewall adds its own processing charge.

The usual optimization is targeted: keep the hub for policy, and add direct peering for a specific pair of spokes that exchange very large volumes and do not need inspection.

When not to use hub-and-spoke

• Two or three networks do not need a hub; direct peering is simpler.
• Latency-critical east-west traffic pays an extra hop and a firewall on every packet. Measure before routing a chatty service pair through inspection.
• Huge internal volumes can make per-GB processing the largest network cost. Direct peering for those flows is often justified.
• Very large, multi-region estates may be better served by a managed hub, Virtual WAN or Cloud WAN, than by hand-built route tables.

The hub-and-spoke diagram

How to read it:

• On-premises at the top connects once to each cloud: to the Azure hub's gateway and to the AWS Transit Gateway.
• The Azure frame shows the hub virtual network with its firewall and VPN gateway, and two spokes peered to it. Spoke-to-spoke traffic goes through the firewall.
• The AWS frame shows the Transit Gateway in the middle, the inspection VPC with its firewall, and two spoke VPCs attached to it.
• Edge labels name the connection type: peering, attachment, VPN or private circuit.
• The Markdown block lists the routing rules and the cost figures above.

Drawing network topologies that hold up in review

• Write CIDR ranges on every network. Overlaps are the first thing a reviewer checks.
• Draw the firewall where traffic actually goes, and show the default route pointing at it.
• Label each connection by type. Peering, attachment and VPN behave differently and cost differently.
• Keep one diagram per region. Multi-region networks drawn on one canvas usually hide the inter-region links that matter.

For the inside of a single network, see the AWS VPC diagram. The network topology diagram covers physical and logical topologies in general, and the zero trust architecture diagram explains why network position alone should not grant access. Multi-region designs are covered in the AWS multi-region architecture diagram.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Core Box for the on-premises network at the top.
3. Add a Core Frame for Azure. Inside it, add a VPC node from the Network pack for the hub virtual network with a Firewall and a Device node for the VPN gateway inside, and two more VPC nodes for the spokes, each with its CIDR.
4. Add a Core Frame for AWS. Inside it, add a Router from the Network pack for the Transit Gateway, a VPC node for the inspection VPC with a Firewall inside, and two VPC nodes for the spokes.
5. Connect on-premises to the Azure gateway and to the Transit Gateway, the spokes to their hubs, and label every edge with its connection type.
6. Add a Markdown block from the Core pack with the routing rules and costs.

The example uses 14 diagram nodes, within the Free plan.

FAQ

What is a hub-and-spoke network topology? A design where one central network, the hub, holds shared connectivity, security and services, and every workload network, a spoke, connects only to the hub. Traffic between spokes and to on-premises passes through the hub.

Is virtual network peering transitive? No, in both Azure and AWS. Two spokes peered with the same hub cannot reach each other through it unless routes send their traffic to a firewall or router in the hub.

What is the difference between Transit Gateway and VPC peering? VPC peering connects two VPCs directly and is non-transitive. Transit Gateway is a regional router that many VPCs and on-premises connections attach to, with route tables for segmentation.

Should I use Azure Virtual WAN instead of a hub virtual network? Virtual WAN suits large or multi-region estates that want Microsoft to manage hub routing and gateways. A self-managed hub gives more control and is common for a handful of spokes in one or two regions.

What does hub-and-spoke cost? Hub connections and processed traffic are billed per hour and per GB, plus firewall processing. In AWS at the time of writing, a Transit Gateway attachment costs $0.05 per hour and data processing $0.02 per GB in US East.

Start free — one seat, no credit card.