Extend to Advanced Elements

Journey Map

Architecture

If multiple VPCs will be used within the environment a "Hub-and-Spoke" approach may be beneficial. In this scenario:

A transit "Hub" VPC serves as a centralized point for routing network traffic to/from the "Spoke" VPCs where workloads are running.
The transit "Hub" VPC can be managed by your organizations network infrastructure SMEs. Each "Spoke" VPC can be owned by a Project/App Team.
Traffic to/from on-prem and the "Spoke" VPCs and traffic between the "Spoke" VPCs pass through the VNF(s) in the "Hub" VPC.
- VNFs within the VPC may be transparent VNFs like Palo Alto or CheckPoint firewalls, or non-transparent VNFs like F5, etc. and are managed by you.
- While VPC has native controls such as Subnet ACLs and Security Groups for control traffic, depending on the complexity of your organization, your network team may prefer to leverage centralized VNFs in transit VPC to control the traffic.
VPC's Custom Routing using ingress/egress rules is used to transit packets to/from the VNF(s) in the "Hub" VPC

The following architecture depicts a VPC Hub-and-Spoke Topology on the IBM Cloud:

Architecture

Provision VPC as hub with following prefixes:
Provision VNF of your choice. In this example using centOS-7 as VNF and enable ip spoofing on the NIC.
Enable IP forwarding in centOS-7 (sysctl -w net.ipv4.ip_forward=1)
Provision VPCs as spokes.
Deploy VM-based or container-based clusters on spoke VPCs.
Provision Transit Gateway
Add all VPCs (Hub and spokes) as connections to transit gateway
Define an ingress rule in hub VPC's custom routing table to force packets from on-premises to transit via VNF to reach target workloads
Define an egress rule in spoke VPC's custom routing table to force the return path from target destined to on-premises to transit via VNF.

Additional resources, such as leveraging Flow Logs for logging VPC traffic is available within our documentation.