Local and Remote Peering on OCI

Most real OCI estates end up with more than one virtual cloud network, and the moment they do, the question becomes how those VCNs talk to each other. Peering is the answer. Local peering connects VCNs within the same region, remote peering connects VCNs across regions, and the modern approach routes much of this through the dynamic routing gateway. Done well, peering lets you keep workloads cleanly separated into their own VCNs while still letting them communicate where they need to. Done badly, usually through overlapping address ranges, peering becomes impossible without painful renumbering. This guide covers both peering types and the discipline that keeps them clean.

Peering is part of the wider topology story in our complete networking guide, and it depends heavily on the dynamic routing gateway covered in our DRG guide, which is the hub most modern peering routes through.

Why multiple VCNs

Before peering, it helps to understand why you would have several VCNs. Separation is the main reason, keeping production apart from non production, isolating workloads with different security requirements, or giving different teams their own network boundary. This separation is good practice, but it creates the need for controlled communication between VCNs, which is exactly what peering provides. The goal is isolation by default with deliberate, controlled paths between, rather than one flat network where everything can reach everything.

Local peering

Local peering connects two VCNs in the same region so resources in one can reach resources in the other using private addresses. It is the right tool when you have separated workloads within a region that still need to communicate, a shared services VCN reached by several workload VCNs, for example. The traffic stays within the region and on the private network, never touching the internet. The one hard requirement is that the address ranges of the peered VCNs must not overlap, because routing cannot distinguish between identical ranges.

Remote peering

Remote peering connects VCNs in different regions, which is how you build estates that span regions for resilience or data locality. It routes through the dynamic routing gateway using a remote peering connection, and it lets a workload in one region reach a workload or shared service in another over the OCI backbone rather than the public internet. This is foundational for multi region designs, including the disaster recovery patterns where a standby in a second region needs private connectivity to the primary. The same non overlapping range requirement applies.

Peering options compared

The overlap problem

The single most common peering failure is overlapping address ranges. If two VCNs use the same or overlapping ranges, routing cannot tell which network a given address belongs to, and peering simply cannot work. Fixing it after the fact means renumbering a live VCN, which is disruptive and risky. This is why the address planning in our VCN fundamentals guide matters so much, and why it should be done across the whole estate before any VCN is created. Plan the ranges once, plan them not to overlap, and peering stays a configuration task rather than a renumbering project.

Designing peered networks

Peering is what lets you have the security and clarity of separated VCNs without sacrificing the communication real estates need. The whole thing rests on disciplined address planning, which is cheap to do up front and expensive to retrofit. Plan the ranges, route deliberately, and peering becomes a clean way to build a network of many parts. The wider topology context is in our complete networking guide, and we design peered, multi VCN estates for clients as part of our OCI networking solution.

Routing and security across peered VCNs

Peering establishes the possibility of communication, but routing and security rules decide what actually flows. After peering two VCNs you still control, through route tables and security rules, which subnets and which resources can talk to which, so peering does not mean opening everything. The discipline is to peer for the possibility and then route and secure for the specific need, allowing only the connections the workloads genuinely require. This is least privilege applied to network topology, and it is what keeps a multi VCN estate secure rather than turning peering into a backdoor that quietly connects everything to everything.

Peering and disaster recovery

Remote peering is foundational to multi region resilience. A disaster recovery design that places a standby in a second region needs private connectivity between the primary and the standby, for replication, for management, and for failover, and remote peering through the dynamic routing gateway provides it. The standby region's VCN peers with the primary's, replication flows over the private OCI backbone rather than the internet, and when failover happens the network is already in place. This is why peering decisions and disaster recovery design are intertwined, and why the address planning that makes peering possible also makes resilient multi region architecture possible.

Keeping a multi VCN estate manageable

As the number of VCNs grows, the connectivity between them can become hard to reason about if it is allowed to accrete connection by connection. The answer is to centralise on the dynamic routing gateway, covered in our DRG guide, using it as the hub through which peering and routing are managed in one place rather than as a mesh of direct connections. A hub centred design scales because every connection passes through one understood point, and it stays manageable because the routing policy lives in one set of route tables. The estates that stay clean are the ones that decided their topology deliberately and grew within it, which is the recurring lesson of our complete networking guide.