When is comes to ODB@AWS product in particular and in general with all ODB@ deployments, we have a lot of integration options. Integration, in respect to this topic means how we can accommodate the ODB@AWS product in the customer AWS existing networking architecture with less changes in the configuration or architecture.

In this blog I will present an ODB@AWS network design that will minimize the configuration part when using multiple ODB Networks for separated environments.

The network topology below is showing the architecture deployed in a simplified mode containing the most important aspects:

Let’s discuss a little bit about this topology and why it is optimized for the less configuration changes and maintenance overhead when it comes to ODB@AWS product integration.

We have a number of ODB Networks, one for each and every environment: Production, Production DR and NonProduction. As we can notice, the Production and Production DR are configured in separate AZs in the same AWS region. The Active Data Guard will be routed through the the OCI infrastructure using LPGs:

All three ODB Networks are peered to the same Transit VPC, which is attached to a specific AWS cWAN segment. Tacking into account the ODB Networks are configured in two separate AZs, the Transit VPC will need to have cWAN attachments in two subnets, one subnet configured in AZ1 and the other one in AZ2. This is needed for Spoke VPCs ODB traffic to reach the specific ODB Network (in AZ1 or AZ2) and vice-versa.

The main function of the Transit VPC is to create the routing path between the Spoke VPCs to ODB Networks and vice-versa. In our deployment this VPC has also a secondary scope:

  1. It contains a test EC2 instance to test the IP connectivity to each individual ODB Network – this will prove that everything is correctly deployed.
  2. It will act as a DNS aggregator for DNS resolution from Spoke VPCs to ODB Networks and from ODB Networks to Spoke VPCs or on-premises environment.

The customer is using custom domain names for Exadata clusters and once the ODBs deployment is ready, each ODB Network will have a DNS Listener IP address created in the client subnet.

The networking design include two custom DNS servers in the Transit VPC. The DNS servers are acting a central DNS Hub.

The DNS resolution from Spoke VPCs to ODB Networks will imply a Route53 DNS conditional forwarding rule for each ODB custom domain that will use the DNS servers from Transit VPC as a target. The DNS servers were configured with conditional forwarding rules for each ODB Network custom domain having the respective DNS Listener as a target.

Below we have the DNS resolution hops from Spoke VPCs to ODB Networks:

Note: You can bypass the DNS servers and send the DNS queries from Spoke VPCs directly to the DNS Listeners endpoints in each and every ODB Network. In our scenario the security dictates to have a central DNS server management to maintain a high level of visibility for the DNS traffic and configuration.

The DNS resolution from each ODB Network to any other Spoke VPCs or to on-premises requires a DNS Forwarding endpoint. The DNS Forwarding endpoint is created automatically. A DNS conditional forwarding rule will be created in each and every ODB Network corresponding OCI Child Site for specific AWS domains that need to be resolved, targeting the DNS servers from the Transit VPC. The Transit VPC DNS servers are configured with DNS conditional forwarding rules for AWS Spoke VPCs which, in turn, target different Route53 Listener endpoints or other DNS servers in the customer AWS infrastructure.

A simplified diagram depicts the ODB Network to Spoke VPCs DNS resolution:

This conclude the design integration for ODB@AWS we can have in place using just one Transit VPC for all ODB Networks and a central DNS aggregator Hub.