Transit Hub Topology

Connecting n private networks pair by pair needs n(n-1)/2 connections. Ten networks is 45; forty is 780, and the forty-first adds forty more. Each connection is an object with route-table entries on both sides, so the configuration surface grows quadratically while the capability stays flat.

The binding limit is not a quota, it is comprehension. At 780 peerings nobody can answer "what can reach the payments subnet", which means no segmentation claim can be evidenced and no rule can safely be deleted. A transit hub replaces those objects with one attachment per network and one place where reachability is described.

The trade is immediate and important: peering is non-transitive, so two networks can reach each other only if explicitly connected. A hub is transitive by nature, so a permissive route table silently creates reachability that never existed before.

Why it matters

Network topology is among the hardest things to change once teams depend on it, and a mesh degrades exactly as the organisation grows. Each new team or account is a project, and the growth is in the wrong direction.

Second, the hub is where segmentation becomes expressible. Route tables per attachment, with explicit propagation, allow statements like "spoke A reaches shared services and nothing else" to be read from configuration rather than inferred from 780 objects. That is the difference between a design and an accumulation.

Third, the hub is a cost and failure concentration. Attachments and per-gigabyte transit charges replace free-after-creation peerings, and a hub problem affects every path rather than one pair. Both properties are acceptable, and both must be chosen deliberately rather than discovered.

Implementation patterns

• One attachment per network, with its own route table, and propagation configured explicitly rather than by default.
• Mirror the existing reachability graph first, gaps included, when migrating. Reproducing today's deliberate isolation keeps the migration separate from a segmentation redesign, which is the most common way these projects fail.
• Migrate pair by pair, one route at a time, with a pause to watch flow logs between the two sides. Rollback is re-pointing a single route.
• Expect asymmetric routing during cutover - one side on the hub, the other still peered - and know the symptom: connections that establish and then hang, because a stateful device sees one direction.
• Leave old peerings in place and unused until flow logs show zero bytes for at least 30 days and through a month-end; deleting them is the only irreversible step.
• Segment with multiple route tables rather than one permissive table: a shared-services table, a production table, a sandbox table with no path to anything else.
• Handle overlapping address ranges last and separately. One hub route table has one entry per prefix, so two estates on 10.0.0.0/16 cannot both be routed natively. Re-address one, keep one on a translation path, or isolate it behind private endpoints.

Industry example

Every major cloud has shipped a managed transit construct since around 2018, and the published guidance from each follows the same arc: peer for a handful of networks, adopt a hub when the pair count grows, and use separate route tables per environment for segmentation. Large-enterprise landing-zone reference architectures assume the hub from day one for exactly the reason above - a 40-account estate reached by mesh is 780 objects, and no governance process survives that.

Failure scenarios

• Accidental transitivity. Two spokes attached with permissive tables can now reach each other. A connectivity migration has become a security change, unreviewed.
• Asymmetric routing mid-migration, producing connections that hang rather than fail, which is the hardest symptom to attribute.
• Hub as a single failure domain. A misapplied route change or a hub-level limit affects every path, where a bad peering affected one pair.
• Cost surprise. Per-attachment hourly charges plus per-gigabyte processing turn previously free east-west traffic into a monthly line item that nobody owns.
• The overlapping estate deferred into the critical path. Re-addressing a live /16 means touching hard-coded addresses, partner allowlists and certificates with IP subject alternative names - months, not weeks, and it will dominate the schedule if it is not isolated.
• Peerings deleted too early, and a quarterly batch job that used one of those paths fails six weeks later.

Trade-offs

When not to use it

Below roughly eight networks with stable pairs, the mesh is 28 objects and understandable, and the hub is a bill plus a failure domain for no benefit.

Where two networks exchange very high volumes continuously, a direct peering alongside the hub is often right: per-gigabyte transit charges on a petabyte-scale replication path can exceed everything else in the network budget, and peering that one pair directly is a legitimate exception.

And where the requirement is partner or third-party access rather than internal connectivity, neither topology is the answer - do not join address spaces with organisations you do not operate; publish a private endpoint or an authenticated API instead.

Interview question

Q: You inherit 40 cloud accounts connected by full-mesh peering, two of which have overlapping address ranges. Leadership wants a transit hub and zero downtime. How do you sequence it, and what do you refuse to do in the same change?

What a strong answer covers: the n(n-1)/2 arithmetic as the reason, and comprehension rather than quota as the binding limit · attach-then-reroute sequencing with per-pair cutover and flow-log verification · mirroring existing reachability gaps and refusing to redesign segmentation in the same change · naming asymmetric routing as the live risk and its hang-rather-than-fail symptom · deleting peerings only after a full business cycle of zero bytes, as the single irreversible step · deferring the overlapping estate as a separate project and saying why it will dominate the schedule · and the new costs and failure domain accepted explicitly.

Quick check

Quiz: What does a transit hub give you that a mesh cannot, beyond fewer objects? One place where reachability is described, so segmentation can be evidenced from configuration rather than inferred from hundreds of peerings - and onboarding a network becomes an attachment rather than a project.

Flashcard: Which property of a hub is a security change disguised as a connectivity change? - Transitivity: peering is non-transitive, so attaching two spokes with permissive route tables creates paths between networks that could never reach each other before.