OCI Network Topology Decisions

The network topology you choose on OCI is one of the hardest things to change later. Subnets, virtual cloud networks, routing and the way they connect become load bearing the moment workloads depend on them, and reworking them in a running estate is risky and slow. That makes the early topology decisions some of the most consequential ones you will make. This guide walks through the choices that define an OCI network topology and how to reason about each one before it is set in concrete.

Single VCN or many

The first fork is whether to run workloads in one virtual cloud network or several. A single VCN is simpler to reason about and route within, and for a small estate it is often the right answer. Multiple VCNs give you stronger isolation between environments or business units, the ability to apply different security postures, and a blast radius that is contained when something goes wrong. The cost is routing complexity, because VCNs do not talk to each other by default and you have to connect them deliberately.

Flat or hub and spoke

Once you have more than a couple of VCNs, the question becomes how they connect. A flat mesh where every VCN peers with every other becomes unmanageable quickly, because the number of connections grows fast and the routing turns into a maze. The hub and spoke model places shared services and connectivity in a central hub VCN that spokes route through, which centralises control, simplifies on premises connectivity and gives you one place to inspect traffic. We cover the build detail in our dedicated guide to hub and spoke networking on OCI, and it is the default we recommend for any estate beyond a handful of networks.

The dynamic routing gateway and transit

The dynamic routing gateway is the hinge of most OCI topologies. It connects VCNs to on premises networks over FastConnect or VPN, and it enables transit routing so that traffic can flow between spokes through the hub. Designing the routing carefully at this layer is what makes a hub and spoke topology actually work, because the route tables decide what can reach what. Getting this right early avoids the situation where two spokes that need to talk cannot, or worse, where everything can reach everything because the routing was left wide open.

Connecting to on premises and other clouds

Most OCI estates are not islands. They connect to a data centre, to another cloud, or to both, and that connectivity shapes the topology. FastConnect gives dedicated, private, predictable bandwidth and is the right choice for production links that carry real traffic. VPN over the internet is cheaper and faster to stand up, suiting lower volume or backup connectivity. The decision affects where the dynamic routing gateway sits, how the hub is designed and how routing propagates, and it should be made alongside the availability thinking in our high availability guide so that the connectivity itself is not a single point of failure.

A topology decision sequence

Public and private subnets

Within whatever VCN structure you choose, the split between public and private subnets is a topology decision with direct security consequences. The principle that holds up is to keep almost everything in private subnets, with no direct route to the internet, and to place only the few resources that genuinely must be reachable from outside, typically load balancers and bastion hosts, in public subnets. Backends, databases and internal services sit private and reach the internet, when they need to at all, through a network address translation gateway for outbound traffic and a service gateway for OCI services, neither of which exposes them to inbound connections.

This layout means the public surface of the estate is small and deliberate, which is both a security posture and a simplification, because there are fewer paths to reason about. It also aligns with the private by default thinking that runs through our compliance design guide. Getting the subnet split right early avoids the awkward situation where a database ended up in a public subnet for expedience and now has to be moved while live.

Security at the topology layer

Topology and security are inseparable, because the network is where a great deal of security is either enforced or lost. Network security groups and security lists decide what traffic is allowed between subnets and resources, and the topology determines where those controls sit and what they protect. A hub and spoke design, for instance, lets you inspect and filter traffic centrally at the hub, which is far easier than trying to enforce consistent rules across a sprawling mesh. The routing itself is a security control, because a route that does not exist is a path that cannot be taken.

The discipline that matters is least privilege at the network layer, opening only the flows that are actually needed rather than broad ranges for convenience. This is harder to retrofit than to build in, because once workloads depend on permissive rules, tightening them risks breaking things. Designing the security groups and routes deliberately as part of the topology, rather than loosening them later to unblock a deployment, is what keeps the network defensible as the estate grows.

Evolving the topology over time

However carefully you design a topology, the estate it serves will change, and the topology has to be able to evolve without a rebuild. This is the strongest argument for choosing hub and spoke and reserving generous, non overlapping address space early, because both make growth additive rather than disruptive. A new business unit becomes a new spoke, a new environment becomes a new VCN that peers into the existing hub, and the central connectivity and shared services are already in place to receive them. Contrast that with a flat design that has to be partially dismantled every time something new arrives.

The topology decisions that age well are the ones that anticipate growth without over building for it on day one. You do not need every spoke that you will eventually have, but you do need a structure that can accommodate them, and address space that will not clash when they arrive. Treating the topology as something that grows along a planned path, rather than a fixed design or an ad hoc sprawl, is the difference between a network that scales gracefully and one that has to be re architected every couple of years, a theme that runs through our scaling patterns guide.

Address space is forever

One topology decision deserves special attention because it is the hardest to undo, and that is IP address planning. Overlapping CIDR ranges between VCNs, or between OCI and on premises, block peering and connectivity and are painful to fix once workloads are live. Allocate ranges that do not overlap with anything you might ever connect to, leave room for growth, and document the allocation so future networks fit the plan. This single piece of discipline prevents a large share of the connectivity problems we are called in to untangle, and it sits within the broader foundations in our complete architecture guide.

Getting the topology right the first time

Network topology rewards careful thought up front because the cost of change rises sharply once workloads depend on it. Size the estate, choose the VCN and connection model, design the routing and reserve the address space deliberately, and the topology will carry the estate for years. Pair this with the scaling considerations in our scaling patterns guide. When you want the topology designed and built to hold up as the estate grows, our OCI networking solution and implementation service are built for exactly that.