OCI Networking Series Part 4 – Advanced DRG & Multi-VCN Architectures Explained

Objective:  Scaling Networking in Large Deployments

As enterprises adopt Oracle Cloud Infrastructure (OCI) for mission-critical workloads, networking design must scale to handle multi-VCN, multi-region, and hybrid connectivity requirements. At the core of such architectures lies the Dynamic Routing Gateway (DRG) — a powerful, software-defined router that enables seamless communication between Virtual Cloud Networks (VCNs), on-premises networks, and even other cloud providers.

In this blog, we’ll explore advanced DRG use cases and multi-VCN architectures including attachments, Remote Peering, DRG attachments, Hub-and-Spoke design, and transit routing.

What is DRG, Enhanced DRG

The Dynamic Routing Gateway (DRG) in Oracle Cloud Infrastructure (OCI) is a regional virtual router that serves as the backbone for hybrid and multi-VCN connectivity. It provides a central point of control, enabling communication between Virtual Cloud Networks (VCNs), on-premises environments through IPSec VPN or FastConnect, and even cross-region VCNs using remote peering.

With the introduction of the Enhanced DRG (DRGv2), OCI has greatly simplified and strengthened network design. The enhanced DRG supports multiple types of attachments (VCNs, FastConnect, VPN, Local and Remote Peering), allows per-attachment route tables for fine-grained traffic control, and delivers greater scalability to support complex topologies such as hub-and-spoke architectures. This makes it easier for enterprises to design secure, flexible, and highly available hybrid cloud networks.

DRG Attachments

A DRG (Dynamic Routing Gateway) acts as the central connectivity hub in OCI. It supports multiple attachments that define the type of connection.

VCN Attachments → Connect a VCN to the DRG for routing traffic in/out of that VCN.

Remote Peering Connection (RPC) → Connects VCNs across different OCI regions securely over the OCI backbone.

FastConnect & IPsec VPN Attachments → Hybrid connectivity options linking on-premises datacenters or third-party clouds to OCI.

Each attachments has its own set of rules or import route distribution attached to it which controls the flow of the traffic. By default, there are 2 DRG route tables, one for for VCN attachment and other one for IPsec and fastconnect attachments.

In the above diagram, all the VCN attachments s are shown. Each attachment can have same or different route table. Keeping separate route table would be easy to manage, isolate and setup different routes for different attachments. If the setup is small and everything is allowed from each attachment to all then default route table makes more sense. But as a best practice, keeping separate RT helps in long run.

Remote Peering Connections (RPC)

When enterprises expand across regions, Remote Peering Connections (RPC) provide secure, low-latency connectivity between two VCNs in different OCI regions.

• Uses OCI’s private backbone network (not public internet).
• Supports east-west traffic flow across regions.
• Useful for DR setups (e.g., replicating databases from Mumbai region to Hyderabad region).

Each region has its own DRG and both DRG are connected through RPC connection at each side. A VM in a VCN from primary region can reach out to a VM to other region VCN compute. The connection goes through VM -> DRG -> RPC-1 -> RPC-2 -> DRG -> Compute.

Above diagram shows, the Remote peering connection is enabled between primary and secondary region and mentioned all the components required for its setup. Route table and security list controls the routes to the destination and security list restrict the ports.

🕸️ Hub-and-Spoke Architecture Design

Enterprises often manage dozens of VCNs across departments, projects, or business units. Connecting all VCNs in a mesh would be complex and unscalable. A dynamic routing gateway (DRG) allows you to connect up to 300 virtual cloud networks (VCNs) and helps to simplify the overall architecture, security list and route table configuration, and to simplify security policy management by advertising Oracle cloud identifiers (OCIDs) through the DRG. Instead, OCI recommends a Hub-and-Spoke model:

Hub VCN → Contains the DRG, shared services (DNS, logging, monitoring).

Spoke VCNs → Application-specific or environment specific VCNs.

Traffic between spokes flows via the hub DRG. 

Advantages:

✔ Centralized control

✔ Simplified routing

✔ Cost-efficient scaling

The below diagram, shows Hub VCN has network firewall and a load balancer, so each traffic from on-premises first goes to the Hub VCN as firewall inspect the traffic in HUB VCN subnet. Then it will go through the respective VCN. Even the reverse traffic follows the same route.

🔀 Transit Routing with DRG

Transit routing is a network architecture pattern that uses a central "hub" Virtual Cloud Network (VCN) to connect an on-premises network to multiple other VCNs, or to services, enabling traffic to "transit" through the hub to its final destination.

• Transit Routing enables one network connection (like FastConnect or VPN) to be shared across multiple VCNs via the hub DRG.
• Reduces redundant FastConnect/VPN setups.
• Ensures centralized hybrid connectivity.
• Simplified administration
• scalability (Easier to add more VCNs)

As mentioned in above diagram as well, each traffic form on-premises going through the HUB-VCN so its a central point for the traffic entering to the OCI tenancy and then forward the traffic to its respective destination.

✅ Best Practices for Advanced DRG & Multi-VCN Architectures

When designing OCI DRG and multi-VCN architectures, a few guiding principles can make your network both resilient and scalable. Start with a hub-and-spoke model, positioning the DRG at the center to simplify connectivity across environments. Use separate VCNs to clearly segment workloads—applications, databases, or testing—and keep shared services such as DNS, firewalls, and monitoring in the hub VCN for easier management. Take advantage of DRG route tables to fine-tune how traffic moves between networks, and enable BGP peering to gain dynamic routing, faster failover, and better bandwidth utilization. 

Strengthen your security posture with a Zero Trust mindset, applying Security Lists and Network Security Groups (NSGs) for precise traffic control. Finally, don’t overlook monitoring and logging, which provide the visibility needed to maintain both performance and protection in complex deployments.

• Use Hub-and-Spoke with Transit Routing for multi-VCN, multi-region scaling.
• For intra-region VCN connectivity, use DRG attachments (enhanced DRG); for cross-region, use RPC.
• Deploy redundant FastConnect or VPN tunnels for HA.
• Keep routing policies simple and centralized at the DRG.
• Apply security lists or NSGs carefully to control cross-VCN traffic.

Hands-On Practices to follow:- 

To gain the understanding of the above concepts, best approach is to try creating those architectures in free tier tenancy.

1. Create a Hub-and-Spoke Network with a DRG :- 

Provision one Hub VCN (10.0.0.0/16) and two Spoke VCNs (10.1.0.0/16 and 10.2.0.0/16).

Attach the Hub VCN and both Spoke VCNs to a DRG.

Configure DRG route tables so that traffic from Spoke-1 can reach Spoke-2 via the Hub.

Test: Launch a compute instance in each Spoke VCN and verify connectivity (ping/ssh).

2. Remote Peering Connection (RPC) – Cross-Region Connectivity

Create two VCNs in different regions (e.g., Ashburn and Phoenix).
Set up Remote Peering Gateways (RPGs) in both VCNs.
Establish a Remote Peering Connection.
Test: Deploy compute instances in both regions and verify private IP-to-private IP connectivity.

📌 Conclusion

Advanced DRG and Multi-VCN architectures provide the backbone for scalable, resilient, and hybrid OCI deployments. With features like VCN attachments,  DRG attachments, RPC, Hub-and-Spoke, and Transit Routing, enterprises can securely connect workloads across regions, projects, and even other clouds — all while keeping routing centralized and efficient.