The hub-spoke topology (often called star topology) has a central component (the hub) that's connected to multiple networks around it, like a wheel. Implementing this topology in the traditional data center can be costly. But in the cloud, there’s no extra cost.
Use virtual cloud networks (VCNs) and the related components to build creative and powerful networking solutions in the cloud.
Segregation of environments for different workloads (development and production), different customers (of an ISV, for example), and so on
Segregation to meet compliance requirements (for example, PCI and HIPAA)
Shared services (log server, domain, file sharing) that are part of the IT infrastructure
This reference architecture shows how to implement a hub-and-spoke topology and all the infrastructure components in a region on Oracle Cloud Infrastructure.
The following diagram illustrates this reference architecture.
Description of the illustration hub-spoke-oci.png
- On-premises network
This network is the local network used by your organization. It is one of the spokes of the topology.
- Virtual cloud network
A virtual cloud network (VCN) is a private network that you set up in Oracle data centers. This architecture has a hub VCN and one or more spoke VCNs.
Subnets are subdivisions that you define within a VCN. A subnet has a contiguous range of IP addresses that don’t overlap with other subnets in the VCN.
- Security lists
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.
- Route tables
Virtual route tables provide mapping for traffic out of the VCN.
- Dynamic routing gateway
A dynamic routing gateway (DRG) is a virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network (transit routing).
- Bastion host
A bastion host is a fortified server that is used to access and manage the infrastructure.
- Local peering gateway
A local peering gateway (LPG) lets you peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.
- VPN Connect
This optional component manages IPSec VPN connections to your tenancy.
This optional component provides an easy way to create a dedicated, private connection between your data center or existing network and Oracle Cloud Infrastructure.
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range large enough for the required IP addresses. Use an address space that falls within the standard private IP address blocks.
Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network later, if necessary.
After you create the VCN, you can't change the address range.
When you design the subnets, consider functionality and security requirements. All compute instances within the same tier or role should go into the same subnet, which can be a security boundary.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
The components that have a cost are the Compute instances and FastConnect (port and provider). All other components have no associated cost.
- The hub default security list has an SSH port open to 0.0.0.0/0. Adjust the security list to match 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.
By default, each region has 10 VCNs. Each VCN can contain up to 300 subnets.
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.
- Availability and redundancy
Except for the instances, the remaining components have no redundancy requirements.
VPN Connect and FastConnect components are redundant. However, to take full advantage of and increase the redundancy, multiple internet connections (preferably from different providers) are necessary.
This deployment provides most of the components shown in the preceding diagram. The CPE/IPSec connection and FastConnect are not part of the deployment, although they are represented in the diagram.
The VMs are shown only to demonstrate basic connectivity.
The Terraform code for this reference architecture is available on GitHub.
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the