OCI Networking: The Complete Guide

Networking is the layer that decides whether everything else on OCI works, and it is the layer that is hardest to change once workloads depend on it. A compute shape can be resized in minutes and a database can be tuned over a weekend, but the address ranges, the routing, and the connectivity into your wider estate are decisions that calcify the moment real traffic flows through them. Getting the network right early is therefore one of the highest leverage things you can do on OCI, and getting it wrong is one of the most expensive to unwind. This guide is the complete picture, from the virtual cloud network that everything sits inside, through subnets and gateways and routing, to the choices that connect OCI to your data centre and to other clouds.

The structure of OCI networking is logical once you see it whole, which is the goal here. We will build up from the foundations, the virtual cloud network and its subnets, through the gateways that control what can talk to what, into the routing that ties it together, and out to the connectivity options that link OCI to the rest of your world. Each section links to a focused guide where the detail lives, so this page works as the map and the others as the territory.

The virtual cloud network

Everything in OCI networking lives inside a virtual cloud network, the VCN, which is your private, software defined network within a region. A VCN is defined by one or more address ranges, and inside it you carve out subnets, attach gateways, and write routing and security rules. The VCN is the boundary of your private network, and the single most consequential early decision is the address range you give it, because that range has to coexist with every other network you will ever connect to. Choose it badly, overlapping with your on premises ranges or with another cloud, and you create a problem that is painful to fix later. Our VCN fundamentals guide covers how to think about this properly, and it is worth the time before you create anything.

Subnets and the public private divide

Within a VCN you divide the address space into subnets, and the most important property of a subnet is whether it is public or private. Public subnets can host resources with public addresses reachable from the internet. Private subnets cannot, and that is the point. The discipline of good network design is to keep almost everything in private subnets, exposing only what genuinely must be reachable, and routing the rest through controlled gateways. Our subnet design guide goes into how to lay subnets out across availability domains for resilience and how to size them so you are not boxed in later. The recurring mistake here is treating subnets as an afterthought, when in fact the public private split is the spine of your security posture.

The gateways

Gateways are how traffic enters and leaves a VCN, and OCI gives you a distinct gateway for each kind of traffic, which is cleaner than it first appears because each one has a single, clear job. An internet gateway allows two way traffic between public subnets and the internet. A NAT gateway allows resources in private subnets to reach out to the internet without being reachable from it, which is how a private application server fetches an update without being exposed. A service gateway gives private resources a path to OCI services such as object storage without that traffic ever traversing the internet at all. Our service gateway and NAT guide covers when to use which, and the distinction matters for both security and cost.

Connecting beyond the VCN

The dynamic routing gateway, the DRG, is the hub for everything that connects your VCN to networks outside it, whether that is your data centre, another VCN, or another region. It is the single attachment point through which private connectivity flows, and understanding it is the key to understanding how OCI scales beyond one isolated network. Our dynamic routing gateway guide explains how it works and why the modern DRG is far more capable than the original design. Around the DRG sit the connectivity choices that link OCI to the rest of your estate, and those are worth treating as a set of deliberate trade offs rather than defaults.

Private connectivity to your data centre

There are two ways to connect OCI privately to your own network. A site to site VPN runs an encrypted tunnel over the public internet, which is quick to stand up and inexpensive but subject to internet variability. FastConnect provides a dedicated, private physical connection with predictable bandwidth and latency, which costs more but behaves consistently. The choice is a classic engineering trade off and we cover it in full in our FastConnect versus VPN guide. Many estates run both, using VPN as a quick start or a backup path and FastConnect as the production link.

Connecting VCNs to each other

When you have more than one VCN, which most real estates eventually do, you connect them through peering. Local peering connects VCNs in the same region, remote peering connects VCNs across regions, and the modern approach routes much of this through the DRG. Our local and remote peering guide covers the patterns and the pitfalls, the most common of which is, again, overlapping address ranges that make peering impossible without painful renumbering.

The connectivity options compared

Load balancing and traffic distribution

