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, NonProduction and NonProduction DR. As we can notice, we are using separate AZs, AZ 1 will be configured for active Production and NonProduction while in AZ 2 we will configure the DR using the same AWS region.

The Active Data Guard will be routed through the the OCI infrastructure using LPGs:

All ODB Networks in AZ 1 are peered to a Transit VPC, which is attached to a specific AWS cWAN segment.

All the ODB Networks in AZ 2 are peered to a separate DR Transit VPC.

One question may be raised regarding this construct. Why we cannot have all the ODB Networks peered to just one Transit VPC, like in the below diagram:

To answer this question we need to remember that an ODB Network is not like a regular VPC. The Transit VPC will have cWAN attachments in two subnets, one subnet configured in AZ1 and the other one in AZ2. This will provide connectivity to both subnets configured in different AZs in the Transit VPC. However, the cWAN and TGW have some limitations when it comes to route the traffic on different AZs for ODB Networks via the Transit VPC.

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, one in AZ 1 and a DR DNS server in AZ2. The DNS servers are acting as 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 Transit VPCs for each AZ we are using implementing the DNS aggregator function for all ODB Networks used.