Oracle Cloud Infrastructure Documentation

Topologies

Learn about network topologies for Oracle Database@AWS.

Oracle provides example network topologies based on different Oracle Database@AWS use cases, including:

  • Same availability zone connectivity
  • Same availability zone with multiple VM clusters
  • Cross-VPC connectivity in the same region with hub and spoke
  • Cross-region connectivity with hub and spoke
  • On-premises (hybrid) connectivity with hub and spoke

Topology Planning Considerations

When selecting a network topology for Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Autonomous Database on Dedicated Exadata Infrastructure, consider the following:

  • Each VM cluster can be associated to a single ODB network within a single availability zone.
  • Each ODB network or Exadata Infrastructure can host multiple VM clusters within that availability zone.
  • Each ODB network can be peered with a single VPC within the same region.
  • VM clusters can't be moved between ODB networks.
  • An ODB network can be shared with different AWS accounts within the same AWS organization.
  • Use AWS Transit Gateway or AWS Cloud WAN to connect VPCs of the same or different AWS accounts to ODB networks.
  • IP addresses are automatically assigned to VM clusters from the CIDR range in the Client subnet.
  • The CIDR blocks must not overlap with any AWS VPC subnet, Oracle Cloud Infrastructure (OCI) VCN, or any database clients. Consider the following:
    • Client subnet: Allocate a dedicated CIDR block with a minimum size of /27. Oracle recommends that you use /24 for the Client subnet CIDR to accommodate future expansion.
    • Backup subnet (Optional for Autonomous Database): Allocate a separate CIDR block with a minimum of /28.
  • Network traffic between availability zones and regions going through the AWS Transit Gateway or AWS Cloud WAN may incur additional cost from AWS.
  • Oracle recommends using the VPC peered with ODB network as a transit VPC hub when implementing the hub-and-spoke network topology.

Topology Components

The topologies use the following key networking components:

  • Amazon virtual private cloud and subnet

    An Amazon virtual private cloud (VPC) lets you to launch AWS resources into a virtual network you have defined. This virtual network resembles a traditional network that you operate in your own data center, with the benefits of using the scalable infrastructure of AWS. After you create a VPC, you can add subnets.

    A subnet is a range of IP addresses in your AWS VPC. You can create AWS resources, such as Amazon EC2 instances, in specific subnets.

  • AWS Direct Connect Gateway

    An AWS Direct Connect gateway builds upon virtual private gateway capabilities adding the ability to connect to up to 10 VPCs across regions.

  • AWS Transit Gateway

    An AWS Transit Gateway connects AWS VPCs and on-premises networks through a central hub. This connection simplifies your network and puts an end to complex peering relationships. A transit gateway acts as a highly scalable cloud router—each new connection is made only once.

  • Amazon VPC Attachment in Amazon VPC Transit Gateways

    An Amazon Virtual Private Cloud (VPC) attachment to a Transit Gateway lets you to route traffic to and from one or more VPC subnets. When you attach an VPC to a transit gateway, you must specify one subnet from each availability zone to be used by the transit gateway to route traffic. Specifying one subnet from an availability zone enables traffic to reach resources in every subnet in that availability zone.

  • AWS Cloud WAN

    An AWS Cloud WAN is a managed wide-area networking (WAN) service that you can use to build, manage, and monitor a unified global network that connects resources running across your cloud and on-premises environments. It provides a central dashboard from which you can connect on-premises branch offices, data centers, and Amazon Virtual Private Clouds (VPCs) across the AWS global network.

  • ODB network

    An ODB network is a private network that hosts Oracle Database@AWS in a specified availability zone. You can set up an ODB peering connection between an ODB network and a VPC to connect to your Oracle databases.

Example Topologies

Expand the following sections to see example network topology diagrams.

Same Availability Zone Connectivity

This topology enables intra-availability zone connectivity to provide the lowest latency between the application and the Oracle Database. Oracle recommends this topology for latency-sensitive applications. You can deploy multiple applications in the same application VPC. To maintain application isolation, use separate subnets for each application.

