Oracle Cloud Infrastructure Documentation

Topologies

Learn about the various Oracle Database@Google Cloud network topology options and select the one best suited to your organizational needs.

Topology Components

The topologies use the following key networking components:

  • Google Virtual Private Cloud (VPC) network and subnets

    Google Virtual Private Cloud (VPC) provides networking functionality to Compute Engine virtual machine (VM) instances, Google Kubernetes Engine (GKE) containers, database services, and serverless workloads. VPC provides global, scalable, and flexible networking for your cloud-based service.

  • VPC Network Peering

    VPC Network Peering connects VPC networks enabling resources in different VPCs (including between projects) to communicate using private IP addresses, and simplifies network architecture.

  • Oracle Database Network (ODB network)

    The ODB network creates a metadata construct around the Google Virtual Private Cloud (VPC), serving as the foundation for all database provisioning. The ODB network enables support for Shared VPC by abstracting and centralizing network configuration, such as subnets, CIDR ranges, and routing. This allows network administrators to manage connectivity independently of database deployment workflows.

Topology Examples

Network topology options:

Single VPC Topology

If you want high performance and low latency, host your applications within the same VPC as your database. To maintain application isolation, use separate subnets for each application while sharing Oracle Database@Google Cloud residing in the same standalone VPC.

The following architecture shows a single VPC topology:

An image of a local network topology in Google Cloud.

The diagram shows a local network topology in Google Cloud with Project A. Project A has a single VPC with a Google Cloud region. The Google Cloud region has a Zone with two subnets each hosting a Sales Application (Subnet 192.168.1.0/24) and an HR Application (Subnet 172.16.0.0/24). The Sales and HR applications connect with each other and also with Oracle Database@Google Cloud. Oracle Database@Google Cloud hosts the ODB network with Oracle Exadata Database Service and Oracle Autonomous AI Database.

VPC Peering Topology

If you want to offer Oracle Database@Google Cloud as a centralized managed service where the platform team creates the databases within their own project and VPC, use the VPC peering topology. Different lines of businesses can connect their applications hosted in a different project and different VPC to the database that's hosted in it's own VPC and project, using VPC peering.

VPC peering topology connects your applications in one VPC to the database in another VPC. VPC peering connects two VPCs so that resources in each network can communicate with each other in the same project, a different project of the same organization, or even different projects of different organizations.

The following architecture shows a local VPC peering topology:

An image of the VPC peering topology in Oracle Database@Google Cloud.

The diagram shows VPC peering topology in Google Cloud with three projects: Project HR, Project Data, and Project Sales all which connect with each other using Peering Cloud DNS peering zone.

  • Project HR has a VPC Dev HR with Subnet 192.168.1.0/24.
  • Project Sales has a VPC Dev Sales with Subnet 10.0.1.0/24.
  • Project Data has a VPC Dev with two subnets with Oracle Database@Google Cloud with an ODB network with the following details:
    • Subnet 172.16.1.0/24 is in the VPC and host GCE
    • Subnet 172.6.2.0/24 is the client subnet within the ODB network and hosts Oracle Exadata Database Service, Oracle Autonomous AI Database, or both.
Note

If you choose this topology, consider that VPC peering incurs costs.

Shared VPC Peering Topology

Shared VPCs allow organizations to connect resources from multiple projects to a common VPC network in a Host project. Organization administrators can delegate management of applications to Service Project administrators while maintaining centralized control over network resources. This simplifies the configuration and allows these resources to communicate securely and efficiently with each other using an internal IP address from the Shared VPC network.

Shared VPCs simplify networking configuration in Google Cloud. Service owners, such as database users, use the network configuration defined by their network teams, instead of manually configuring the networks between different resources. It reduces the need to enable and configure VPC Peering and associated configurations.

Shared VPC allows you to manage a single, centralized VPC in a host project, while granting each team controlled access to deploy their Oracle Databases in isolated service projects. This enables secure, consistent networking policies (firewalls, routes, DNS) across all environments, simplifies inter-service communication, and avoids VPC sprawl or duplicated configurations.

The following architecture shows an example of Shared VPC topology with an Oracle Autonomous AI Database:

An image of shared VPC network topology in Oracle Database@Google Cloud.

The diagram shows shared VPC topology in Google Cloud with a Host project and Service Project.

The Shared VPC hosts a subnet 192.168.1.0/24 in a Google Cloud region and Oracle Database@Google Cloud with an ODB network.

Service Project hosts an Application in Compute instance and an Oracle Autonomous AI Database.

The Application can connect to the Oracle Autonomous AI Database by the ODB network and the VPC.

Hub-and-Spoke Topology

If you want a virtual appliance (NVA) as a centralized point of connectivity, use the Hub-and-Spoke topology. The NVA centralizes communication from different VPC with multiple Virtual Network Interface Cards (VNICs) in each spoke subnet and facilitates communication between applications and databases.

To create the VNIC for Oracle Database@Google Cloud connectivity, you must create a subnet in the transit VPC. As a centralized point of connectivity, the NVA facilitates communication between applications and databases.

The following architecture shows a NVA hub-and-spoke topology:

An image of NVA hub-and-spoke network topology.

The image shows a hub-and-spoke NVA topology in Google Cloud with three VPCs: VPC Spoke Finance, VPC Spoke Sales, and VPC (transit). VPC (transit) hosts Subnet Transit which connects to Oracle Database@Google Cloud with an ODB network hosting Oracle Exadata Database Service and Oracle Autonomous AI Database.

  • VPC Spoke Finance has Subnet Spoke Finance, which hosts a Finance Application.
  • VPC Spoke Sales has Subnet Spoke Sales, which hosts a Sales Application.

The multiple instance NVA connects to VPC Spoke Finance using Nic2, to VPC Spoke Sales using Nic3, and to VPC (transit) using Nic1.

Multiple VPC Topology

If you want to isolate database workloads between two lines of businesses, using different Google Cloud projects, use the multiple VPC topology. A Sales and Marketing team can have their own Project and VPC for their databases in a VM Cluster inside an Oracle Exadata Database Service infrastructure.

To isolate workloads on Oracle Exadata Database Service at the VM Cluster level, deploy multiple clusters in isolated Project VPCs.

With the following:

  • Multiple VM clusters share the same Oracle Exadata Database Service infrastructure.
  • Each VM cluster is connected to a different VPC.
  • Oracle Exadata Database Service infrastructure and VM clusters can be part of different projects (select the Oracle Exadata Database Service Infrastructure project when you deploy a new VM Cluster)

The following architecture shows a multiple VPC architecture:

An image of a multiple-vpc network topology in Oracle Database@Google Cloud.

The diagram shows an Oracle Exadata Database Service infrastructure running multiple VM Cluster in different Google Cloud projects.

Project Marketing Production has one VPC Marketing and the project Sales Production has one VPC Sales both in the same Google Cloud region but with separate VPCs having separate subnets, separate VM clusters.