Skip to content

Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS)

5 minute read
Content level: Advanced
2

This article is intended for AWS customers who use Cloud WAN to manage network connectivity across their environment and are looking to connect to Oracle Database@AWS (ODB@AWS). While ODB supports connectivity via Transit Gateway or ODB peering, there is no native integration between Cloud WAN and ODB.

Oracle Database@AWS (ODB@AWS) allows customers to run Oracle Exadata workloads natively within AWS. Customers looking to use Exadata Database Service on Dedicated Infrastructure or Autonomous Database on Dedicated Exadata can use ODB network to deploy resources and use ODB peering to connect their Oracle database resources to EC2 instances in their VPCs.

If you're using an AWS Transit Gateway to manage regional connectivity between your ODB network and VPCs, you can configure routing using the steps described here.

If you're using AWS Cloud WAN to manage global connectivity, this post explains how to configure routing so your applications can reach ODB resources—even though Cloud WAN does not currently support a direct integration with ODB peering.

Architecture overview

To set up the Transit Gateway (TGW) as the bridge between the Cloud WAN and the ODB network, you'll first need to follow the steps outlined here to configure the TGW integration with the ODB network. This includes setting up the TGW attachment in the ODB Transit VPC and configuring the necessary routing

The following diagram shows the packet walkthrough and route tables of all the components involved in setting up the connectivity. ODB to Cloud WAN Flow

Traffic flow from App VPC CIDR: 10.1.0.0/16 to ODB Network CIDR: 172.30.0.0/24

  1. The application in the App VPC initiates a connection to an ODB resource. The App VPC subnet route table must include a static route to 172.30.0.0/24 pointing to the Cloud WAN attachment.
  2. Cloud WAN receives the traffic in the segment attached to the App VPC. That segment is also attached to a Transit Gateway route table that contains static routes to the ODB network, allowing Cloud WAN to forward the traffic to the Transit Gateway
  3. Transit Gateway looks up the destination in its route table and forwards the traffic to the ODB Transit VPC via its VPC attachment.
  4. The ODB Transit VPC must have a static route in the subnet where the TGW attachment resides. This route points to the ODB network via the ODB peering interface.
  5. ODB peering completes the path. Traffic exits the ODB Transit VPC and enters the ODB Network.
  6. Return traffic follows the same path in reverse. If the App VPC CIDR is listed in the ODB Peered CIDRs configuration, return traffic is routed back through the ODB Transit VPC, TGW, and Cloud WAN to reach the App VPC.
  7. The ODB Network sends return traffic directly to the Transit Gateway and does not rely on the route table of the ODB Transit VPC.

Note: The only part of this flow where routes are exchanged dynamically is between the Transit Gateway and Cloud WAN. Routes in the VPC and from the Transit Gateway to the ODB network must be configured as static routes by the administrator.

Considerations

  • The ODB Transit VPC should only have one TGW attachment.
    Attaching it to multiple TGWs can lead to asymmetric routing and break return traffic from the ODB network. These return routes are not visible in the ODB Transit VPC route tables, and customers cannot determine which TGW attachment is used for return traffic.

  • Create the TGW attachment in the ODB Transit VPC before updating Peered CIDRs.
    The Peered CIDRs define which networks can be reached via ODB peering. Any CIDR not part of the ODB Transit VPC will be routed through the TGW attachment—so it must exist before updating the config.

  • No need to add routes to the App VPC in the ODB Transit VPC.
    In this setup, the ODB Transit VPC does not need a route to the App VPC, and vice versa. These routes are only required if the ODB Transit VPC needs to initiate traffic to the App VPC.

  • The TGW attachment must be in the same Availability Zone as the ODB infrastructure.
    If it’s not, add a subnet in the correct AZ and extend the TGW attachment into it.

  • Set up DNS forwarding using Route 53 Resolver Endpoints.
    DNS queries from your AWS environment must be forwarded to Oracle's private DNS to resolve ODB hostnames. For configuration guidance, see the ODB documentation.


Deployment Steps

  1. Deploy your ODB environment and integrate it with a Transit Gateway (TGW)
    Follow the steps in the AWS documentation to set up your ODB environment and attach it to a TGW.

  2. Set up peering between TGW and Cloud WAN
    Use the steps outlined here: Cloud WAN Peering

    • If your TGW and Cloud WAN are in different AWS accounts, you’ll need to share the Cloud WAN core network and configure a shared peering.
  3. Attach the Cloud WAN segment to a TGW route table
    This allows Cloud WAN to learn about the ODB routes from the TGW.
    See: TGW Attachment

  4. Update route tables as needed

    • App VPC subnet route tables with static routes to ODB network CIDRs
      VPC Route Tables
    • TGW route tables, if not already configured in step 1, with routes to ODB network CIDRs
      TGW Route Tables
    • ODB Peered CIDRs, if not already done in step 1, to include the App VPC CIDR
      ODB Peering Configuration
  5. Test connectivity
    From the App VPC, ping your ODB resources. If routing and DNS are correctly configured, you should receive ICMP echo responses.