Learn About Network Topologies for Oracle Database@Google Cloud

Learn about the various Oracle Database@Google Cloud network topology options and select the one best suited for your organizational needs.
  • Single VPC connectivity
  • VPC peering connectivity
  • Shared VPC peering connectivity
  • Hub-and-spoke connectivity
  • Multiple VPC connectivity

About 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 VPC.

The following architecture shows a single VPC topology:


Description of google-single-vpc-arch.png follows
Description of the illustration google-single-vpc-arch.png

google-single-vpc-arch-oracle.zip

About 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 is 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:

Description of google-vpc-peering-arch.png follows
Description of the illustration google-vpc-peering-arch.png

google-vpc-peering-arch-oracle.zip

Tip:

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

About Shared VPC 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, like 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 Database:

Description of google-shared-vpc-arch.png follows
Description of the illustration google-shared-vpc-arch.png

google-shared-vpc-arch-oracle.zip

About Hub-and-Spoke Topology

If you want the Hub network virtual appliance (NVA) as a centralized point of connectivity, use the Hub-and-Spoke topology. The Hub 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 transit 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:

Description of google-nva-hub-and-spoke-arch.png follows
Description of the illustration google-nva-hub-and-spoke-arch.png

google-nva-hub-and-spoke-arch-arch.zip

About 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.

The following architecture shows a multiple VPC architecture:

Description of google-multiple-vpc-arch.png follows
Description of the illustration google-multiple-vpc-arch.png

google-multiple-vpc-arch-oracle.zip

You must ensure 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 are part of different projects.

Topology Components

The topologies use the following key networking components:
  • Google Cloud region

    A Google Cloud region is a geographical area that contains data centers and infrastructure for hosting resources. Regions are made up of zones, which are isolated from each other within the region.

  • Google Virtual Private Cloud

    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.

  • Google Cloud zone

    A zone in Google Cloud is a deployment area for resources within a region. Zones are isolated from each other within a region, and are treated as a single failure domain.

  • Google Cloud Project

    A Google Cloud Project is required to use Google Workspace APIs and build Google Workspace add-ons or apps. A Cloud Project forms the basis for creating, enabling, and using all Google Cloud services, including managing APIs, enabling billing, adding and removing collaborators, and managing permissions.

  • 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.

  • Google Cloud Shared VPC

    Shared Virtual Private Clouds (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.