Connecting a handful of VCNs directly works. Connecting many of them in a mesh does not. Hub and spoke routes shared connectivity through a central hub, and it is how OCI estates scale their networking.
An OCI estate usually starts with one virtual cloud network, and one network needs no clever topology. The trouble arrives as the estate grows and you find yourself with many networks, one per workload, per environment or per team, that all need to reach shared services, connect to on premises, and sometimes talk to each other. Connecting them directly, every network to every other, produces a mesh whose complexity grows faster than the number of networks and quickly becomes unmanageable. The answer the industry settled on long ago, and that applies cleanly to OCI, is hub and spoke. This article sets out how to design it.
Hub and spoke puts a central network, the hub, at the middle of the estate, and connects each workload network, a spoke, to that hub rather than to every other spoke. Shared services, external connectivity and security inspection live in the hub, and the spokes reach them through it. The result is a topology whose complexity grows linearly with the number of networks rather than explosively. The sections below explain the pattern, what belongs in the hub, and how to design it well. It builds on the single network patterns in VCN Design Patterns on OCI and the broader foundation in OCI Landing Zone and Architecture: A Complete Guide.
The case for hub and spoke is easiest to see by counting connections. With a handful of networks, connecting each to every other is manageable. But the number of connections in a full mesh grows roughly with the square of the number of networks, so an estate with a dozen networks would need dozens of peerings, each to be configured, secured and maintained. Every new network multiplies the work. Hub and spoke breaks this, because each new spoke connects only to the hub, so adding a network adds one connection rather than many.
| Networks | Full mesh connections | Hub and spoke connections |
|---|---|---|
| 4 | 6 | 4 |
| 8 | 28 | 8 |
| 12 | 66 | 12 |
| 20 | 190 | 20 |
The hub is where shared concerns live, the things every spoke needs but none should duplicate. That typically includes external connectivity, the connection to on premises and to other clouds, so that one well secured path serves the whole estate. It includes shared services such as DNS and directory services. And it often includes a point of security inspection, where traffic between spokes or between spokes and the outside can be examined and filtered centrally. Centralising these in the hub means they are configured, secured and monitored once rather than repeated in every spoke.
Each spoke holds a workload or a group of related workloads, with its own subnets and its own internal segmentation following the patterns in VCN Design Patterns on OCI. Spokes are isolated from each other by default, which is a security benefit, because a compromise in one spoke does not automatically reach another. Where two spokes genuinely need to communicate, that traffic routes through the hub where it can be inspected, rather than through a direct connection that bypasses central control. This default isolation with deliberate, inspected exceptions is much of why the pattern is favoured for security as well as scale.
On OCI the connections between hub and spokes are built with the dynamic routing gateway and local peering, with route tables in each network directing traffic to the hub for anything outside the spoke itself. The address planning matters enormously here, because spokes with overlapping address ranges cannot be cleanly connected, which is why planning a non overlapping address space across the whole estate from the start, as stressed in the VCN patterns article, pays off precisely when you build the hub. An estate that planned its addressing well finds hub and spoke straightforward, and one that did not finds it painful.
One of the strongest reasons to adopt hub and spoke is centralised security. By routing traffic through the hub, you can place inspection and filtering at a single point that sees traffic between spokes and traffic leaving the estate, rather than trying to enforce security separately in every network. This central enforcement point is far easier to keep consistent and to audit than scattered controls, and it embodies the principle of security as a property of the design rather than a per workload afterthought, a theme in Security by Design on OCI.
For estates that span regions, the hub and spoke pattern extends, with a hub in each region and the regional hubs connected to each other, so that the estate has a clean topology both within and across regions. This keeps the multi region design manageable, because the cross region connectivity is concentrated at the hubs rather than spread across every workload network. The wider multi region considerations are covered in Multi Region Architecture on OCI, and the hub and spoke topology is what keeps the networking part of that design from becoming unmanageable.
Hub and spoke is the right destination for a growing estate, but it is not always the right starting point. An estate with one or two networks does not need a hub, and building one prematurely adds complexity for no benefit. The skill is in designing the early networks, particularly their address space, so that the hub can be introduced cleanly when the estate grows into needing it, rather than building the hub on day one or, worse, growing a mesh and having to unpick it later. Designing for the eventual hub without building it yet is the balanced approach.
The case for hub and spoke is usually made on scale and security, but the operational benefits are just as real. Because shared concerns live in one place, changes to connectivity, DNS or inspection are made once in the hub rather than repeated across every network, which reduces both effort and the chance of inconsistency. Troubleshooting is simpler because the paths traffic takes are predictable, flowing through the hub rather than through an unpredictable mesh of direct connections. Onboarding a new workload is a matter of standing up a spoke and connecting it to the hub, a repeatable operation rather than a bespoke networking project. These operational gains compound over the life of the estate and are a large part of why mature organisations standardise on the pattern.
A hub is not free, because the connectivity and the shared services it hosts carry their own cost, and traffic routing through a central inspection point can add to data processing charges. For a small estate these costs can outweigh the benefit, which is another reason not to build a hub before it is needed. For a large estate, the hub almost always pays for itself, because the alternative is duplicating connectivity and services across many networks, which costs more in aggregate and far more in operational effort. The cost question is therefore really a question of scale, and the same threshold that makes hub and spoke worthwhile for manageability tends to make it worthwhile on cost as well. Designing the hub to concentrate genuinely shared services, rather than becoming a dumping ground, keeps its cost proportionate to the value it provides.
Designing and building hub and spoke topologies is part of our OCI Networking practice, and we plan for it from the start of the landing zone work in our OCI Consulting and Advisory engagements, particularly in the address planning that makes a future hub clean to introduce. The aim is a network that scales by adding spokes rather than by multiplying connections, with security and shared services concentrated where they can be managed well.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.