The following architecture shows Oracle Database@AWS within the same availability zone:

A diagram of a same availability zone connectivity topology

To maintain application isolation, separate the subnets for each application. The application VPC connects to the ODB network using an ODB peering connection to the Oracle Database.

Same Availability Zone Connectivity with Multiple VM Clusters

You can replicate the same availability zone deployment pattern with multiple VM clusters to isolate the application and database while using the same Exadata Infrastructure.

Oracle Exadata Database Service and Oracle Autonomous Database support deploying multiple VM clusters, each within its own ODB network, to provide logical separation between environments. You can share ODB networks to different AWS accounts to provide isolation.

The following architecture shows a topology for Oracle Database@AWS in the same availability zone with multiple VM clusters:

a diagram of same availability zone connectivity with multiple vm clusters

You can deploy multiple VM clusters within a single ODB network supporting both Exadata VM clusters and Autonomous VM clusters.

Cross-VPC Connectivity in Same Region with Hub and Spoke

This topology enables applications distributed across multiple VPCs to securely connect to Oracle Database@AWS using AWS Transit Gateway or AWS Cloud WAN.

Use this topology for the following use cases:

  • If you need traffic inspection between the application tier and database.
  • For highly available applications that are deployed across multiple availability zones connected to the same Oracle Database.
  • For applications that require centralized database access from multiple lines of businesses deployed across different availability zones.

The following topology shows cross-VPC connectivity with a hub-and-spoke configuration.

a diagram of cross vpc connectivity in the same AWS region with hub and spoke architecture.

Traffic is routed through one of the following methods:

  1. From VPCs to ODB network through AWS Transit Gateway or AWS Cloud WAN.
  2. Optionally, through Firewall to ODB network using either AWS Transit Gateway or AWS Cloud WAN.

Oracle recommends that AWS Transit Gateway attachment to transit VPC subnet are in the same availability zone as the ODB network for better performance.

When designing your topology, consider the following:

  • Latency can vary for cross-VPC connectivity in the same region. Validate application performance under these conditions.
  • Configure the AWS Transit Gateway route tables, or use AWS Cloud WAN for seamless cross-VPC connectivity.
Cross-Region Connectivity with Hub and Spoke

The cross-region connectivity with hub-and-spoke topology enables applications distributed across multiple regions to securely connect to Oracle Database@AWS using AWS Transit Gateway or AWS Cloud WAN.

Use this topology for the following use cases:

  • Setting up regional disaster recovery.
  • Replicating data across regions.
  • Logging and managing databases centrally in a remote region.

The following topology shows cross-region connectivity for Oracle Database@AWS with hub and spoke:

A diagram showing cross-region connectivity with hub and spoke architecture

This topology deploys two AWS Transit Gateways, one in each region with peering. This simplifies the network and reduces cross-region latency compared to other solutions like VPN.

When designing this topology, consider the following:

  • Latency can vary due to location. Validate application performance under these conditions.
  • Alternatively, use AWS Cloud WAN for cross-region connectivity.
On-Premises (Hybrid) Connectivity with Hub and Spoke

This network topology extends connectivity to on-premises applications, enabling seamless integration with Oracle Database@AWS.

Use this topology for the following use cases:

  • Migrating from on-premises to the cloud.
  • Replicating the on-premises application and database to the cloud for disaster recovery.
  • Integrating applications both on premises and on AWS.

The following architecture shows a topology for on-premises connectivity with hub and spoke:

A diagram of on-premises (hybrid) connectivity with hub and spoke architecture.

The topology uses the AWS Transit Gateway as the central point for providing access to the database. The Transit Gateway can support two connectivity types to your on-premises network, VPN, and AWS Direct Connect. Due to latency and bandwidth requirements, Oracle recommends the following:

  • Use a Direct Connect connectivity.
  • Use an AWS Transit Gateway attachment to transit VPC subnet in same availability zone as the ODB network.

When designing this topology, ensure the following:

  • Latency can vary in on-premises connectivity. Validate application performance under these conditions.
  • Alternatively, use AWS Cloud WAN for on-premises connectivity.