Set Up a Hub-and-Spoke Network Topology Using a Dynamic Routing Gateway

A hub-and-spoke network, often called a star network, has a central component that's connected to multiple networks around it. Setting up this topology in the traditional on-premises data center can be expensive. But in the cloud, there’s no extra cost.

The dynamic routing gateway (DRG) is a virtual router that provides a path for private network traffic between a virtual cloud network (VCN) and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network from another cloud provider.

The DRG can connect to multiple VCNs, adding flexibility to how you design your cloud network.

Use the hub-and-spoke architecture to build creative and powerful networking solutions in the cloud for the following common use cases:
  • Isolate the workloads of different customers, such as the subscribers of an ISV
  • Provide shared IT services such as log server, DNS, and file sharing from a central network
  • Extend Oracle Cloud Infrastructure connectivity to multicloud environments using FastConnect partners
  • Set up separate development and production environments
  • Segregate environments to meet compliance requirements, such as PCI and HIPAA


A dynamic routing gateway (DRG) allows you to connect up to 300 virtual cloud networks and helps to simplify not only the overall architecture, but also security list and route table configuration, as well as security policy management by advertising OCIDs through the DRG.

In this architecture, a dynamic routing gateway is connected to multiple VCNs. There are sample subnets and VMs in each VCN. The DRG has a route table that specifies rules to direct traffic to targets outside the VCN. The DRG enables private connectivity with an on-premises network, which you can implement by using Oracle Cloud Infrastructure FastConnect, site-to-site VPN, or both. The DRG also enables you to connect to multiple cloud environments using a FastConnect partner.

The following diagram illustrates this reference architecture.

Description of hub-and-spoke-drg.png follows
Description of the illustration hub-and-spoke-drg.png

The architecture has the following components:

  • On-premises network

    This network is the local network used by your organization. It is one of the spokes of the topology.

  • Cloud

    Cloud computing delivers computing infrastructure and services, such as servers, virtual machines, security, storage, databases, networking, analytics, applications, and so on over the Internet. With cloud computing, the provider manages and maintains the infrastructure and services. You typically pay only for the resources you use and can scale the resources as your requirements change.

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Network security group (NSG)

    NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Bastion host

    The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

  • Site-to-Site VPN

    Site-to-Site VPN provides IPSec VPN connectivity between your on-premises network and VCNs in Oracle Cloud Infrastructure. The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives.

  • FastConnect

    Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.


Use the following recommendations as a starting point to <rest of sentence.> Your requirements might differ from the architecture described here.
  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  • Security lists

    Use security lists to define ingress and egress rules that apply to the entire subnet.

  • Security

    Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe and denies operations that violate any of the policies.


Consider the following points when deploying this reference architecture.

  • Performance

    Within a region, performance isn’t affected by the number of VCNs. When you peer VCNs in different regions, consider latency. When you use spokes connected through VPN Connect or FastConnect, the throughput of the connection is an additional factor.If extreme performance is required, use Local Peering instead of going through the DRG.

  • Security
    Use appropriate security mechanisms to protect the topology.The topology that you deploy by using the provided Terraform code incorporates the following security characteristics:
    • The default security list of the hub VCN allows SSH traffic from Adjust the security list to allow only the hosts and networks that should have SSH access (or whatever other services ports are required) to your infrastructure.
    • This deployment places all components in the same compartment.
    • Spoke VCNs are not accessible from the internet.
  • Availability and redundancy

    Except for the instances, the remaining components have no redundancy requirements.The VPN Connect and FastConnect components are redundant. For further redundancy, use multiple connections, preferably from different providers.

  • Cost

    The only components of this architecture that have a cost are the compute instances and FastConnect (port hours and provider charges). If a VCN in a different region is connected, traffic between regions is charged. The other components have no associated cost.

  • Management

    Route management is simplified as most routes will be at the DRG. Using the DRG as the hub, it is possible to have 300 attachments (using LPGs, the hub VCN can only connect to 10 VCNs).


The Terraform code for this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, you can download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.


The Terraform code includes most of the components shown in the architecture diagram. The service VM, workload VM, VPN connection, and FastConnect are not included in the code, although they are shown in the diagram.
  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Review and accept the terms and conditions.
    3. Select the region where you want to deploy the stack.
    4. Follow the on-screen prompts and instructions to create the stack.
    5. After creating the stack, click Terraform Actions, and select Plan.
    6. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy by using the Terraform CLI:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Change Log

This log lists significant changes: