Diese Abbildung zeigt den Ost-West-Verkehrsfluss vom Web oder der Anwendung zur Datenbank in einer regionalen Hub- und Spoke-Topologie, die eine Check Point CloudGuard-Firewall verwendet. Sie umfasst drei virtuelle Cloud-Netzwerke (VCNs):

• South-Hub-VCN (192.168.0.0/16): Das Süd-Hub-VCN enthält die Check Point-CloudGuard-Netzwerksicherheitsgateways. Das Backend-Subnetz verwendet vNIC2 für internen Traffic zu oder von den Netzwerksicherheitsgateways des Checkpoints CloudGuard. Das südliche Hub-VCN kommuniziert mit Spoke-VCNs über ein dynamisches Routinggateway (DRG).
• Web- oder Application Tier Spoke-VCN (10.0.0.0/24): Das VCN enthält ein einzelnes Subnetz. Ein Load Balancer verwaltet Datenverkehr zu den Web- oder Anwendungs-VMs. Das VCN der Anwendungsebene ist über das DRG mit dem Hub-VCN verbunden.
• Datenbank-Tier Spoke-VCN (10.0.1.0/24): Das VCN enthält ein einzelnes Subnetz, das das primäre Datenbanksystem enthält. Das VCN der Datenbankebene ist über das DRG mit dem Hub-VCN verbunden.

Der Ost-West-Verkehr fließt vom Web oder der Anwendung zur Datenbank in den folgenden Schritten:

1. Datenverkehr, der von der Web- oder Anwendungsebene auf die Datenbankebene (10.0.1.10) verschoben wird, wird über die Routentabelle des Web- oder Anwendungssubnetzes (Ziel 0.0.0.0/0) weitergeleitet.
2. Traffic wird von der Routentabelle des Web- oder Anwendungssubnetzes in das DRG für das Spoke-VCN der Datenbankebene verschoben.
3. Traffic bewegt sich vom DRG über die Ingress-Routentabelle des Süd-Hub-VCN zu den Netzwerk-Gateway-VMs des Checkpoints CloudGuard mit der sekundären IP von vNIC2.
4. Traffic vom aktiven Check Point CloudGuard Network Security-Gateway wird über die Routentabelle des Backend-Subnetzes weitergeleitet (Ziel: 10.0.1.0/24).
5. Traffic wird von der Routentabelle des Backend-Subnetzes in das DRG für das Datenbank-Spoke-VCN verschoben.
6. Traffic wird vom DRG für das Datenbanksystem über den Spoke-VCN-Anhang der Datenbank verschoben.