Introduction

As part of the Oracle Multicloud strategy, during Cloud World 2024 Oracle and Amazon Web Services (AWS) jointly announced Oracle Database services on OCI in AWS datacenters. This product is known as Oracle Database@AWS. It was released for General Availability during July 2025.

Multicloud is defined as the coordinated use of cloud services from more than one provider. And what better way of using the coordinated services of two Cloud Service Providers than Oracle Database@AWS? With Oracle Database@AWS, OCI extends its services inside AWS regions!

OCI for AWS Architects

Oracle University offers three courses to engineers that are already familiar with the cloud environments of other Cloud Service Providers (CSP). One of these courses is OCI for AWS Architects. In these courses the learners’ current CSP knowledge is leveraged for presenting similar services that OCI offers; for example, the Virtual Network in AWS is called Virtual Private Cloud (VPC), while in OCI is called Virtual Cloud Network (VCN). Similarly, in AWS one or more physically separate data centers within a region is called an Availability Zone (AZ) while in OCI is called an Availability Domain (AD).

The OCI for AWS Architects course is highly recommended for anybody that will work with Oracle Database@AWS because similar concepts will be named accordingly in their respective Cloud Service Provider during provisioning, and in the service’s documentation.

With this new joint offering from Oracle and AWS, new services are created, and one of these is the Oracle Database Network or ODB Network.

The Oracle Database Network

An ODB Network is a brand-new network resource inside AWS that shares similar attributes to a VPC.  It is provisioned specially for deploying an Oracle Exadata VM Cluster or an Oracle Autonomous Database Cluster that host Oracle databases. It differs from an Amazon VPC mainly because it only supports Oracle Database@AWS resources within the network. An ODB network is a private and isolated network in a specified AZ for a multi-tier architecture. In this architecture the application resides in a VPC that will be peered to the ODB Network.

Because Oracle Database@AWS is an Oracle managed service that logically resides in OCI but physically is hosted in AWS, in very specific AZs within the region, these AZs are clearly identified by the physical data center ID. For this reason the ODB Network MUST be placed in the same AZ where the Exadata Infrastructure is configured. The resources in the VPC for the applications can span AZs.  Oracle Database@AWS always uses two AZs, regardless of how many there are in the AWS region.

Oracle Database@AWS is currently available in two AWS regions:

• N Virginia (us-east-1)
• Oregon (us-west-2)

The matching OCI regions are:

• US East (Ashburn)
• US West (Boardman)

Another way that the ODB Network differs from a VPC is that the ODB Network becomes available to the AWS customer only after purchasing Oracle Database@AWS from the AWS marketplace. It is placed there by Oracle exclusively for that customer.

It is the AWS customer who requests a private offer for the Oracle Database@AWS from Oracle. Once the private offer has been generated and accepted by the customer, it will be placed in the AWS Marketplace for the customer to purchase. Only then will the Oracle Database@AWS dashboard become available. This means that the AWS Account has been paired with an OCI Tenancy. From this dashboard the customer can get access to all the Oracle Database@AWS tools.

Listing the above:

• Request private offer from Oracle in the AWS dashboard
• Purchase from the AWS marketplace
• AWS account is paired with OCI tenancy
• Tools and ODB Network become accessible from AWS dashboard

As previously mentioned, Oracle Database@AWS is an Oracle managed service. It is an OCI child site that physically resides in an AWS AZ where AWS hosts the Exadata infrastructure, and OCI provisions and maintains the Exadata infrastructure hardware inside the AZ, including the ODB Network.

In Oracle Database@AWS the user can create the following resources:

• ODB Network
• Exadata Infrastructure
• Exadata VM Cluster
• Autonomous VM Cluster

The Exadata Infrastructure is a top-level container in an AZ for Exadata databases. This is where the compute and storage servers are specified for the clusters hosting the Oracle databases.

Both the Exadata and Autonomous VM Clusters contain an installation of Oracle Clusterware, which supports databases in the cluster. These VM Clusters specify an ODB network and an Exadata infrastructure. They need to be in the same AZ.

The databases, like the Autonomous Data Warehouse, reside in OCI. They are configured from the OCI Console, or Graphic User Interface (GUI).

And this is where the OCI VCN comes into play. Every ODB Network has an OCI VCN associated with it. They are closely integrated.

The Oracle Database that resides in the VM Clusters need this VCN.

Launching the ODB Network

Creating and ODB Network requires only few fields to be filled in:

• ODB Network Name. It must start with a letter or underscore.
• Availability Zone. This one is very important. It is a known fact that if two users select the same AZ, the physical data center given to user-1 might not be the same as the one assigned to user-2. When dealing with AZs one sees the logical name. For example the us-west-2 (Oregon) AWS region has 4 Availability Zones. These are designated as us-west-2a, us-west-2b, us-west-2c, and us-west-2d. These designations are logical IDs that AWS will assign to the physical data centers based on the region’s workload at a given time so it distributes it evenly across all users in that region. Because Oracle Database@AWS is in two of these AZ, and it requires that the ODB Network be in the same AZ as the Oracle Exadata Infrastructure, it is recommended that the user selects the AZ by the data center physical name and not by the logical name. The labels for the physical data centers where Oracle Database@AWS is provisioned are:
  • usw2-az3 and usw2-az4 in the us-west-2 (Oregon) region
  • use1-az4 and use1-az6 in the use-east-1 (N.Virginia) region

