A hub-and-spoke network, often called star network, has a central component that's connected to multiple networks around it. The overall topology resembles a wheel, with a central hub connected to points along the edge of the wheel through multiple spokes. Setting up this topology in the traditional on-premises data center can be expensive. But in the cloud, there’s no extra cost.
Setting up separate development and production environments.
Isolating the workloads of different customers, such as the subscribers of an ISV.
Segregating environments to meet compliance requirements, such as PCI and HIPAA.
Providing shared IT services such as log server, DNS, and file sharing from a central network.
This reference architecture shows an Oracle Cloud Infrastructure region with a hub VCN connected to two spoke VCNs. Each spoke VCN is peered with the hub VCN by using a pair of local peering gateways (LPGs).
The architecture shows a few sample subnets and VMs. Security lists are used to control network traffic to and from each subnet. Every subnet has a route table that contains rules to direct traffic bound for targets outside the VCN.
The hub VCN has an internet gateway for network traffic to and from the public internet; it also has a dynamic routing gateway (DRG) to enable private connectivity with your on-premises network, which you can implement by using Oracle Cloud Infrastructure FastConnect, or IPSec VPN, or both.
The following diagram illustrates the reference architecture.
Description of the illustration hub-spoke-oci-png.png
- On-premises network
This network is the local network used by your organization. It is one of the spokes of the topology.
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)
A VCN is a software-defined network that you set up in an Oracle Cloud Infrastructure region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.
This architecture has a hub VCN and one or more spoke VCNs.
- 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 contain rules to route traffic from subnets to destinations outside the VCN, typically through gateways.
- Dynamic routing gateway
The dynamic routing gateway is a virtual router that provides a path for private network traffic between the VCN and the on-premises network. You can also use it for private connectivity between VCNs in different regions.
- 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) enables you to 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
VPN Connect provides site-to-site 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.
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.
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
When you create the VCNs, determine how many IP addresses your cloud resources in each VCN require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses.
Select VCN address ranges that don’t overlap with each other or your on-premises network.
After you create a VCN, you can't change its address range.
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.
Use regional subnets.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
When you design a hub-and-spoke network topology in the cloud, consider the following factors:
The only components of this architecture that have a cost are the compute instances and FastConnect (port hours and provider charges). The other components have no associated cost.
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 0.0.0.0/0. 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.
Consider the service limits for VCNs and subnets for your tenancy. If more networks are required, request an increase in the limits.
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.
The VPN Connect and FastConnect components are redundant. For further redundancy, use multiple connections, preferably from different providers.
The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.
Note: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 using the sample stack in Oracle Cloud Infrastructure Resource
- Go to Oracle Cloud Infrastructure Resource Manager.
- Sign in, if you haven't already.
- (Optional) To deploy the stack in a region other than US West (Phoenix), select the required region.
- Click Sample Solution.
- Click Select Solution.
- In the Browse Solutions dialog box, locate Hub-and-Spoke Network Topology, and select it.
- Click Select Solution.
- Click Next.
- Follow the on-screen prompts and instructions.
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the