Once traffic reaches your VCN it usually needs to be distributed across instances, and OCI provides load balancers for this. There is a flexible application layer load balancer that understands HTTP and can route based on content, and a network layer load balancer that operates at the transport layer for raw throughput and low latency. Choosing between them is about what your application needs, and our load balancing options guide walks through the decision. Load balancing is also where availability is won or lost, because a load balancer spread across fault domains is what lets a single instance fail without taking the service down with it.

DNS and traffic steering

DNS is the layer that turns names into addresses, and on OCI it does more than that. The traffic management features let you steer users to the nearest or healthiest endpoint, fail over between regions, and split traffic for testing. Our DNS and traffic management guide covers how this fits into a resilient design. DNS is easy to treat as plumbing, but it is the control point for global routing, and a well designed DNS layer is what makes multi region failover something you can actually trigger rather than something you hope works.

Securing the network

Security in OCI networking happens at several layers. Network security groups and security lists control what can talk to what at the packet level, the subject of our NSGs versus security lists guide. The network firewall adds deeper inspection of traffic for threats, covered in our network firewall guide. The principle that ties them together is defence in depth, controlling access at the network edge, between subnets, and at the host, so that no single misconfiguration exposes everything. A flat network where everything can reach everything is the configuration that turns a small compromise into a large one.

A framework for designing an OCI network

Worked in this order, the network becomes a deliberate structure rather than an accumulation of rules added under pressure. Each layer has a clear job, each decision is made once and made well, and the result is a network you can reason about, secure, and grow. That is the difference between a network that supports the estate and one that constantly fights it.

Bringing it together

OCI networking is a layered system, and the leverage is all at the foundations. Get the address ranges, the public private split, and the routing right early and everything above them is straightforward. Get them wrong and you spend years working around the consequences. The detail of each layer lives in the focused guides linked throughout, from VCN fundamentals through connectivity choices to load balancing, and the connective tissue is the deliberate, layered approach this page lays out. We design and build OCI networks for clients as part of our OCI networking solution, and the work always starts with the foundations, because that is where the network is decided.

Network observability

A network you cannot see into is a network you cannot operate confidently, and OCI provides several tools for visibility. Flow logs record the traffic that traverses your subnets, giving you a record of what actually connected to what, which is invaluable for both troubleshooting and security investigation. The network path analyzer lets you test whether a given path through your network would work, tracing the routing and security rules a packet would encounter, so you can diagnose connectivity problems by analysis rather than by trial and error. These tools turn the network from a black box into something you can reason about with evidence, and they are what make operating a large estate tractable rather than a matter of guesswork.

Observability also feeds back into design. The patterns you see in flow logs, which connections are heavily used, which are unexpected, which never happen, tell you whether your network matches your intent. A connection in the logs that your design never anticipated is either a legitimate need you missed or a gap you need to close. Either way, the visibility is what lets you keep the network aligned with what you meant to build, rather than discovering the divergence during an incident.

Networking and cost

Network design has cost consequences that are easy to overlook until the bill arrives. Data transfer, particularly traffic leaving a region or crossing the internet, carries charges, and a design that routes traffic inefficiently can run up costs that a better topology would avoid entirely. The service gateway is a clear example, keeping traffic to OCI services off the internet path not only improves security but avoids transfer charges. The broad principle is that the cheapest and most secure path is usually the same path, the private one that stays on the OCI backbone, and a network designed around private connectivity tends to be both safer and less expensive than one that leans on the internet. This is the kind of structural saving that compounds, and it connects to the cost governance discipline that runs through a well managed estate.

Operating the network over time

A network is not finished when it is built. It grows as the estate grows, new VCNs appear, new connections are needed, new workloads arrive with their own requirements. Operating it well means keeping the discipline that built it, planning ranges before creating VCNs, routing deliberately rather than reactively, and reviewing the topology periodically against what it has become. The estates that stay manageable are the ones where this discipline holds, where every addition is made within the structure rather than bolted on beside it. The ones that become unmanageable are the ones where the original design was sound but every subsequent change was made under pressure without reference to it, until the network is an accumulation nobody fully understands. The work of operating a network is the work of keeping it coherent as it grows.