• Client subnet CIDR. Curiously the ODB Network request the subnet CIDR and not the Network CIDR! As I mentioned earlier, the AWS ODB Network is closely integrated with the VCN in the OCI tenancy that is paired with the AWS account. This CIDR block IS the VCN CIDR block, and the Client subnet uses the same range. Meaning that within this CIDR range, the AWS ODB Network will only have one subnet. The Client subnet reserves or consumes five IP addresses from the CIDR, and this reservation is independent from the amount of VM Clusters in the ODB Network.
• Backup subnet CIDR. The Backup subnet routes backup and recovery traffic for Exadata resources. Because a VCN supports up to 5 different CIDRs, this CIDR prefix is assigned to the same VCN as a secondary CIDR. Similarly to the Client subnet, the Backup subnet also uses the whole CIDR range. The Cloud Architect must ensure a good IP addressing design, avoiding CIDR overlaps within the ODB Network and with the application VPC. The Backup subnet reserves or consumes three IP addresses from the CIDR, regardless of how many VM Clusters are provisioned in the ODB Network.
• DNS configuration. The default OCI DNS option can be selected, which is oraclevcn.com and there is an option for including a personal domain name prefix.  And there is an option for the customer to use a custom DNS. The custom domain name prefixes can be created when provisioning the ODB Network. If a custom domain name prefix is added, for example oudbaws, then the domain name for the Client subnet will be client.oudbaws.oraclevcn.com.

• And this is all is needed! This is everything that is needed for launching the ODB Network. There are optional services that can be included.  They are called Service Integrations. Amazon S3 and Zero-ETL can be included for ODB Network access to them. It will be necessary to grant specific permissions for allowing access to the Oracle Database@AWS resources.
• ODB peering connection. This service is configured separately. It connects the ODB Network to one VPC, which will typically host the application in the multi-tier architecture. There is a 1:1 relationship between a VPC and an ODB Network. An ODB peering connection between a single VPC and multiple ODB networks cannot be done currently, nor between a single ODB network and multiple VPCs.

Once the ODB Network is provisioned, important information about it can be seen in the Summary tab. For example the CIDRs configured for the Client and Backup subnets are displayed there, and those for the peered VPC too. Very important information visible here is the Amazon Resource Name (ARN) ID, which has a similar usage as the OCID in OCI.

A default Amazon VPC Lattice service network is launched automatically when the ODB Network is created. Amazon VPC Lattice is a fully managed application networking service that can later be used to connect, secure, and monitor layer-7 services and layer-4/TCP resources.

OCI Resources

Next to the Summary tab is the OCI Resources tab that contains the VCN OCID and a direct link to it inside the OCI Tenancy.

The route rules in the default route table that govern the ODB Network are visible from the OCI console in the VCN that is generated when the ODB Network is launched from the AWS console. And the security rules too. Seven OCI Network Security Groups (NSG) are generated when an ODB Network is provisioned.

The below list includes all VCN resources that the ODB Network launches:

• Two IPv4 CIDR blocks
• Two subnets
• One Cross-Tenancy DRG Attachment
• One Service Gateway
• Route Rules to DRG and OSN in Default Route Table
• Seven NSGs for Exadata, ADB, & DNS services
• One Private Resolver Forwarder Endpoint
• One Private Resolver Listener Endpoint

Figure 8 below shows the two CIDR prefixes for the ODB Network subnets that are shown in Figure 6 (Summary tab) as well as the DNS domain name: oudbaws.oraclevcn.com.

What stands out in the VCN resources list above is the Cross-Tenancy DRG Attachment. The VCN that is generated in the customer’s OCI Tenancy is attached to the Oracle Corporation master tenancy for managing the Oracle Database@AWS service. This is why in the route rules on the Default Route Table, the DRG is only listed as a destination, but it is not there under the Target column for clicking on it for viewing the details, like the Service Gateway is.

Seven NSG are created automatically, for different services, and attached to the appropriate vNIC.

For example, the dns_nsg  NSG is attached to the vNIC of the DNS Listener end-point, and it has stateful ingress rules for destination port 53, both UDP and TCP, where the source is the IPv4 CIDR of the peered VPC.

The DNS resolver’s Listener and Forwarder are automatically configured in the ODB Network for facilitating name resolution between the Application in AWS and the Oracle Database in OCI.

Two Important Considerations

1. Route Rule in the VPC

The App VPC in AWS that is peered with the ODB Network needs a route rule to it. And the user needs to add it manually. Currently this is done via the AWS CLI. AWS Cloud Shell can be used of this task The ARN for the ODB Network is needed for this API call. This is the format for the rule:

2. Deleteing the ODB Network

When deleting the ODB Network,  one needs to make sure to check the Delete associated OCI resources checkbox. Deleting these resources later can be a complicated and time consuming task.

Conclusion

Multicloud is the new normal, and this brings challenges, especially when integrating products from different vendors. But when competing CSPs embrace Multicloud for a joint offering that benefits the end customer, the Multicloud concept shines, and every party involved wins. This is the case with Oracle Database@AWS, where the networking component is the fundamental integration piece. 

Stay tuned for the Oracle University learning path on Oracle Database@AWS!